Solo developer on a flat-rate plan — UNDECIDABLE
One person running claude all day against a subscription. They are not paying per token, so the token bill is somebody else’s problem; what they feel is the session dying mid-task and having to re-explain everything. Their patience for setup is about one evening, and it competes with actually shipping. This is the largest population by headcount and the hardest to win, because the incumbent is already installed, already works, and costs them nothing to keep.
- Next best option overall — keep using bare
claude(orcodex) exactly as installed, and restart the session when it gets confused - Tolerance — 2 engineer-hours of unfamiliarity before this buyer walks away. Every cell’s
loadis measured against it. - Switch bar —
+0.50: thew_effone axis must clear before switching is rational. - Verdict — UNDECIDABLE. 50% of what this buyer weights has never been measured against their actual alternative (session-longevity, injection-control, observability, portability)
| facet | weight | w_eff | verdict | β | load | vs |
|---|---|---|---|---|---|---|
| Run integrity | 0.20 | +1.00 |
CRUISE | +1.00 |
+0.75 |
an agent loop that trusts its own completion report |
| Raw speed | 0.05 | -0.28 |
DRAG | -0.03 |
+0.25 |
a raw SGLang endpoint, unmediated |
| Token economy | 0.10 | -0.63 |
DRAG | -0.36 |
+0.25 |
bare claude, as installed |
| Steady-state ops | 0.15 | -4.06 |
REGRESSIVE | -1.50 |
+0.25 |
bare claude, as installed |
| Session longevity | 0.35 | ? | NEVER MEASURED | – | – | – |
| Injection control | 0.05 | ? | NEVER MEASURED | – | – | – |
| Observability | 0.05 | ? | NEVER MEASURED | – | – | – |
| Portability | 0.05 | ? | NEVER MEASURED | – | – | – |
Run integrity — +1.00 (CRUISE)
When you are not watching, does the run end in a state you can trust and resume?
- fak
1— MODELED, tools/loopgateverified-vs-naive-loop.report.json: the governed arm cuts false-done from 0.50 to 0.00 (net +3,900 tokens), with one-holder leases and runaway/injection caps - next best
0.5— an agent loop that trusts its own completion report, the ungoverned arm of the same report: false-done 0.50, so 0.50 of runs end in a true state - ceiling
1(definitional) - β
+1.000→w+3.800 - adoption 1.5 h fak vs 0 h alternative, of 2 h → load
+0.75→τ+0.973 - w_net
+2.827→ capped at CRUISE (MODELED evidence) →w_eff+0.999 - cost basis docs/governed-agent-quickstart.md 1,361 w + POLICY.md 1,726 w – the read to a working governed loop; docs/troubleshooting-first-run.md 890 w, which exists because the first run frequently does not work
- Read Scores the UNATTENDED case. A developer sitting and watching the terminal catches some false completions by eye, so their lived rate is better than 0.50 – at the price of having to watch, which is the thing they wanted to stop doing.
- Fence The 0.50 baseline comes from an AUTHORED corpus, not from field measurement. The governing mechanism is real and tested; the rate it is measured against is constructed. Capped at CRUISE by the MODELED provenance rule for exactly this reason – a simulated corpus cannot buy a category-defining claim.
Raw speed — -0.28 (DRAG)
How fast do tokens actually come out, against the hardware’s physical limit?
- fak
0.971— MEASURED, BENCHMARK-AUTHORITY.md Gemma-4-31B serving row: end-to-end p50 1.03x versus the unmediated endpoint, i.e. 3% slower; expressed as a speed fraction, 1/1.03 = 0.971 - next best
1— a raw SGLang endpoint, unmediated, the unmediated endpoint arm of the same comparison, normalized to 1.0 - ceiling
1(physical) - β
-0.029→w-0.029· modepure_tax - adoption 0.5 h fak vs 0 h alternative, of 2 h → load
+0.25→τ+0.255 - w_net
-0.284 - cost basis same install as the token-economy cell; no additional configuration is needed to observe the latency tax
- Read A ~3% end-to-end tax at the median. Small, and small is the correct answer here – mediation is cheap when the model call dominates.
- Fence PROXY, and scope-mismatched on purpose: measured on a self-hosted Gemma-4-31B endpoint, not on the hosted-provider path this buyer actually uses. It is the closest committed measurement of fak’s end-to-end mediation cost. The equivalent measurement against a hosted provider has not been run. It is quoted here because it costs fak points rather than winning them; a flattering out-of-scope number would not be admissible.
Token economy — -0.63 (DRAG)
For the same delivered work, how much of the input-token bill does it remove?
- fak
0.641— MEASURED, cross-agent ablationexperiments/ablate/cross-agent-pong-opus.json, K=5 per arm: output tokens 0.98x, turns 1.00x (the same work delivered), total ingested 1.56x – +28,986 tokens. Work-per-token relative to the bare agent = 1/1.56 = 0.641 - next best
1— bareclaude, as installed, the bare claude_code arm of the same artifact, normalized to 1.0 as the reference point - ceiling
1(definitional) - β
-0.359→w-0.376· modepure_tax - adoption 0.5 h fak vs 0 h alternative, of 2 h → load
+0.25→τ+0.255 - w_net
-0.631 - cost basis README.md 1,746 w + GETTING-STARTED.md 3,124 w + INSTALL.md 1,647 w – the minimum read to a first working
fak manage -- claude; the alternative is already installed and its cost is already sunk, so alt_hours = 0 - Read pure_tax because the bare agent is the reference point, not a rung below the ceiling: the absolute elimination fraction cancels in the ratio, so only the 1.56x matters. On the ONE committed head-to-head against what this buyer actually uses, fak costs MORE tokens, not fewer. The compaction row cannot rescue this cell: BENCHMARK-AUTHORITY.md:66 fences shed tokens to a proportional blend and forbids ratioing them against cache_read, so no like-for-like elimination fraction is derivable from it.
- Fence K=5 per arm on ONE tiny tool-light task. The guard’s fixed preamble dominates a short session and would amortize over a long one – which is precisely the long-session comparison this segment’s session-longevity cell records as never run. Read this as ‘unamortized overhead is real and measured’, not as ‘fak costs 1.56x forever’.
Steady-state ops — -4.06 (REGRESSIVE)
After you have adopted it, what does it cost every month to keep it running?
- fak
2.5— MODELED, authored estimate from the measured adoption surface, 2026-08-10: 100 top-levelfakverbs, 34 operating .md files at repo root, ~2.0M words across root+docs, plus its own upgrade cadence, its own config file (dos.toml), and its own failure modes layered on the agent’s - next best
1— bareclaude, as installed, authored estimate: keeping a single vendor CLI current – it updates itself and occasionally breaks - ceiling
0(definitional) - β
-1.500→w-3.800 - adoption 0.5 h fak vs 0 h alternative, of 2 h → load
+0.25→τ+0.255 - w_net
-4.056→ capped at CRUISE (MODELED evidence) →w_eff-4.056 - cost basis same install as the other cells in this segment
- Read The worst cell on the board for this buyer, and the most important one. Because the ceiling is 0 hours/month, the denominator is -N: any layer costing more than double the incumbent’s monthly attention falls straight to the display floor. Adding a management layer to a setup that already works more than doubles a solo developer’s recurring burden, and no token or safety win on this board is currently measured well enough to pay for it.
- Fence Both endpoints are authored estimates grounded in the measured surface, not timing studies. The RATIO is the claim, not the absolute hours: a 100-verb, 2M-word layer on top of a working single-binary CLI is not a wash, whatever the true hours are.
Session longevity — never measured (weight 0.35)
the deciding comparison for this buyer – fak’s compaction versus Claude Code’s own native auto-compaction, over a session long enough for both to fire repeatedly – has never been run. The repo has fak’s per-fire shed (~107K tokens against a 48K budget) but no measurement of the alternative on the same session, and docs/benchmarks/AUTHORITY-GENERATED-SAMPLE.md:465 states plainly that sessionbench has no checkpoint/resume. A number for one arm is not a comparison.
Next: run one long real task twice (bare claude vs fak manage -- claude), same prompt and same tools, and report turns-to-context-exhaustion and re-explanation events for both arms
Injection control — never measured (weight 0.05)
the formal-isolation tier fak’s 0/38 AgentDojo result is at parity with (CaMeL, MELON) costs more to deploy than this buyer’s entire tolerance, so it is not their next-best option – and no ASR measurement exists against what they would actually use, which is the host agent’s own permission prompts.
Next: run AgentDojo against bare claude with default permission prompting as the alternative arm, so the comparison is against the thing this buyer actually has
Observability — never measured (weight 0.05)
the alternative here is the agent’s own transcript, not an OTel tracing stack, and nobody has decomposed what a bare Claude Code transcript does and does not let you reconstruct after the fact.
Next: take one failed real session and score both artifacts against the same five decision classes (model traffic, cache reuse, compaction, tool verdicts, recovery)
Portability — never measured (weight 0.05)
for this buyer portability means keeping their agent and their login, not the model x backend grid; there is no committed comparison of what bare Claude Code locks in versus what fak locks in.
Next: enumerate the swap points (agent, provider, model, host) for both and mark which are actually exercised in CI