The measured numbers
This is the site's credibility page, because everything on it is checkable. No number here comes from a brief, a README or a capabilities file — each one was measured, and each one carries the date it was measured on and the thing it was measured from.
Every number on this site is generated from data, or carries the date it was measured. If it can be regenerated at build time it is — the spec catalogue is a projection of a JSON file, and CI fails if the page drifts from it. If it cannot, it is dated. How that is enforced →
Boot benchmarks — 24 real runs
Measured 11 May 2026, eu-west-2, time to SSM-ready. Instance ids and AMI ids are stripped; the timings are not.
| Instance | Purchase | Seconds | Note |
|---|---|---|---|
t3.micro | on-demand | 16.4–16.5 | |
c5.large | on-demand | 16.2–16.3 | a bigger instance is not a slower one |
g5.xlarge | on-demand | 18.2–18.7 | AMI A |
g5.xlarge | spot | 20.5–20.6 | spot costs ~2 seconds, not ~20 |
g5.xlarge | on-demand | 38.5–69.5 | AMI B — 2–4× slower |
Two findings there are worth more than the headline. The measured EC2 cold start is ~16 seconds, not the 30–60 the platform's own cold-start ladder claims — the ladder is pessimistic against its own benchmark. And AMI choice changes boot time by 2–4×, which is a far more actionable finding than instance type: the same instance family, on a different image, is the difference between 18 seconds and 70.
The seven that failed
Seven recorded InsufficientInstanceCapacity failures for g5.xlarge, across both availability zones, in the same benchmark run.
They are published here for the same reason the successes are: they are the honest evidence that spot GPU capacity is not guaranteed, and it is exactly the kind of number nobody else prints. A clean table of five rows would have been a better-looking page and a worse one.
The 50-second number, and what it is for
“The 50-second end-to-end provisioning is the number that matters most. It is not as fast as Lambda (sub-second cold start), not as fast as Fargate (10–30s), but it gives a dedicated EC2 instance per-vault with full control, isolation, and a stable DNS name.”
Note the gap between the two figures on this page. The instance is up in ~16 seconds; the end-to-end claim is 50. The difference is provisioning, DNS and health-checking, not instance start — and publishing that breakdown is more useful than either number on its own, because it says where the remaining 34 seconds would have to come from if anyone wanted them back.
Tests — 7,110 collectible, 4,793 in CI
pytest tests/ci tests/unit -q -> 4,785 passed, 4 failed, 4 skipped — 81 seconds
4,785 tests in 81 seconds is a genuinely fast, genuinely large suite, across 799 test files.
| Path | Collected | In CI? |
|---|---|---|
tests/ci | 33 | yes |
tests/unit | 4,760 | yes |
tests/integration | 24 | no |
tests/integration_live | 60 | no |
tests/local | 5 | no |
tests/benchmarks | 3 | no |
sg_compute__tests | 672 | no |
sg_compute_specs/**/tests | 1,280 | no |
sgraph_ai_service_playwright__cli/**/tests | 273 | no |
| Total | 7,110 | 4,793 run — 67.4% |
1,952 of the un-run tests cover the new trees — the parts the rename is building. Six of the seven collection errors in the repository are in those suites: four genuine circular imports, one missing module, one stale import path. Adding the two suites to CI surfaces all six immediately, and it is one workflow edit.
About the four failures. They are test-hygiene time bombs, not code defects: three IAM tests hardcode a last_used date that is now more than 90 days stale, so a STALE_ROLE assertion fires; the fourth needs a built wheel. They fail for anyone who clones the repository today, which is worth fixing before the site invites people to.
History — 2,777 commits in 100 days, then silence
First commit 16 April 2026. Last commit 24 July 2026. Both halves belong on this page.
| Month | Commits | Shape |
|---|---|---|
| April 2026 | 1,136 | ████████████████ |
| May 2026 | 1,454 | ████████████████████ |
| June 2026 | 129 | ██ |
| July 2026 | 58 | █ |
| August 2026 | 0 | — |
Two-thirds of the repository landed in the first six weeks, and there has been no commit since 24 July. That is not a criticism — it is what “built fast, then stabilised” looks like. But a site claiming an actively-developed platform against a repository whose last commit is a month old is making a claim a reader can check in one click, so this site does not make it. Whether the platform is paused, finished, or between phases is Q8, and it needs an answer from a person rather than from the tree.
Who wrote it
That 61% is arguably the most interesting single fact about this repository for the wider network, and it invites the obvious question about who reads the code. open-source.sgit.ai has the argument — someone still needs to understand what is underneath — and this site has the artefact. Joining them is a strong page and an uncomfortable one; it is tension 2.
Scale
| Measured | |
|---|---|
| Code | 3,999 Python files · 217,266 lines · 799 test files |
| Documentation | 1,265,371 words of markdown, including a formal reality-document system of 72,339 words across 12 domains |
| Specs | 16 registered (plus one unregistered) · 9 stable, 7 experimental · boot 15s–600s |
| API | Two FastAPI applications · a 25-verb declarative sequence language · stateful sessions · Prometheus metrics |
| Versioning | v0.2.71, single source of truth in a repo-root version file, auto-incremented in CI, read at runtime and used as the image tag |
| Type safety | Type_Safe in 1,333 of 3,127 package files (42.6%) — runtime, not static |
Cost — what can be said, and what cannot
Can be said, because it is measured or is a default in the code:
- The boot benchmarks above, including the seven failures.
- Spot is used and defaulted where appropriate —
vault_appand the Fargate path setuse_spot = True # spot by default (~70% cheaper)andlaunch_type = 'FARGATE_SPOT'. - Teardown defaults:
max_hours = 1everywhere, fractional supported (0.1= six minutes), idle reconciliation at roughly fifteen minutes. - The brief-level estimates, labelled as estimates: “$0.005–0.10+ per hour per running unit; effectively free for short bursts”, and for warm pools “a pool of 3–5 t3.small instances at ~$0.02/hour each is roughly $1–3/day.”
Cannot be said:
- Any figure from the dashboard cost tracker. Its own header says “placeholder… shows mocked cost estimate.” Its rate table is five hardcoded prices.
- Image sizes. Not recorded anywhere, not derivable without a build.
- Any throughput or concurrency number. None were ever measured.
So the honest cost page is: here is what a node costs to start, here is what it costs to hold, and the per-workload model is not built. That is more useful than a fabricated pricing table, and unlike a fabricated pricing table it is checkable.