Routing is not the hard part. Checking the work is.
Flywheel routes, runs, and verifies on one surface. Every accepted answer has passed a check the model does not control, and carries the record of that check with it. The authority that accepts an answer is an external verifier, never a model grading its own work.
Bring your keys, or bring your weights.
The verified-inference loop.
Propose cheap with a local model. Dispose with an external check that can fail. Carry a re-checkable receipt. What passes accumulates; the next identical ask is free, re-checked before it is served.
One surface, four things it does that others do not.
How it compares.
| Ordinary router | Local runner | Agent harness | Flywheel | |
|---|---|---|---|---|
| Routes to many providers | Yes | No | Some | Yes |
| Runs a local model | No | Yes | Some | Yes |
| Works offline | No | Yes | No | Yes |
| Accepts on an external check | No | No | No | Yes |
| Re-checkable receipt per answer | No | No | No | Yes |
| Answers local, escalates the hard part | No | No | No | Yes |
| One root-hashed shared state | No | No | No | Yes |
| Zero dependencies, one file to run | Varies | Varies | No | Yes |
Run it now.
Flywheel installs two ways, both one line. On any platform with Python: pip install flywheel-verify, then flywheel up (the PyPI name is flywheel-verify; the bare name belongs to an unrelated package; the installed command is flywheel). On Windows, the desktop installer bundles the engine, no Python, no setup: every tool the engine mounts renders as a fillable form, the first run picks a model that can actually answer, and provider keys live in the OS keychain, shown as presence only, never a value.
Each installer ships from the platform repository's version tag with SHA256SUMS.txt published beside it in the same release. Verify the copy you downloaded against that file:
- Release line
- v0.3.x, August 2026; the releases page names the current version and carries its hash.
The honest caveat.
The installer is not code-signed yet, so Windows SmartScreen will warn on first run. The hash above is the substitute: it proves the file you hold is the file the pipeline built. Signing is planned; until then the receipt does the signature's job, checked by you instead of trusted by default.
Prefer source? Zero dependencies, Python standard library only. Route online with your keys, or run fully offline against local weights.
Then open the surface in your browser. One origin, one page, same-origin JSON routes.
Benchmarks, with the interval.
The model is Flywheel-Local-Coder-14B, a trained artifact with a full provenance chain, just under 9 GB at 4-bit. Hard set, ten tasks, every arm carrying its Wilson 95% interval and 100% receipt reproducibility.
| Arm | Result | Wilson 95% CI | Receipts |
|---|---|---|---|
| single-shot | 8 / 10 (80%) | [0.490, 0.943] | 100% |
| verified inference | 9 / 10 (90%) | [0.596, 0.982] | 100% |
| best-of-4 | 9 / 10 (90%) | [0.596, 0.982] | 100% |
| single + oracle | 8 / 10 (80%) | [0.490, 0.943] | 100% |
The honest null.
Verified inference beats single-shot by +0.100 here. The 95% interval on that difference is [-0.236, +0.420], which includes zero, and plain best-of-4 sampling ties it. So we do not claim a capability uplift.
What we do claim, and can measure: 100% receipt reproducibility, every accepted answer re-checks; pass parity with the models it routes to; availability on your own schedule, from weights you hold; and local cost. A tool that refuses to overclaim is a tool whose other claims you can trust.
Evidence: the running app serves the receipt at /artifacts/flywheel-local-coder-14b-benchmark-ci.json, re-checkable offline. The number moves the day the evidence does, not before.
Spec, at a glance.
- Install
- pip install flywheel-verify, then flywheel up.
- Desktop app
- Windows x64 installer, engine bundled, no Python required. v0.3.x line, released from the platform repository with published checksums.
- Dependencies
- None. Python standard library only.
- Network
- Your choice per call: route online with hosted-provider keys, or run fully offline against local weights.
- Entry point
- flywheel up, or python scripts/run_harness_cli.py app --port 8799 from a clone.
- Surface
- One origin, one browser page, same-origin JSON routes.
- Local model
- Flywheel-Local-Coder-14B, ~9 GB 4-bit, GPU optional.
- Accept authority
- An external check. No learned model on the accept path.
- Receipts
- Content-addressed, re-checkable offline, on every accepted answer.
The replaceable half and the durable half.
Flywheel is the front surface of a verified-inference flywheel: propose with a cheap local model, dispose with an external check, keep the re-checkable receipt, and let what passes accumulate. The model is the replaceable half; the verification harness is the durable half.
The same discipline, an external check that can fail plus a receipt anyone can re-run, scales from routing a single call to composing a whole workshop of tools. This is the largest of them, and the front door to all of them.
Run it: github.com/HarperZ9/flywheel · the engine room · the workshop
State of the work, August 2026.
The engine, the receipt discipline, the witness graph, the infrastructure controls, and the verify layer are all on the public default branch. Merged as of 2026-08-03: capability-typed shell admission with Unicode-spoof neutralization, a domain oracle registry with three live verifier domains (code via pytest, mathematics via the Lean kernel, and a measurement gate for empirical claims) and an honest UNVERIFIABLE verdict elsewhere, a model-neutral router with quota failover, a subscription-auth adapter, and session tooling for past verified runs.
No capability uplift is claimed for the trained local model. The engine's first preregistered confirmatory run completed 2026-08-04: zero verdict disagreements across 2,646 certificate bodies in nine model contexts, significant held-out selection uplift at every model size on the solvable task family, nulls kept, analysis anchored in a signed ledger anyone can verify offline.