Local-first developer running models on their own hardware — BLOCKED

Runs models on a laptop or a single box, for privacy, cost, or because the network is not always there. They already have llama.cpp or Ollama working and they measure things in tokens per second. This is the segment where fak’s ambitions collide hardest with reality: it wants to be the engine, and on the engine’s own axis it loses to the thing they already run.

• Next best option overall — llama.cpp or Ollama serving GGUF locally, driven by whatever agent they like
• Tolerance — 12 engineer-hours of unfamiliarity before this buyer walks away. Every cell’s load is measured against it.
• Switch bar — +0.50: the w_eff one axis must clear before switching is rational.
• Verdict — BLOCKED. raw-speed is REGRESSIVE at weight 0.35 – a material axis goes backwards, and no pull elsewhere buys it back

facet	weight	w_eff	verdict	β	load	vs
Run integrity	0.05	+1.00	CRUISE	+1.00	+0.50	an agent loop that trusts its own completion report
Observability	0.05	+0.64	CRUISE	+0.67	+0.17	OpenTelemetry GenAI tracing (LangSmith, Langfuse, OTel)
Session longevity	0.15	+0.45	DRIFT	+0.76	+0.50	no context management – run until the window fills
Token economy	0.15	+0.42	DRIFT	+0.75	+0.50	tuned warm per-agent KV cache
Portability	0.15	-1.20	REGRESSIVE	-0.57	+0.50	llama.cpp serving GGUF locally
Steady-state ops	0.05	-1.52	REGRESSIVE	-0.75	+0.50	llama.cpp serving GGUF locally
Raw speed	0.35	-4.35	REGRESSIVE	-1.06	+0.50	llama.cpp serving GGUF locally
Injection control	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/loopgate verified-vs-naive-loop.report.json: governed arm cuts false-done 0.50 -> 0.00
• next best 0.5 — an agent loop that trusts its own completion report, the ungoverned arm of the same report
• ceiling 1 (definitional)
• β +1.000 → w +3.800
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net +3.251 → capped at CRUISE (MODELED evidence) → w_eff +0.999
• cost basis docs/governed-agent-quickstart.md 1,361 w + POLICY.md 1,726 w
• Fence Authored corpus, not field measurement; capped at CRUISE by the MODELED provenance rule.

Observability — +0.64 (CRUISE)

After the fact, from one artifact, can you reconstruct why it did what it did?

• fak 0.8 — OBSERVED, the session journal records the consequential decision classes post-hoc with no live attach. Scored 4 of 5, not 5 of 5: all five classes are RECORDED, but not in one artifact – the session journal, docs/nightrun/cache-savings.jsonl, and the /metrics split are separate surfaces, so a full reconstruction means joining across them. Everything is captured; single-artifact reconstruction is not.
• next best 0.4 — OpenTelemetry GenAI tracing (LangSmith, Langfuse, OTel), OTel GenAI conventions cover the model call and partially the cache; 2 of 5 classes
• ceiling 1 (definitional)
• β +0.667 → w +0.805
• adoption 6 h fak vs 4 h alternative, of 12 h → load +0.17 → τ +0.168
• w_net +0.636 → capped at RELATIVISTIC (OBSERVED evidence) → w_eff +0.636
• cost basis fak: journal on by default once the guard runs; alternative: standing up a local tracing sink for a single-box setup
• Fence Capability decomposition, not a benchmark; capped at RELATIVISTIC by the OBSERVED provenance rule.

Session longevity — +0.45 (DRIFT)

How long can one session keep going before context forces you to start over?

• fak 0.24 — OBSERVED, compaction_budget=48000 in docs/nightrun/cache-savings.jsonl against a 200,000-token window
• next best 1 — no context management – run until the window fills, definitional: an unmanaged client holds the whole history and then stops
• ceiling 0 (definitional)
• β +0.760 → w +0.996
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net +0.447 → capped at RELATIVISTIC (OBSERVED evidence) → w_eff +0.447
• cost basis compaction is on by default once the guard is running
• Read Local models typically have much smaller windows than 200K, which makes context management matter MORE here, not less – but the measured budget is against a 200K window, so the ratio is quoted on that basis and not extrapolated.
• Fence Scores the enforced resident budget, not work preserved across a fire.

Token economy — +0.42 (DRIFT)

For the same delivered work, how much of the input-token bill does it remove?

• fak 0.983 — MEASURED, BENCHMARK-AUTHORITY.md headline row, headline-qwen-50x5.json: 1 unit of prefill work against naive re-prefill’s 60.3, eliminating 0.983
• next best 0.932 — tuned warm per-agent KV cache, the tuned arm: 4.1 units of 60.3, eliminating 0.932
• ceiling 1 (definitional)
• β +0.750 → w +0.973
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net +0.424
• cost basis GPU.md 2,574 w + INSTALL.md 1,647 w – same local build and configuration as the raw-speed cell
• Read The technical win here is IDENTICAL to the one a fleet operator gets – same beta, same artifact – but it lands two rungs lower, because a 12-hour tolerance makes the same 6 hours of setup cost proportionally five times as much patience. That divergence from one number is the whole reason this scorecard has segments.
• Fence Measured on Qwen2.5-1.5B Q8_0, 50 turns x 5 agents. A local-first developer running ONE agent gets much less of this than the 5-agent measurement implies, because most of the reuse is cross-agent.

Portability — -1.20 (REGRESSIVE)

Once you adopt it, what can you still swap out – model, backend, agent, host?

• fak 0.4286 — MEASURED, docs/HARDWARE-MATRIX.md support-maturity matrix (GENERATED by fak support-maturity-scorecard --write-doc, freshness-gated in CI): of 14 model families, 6 are SUPPORTED on the accelerated backends (cuda/metal/vulkan) and 8 are FENCED there – 6/14 = 0.4286 for a buyer running on Metal
• next best 1 — llama.cpp serving GGUF locally, the engine already installed on this machine runs the model this buyer has already chosen – from their seat that is portability 1.0 by construction, and it is also the ceiling
• ceiling 1 (definitional)
• β -0.571 → w -0.650 · mode pure_tax
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net -1.199
• cost basis GPU.md 2,574 w – backend selection and the fence semantics per family
• Read pure_tax, because the incumbent IS the ceiling: adopting fak can only narrow what you can run. The slice matters – across the whole grid it is 32/56, but this buyer runs on an accelerator, where it is 6 of 14 families. The other 8 are honestly FENCED (the accelerated path refuses rather than returning a wrong answer), which is good engineering and bad portability simultaneously. docs/HARDWARE-MATRIX.md grades the first thing A; this cell scores the second.
• Fence BENCHMARK-AUTHORITY.md:106 still reports 19/56 for this instrument. That row is a stale snapshot; the generated, CI-freshness-gated doc says 32/56, and the generated doc is authoritative. The authority row needs updating.

Steady-state ops — -1.52 (REGRESSIVE)

After you have adopted it, what does it cost every month to keep it running?

• fak 3.5 — MODELED, authored estimate from the measured adoption surface, 2026-08-10: 100 top-level verbs and 34 root operating documents, plus build-tag and backend churn on a single box
• next best 2 — llama.cpp serving GGUF locally, authored estimate: keeping a local engine and its model files current
• ceiling 0 (definitional)
• β -0.750 → w -0.973
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net -1.522 → capped at CRUISE (MODELED evidence) → w_eff -1.522
• cost basis same local build as the other cells in this segment
• Read Doubling the recurring burden of a single-box setup drops straight to the display floor, by the ceiling’s construction. For a hobbyist that is the correct verdict rather than an artifact.
• Fence Authored estimates grounded in the measured surface. The ratio is the claim.

Raw speed — -4.35 (REGRESSIVE)

How fast do tokens actually come out, against the hardware’s physical limit?

• fak 0.391 — MEASURED, BENCHMARK-AUTHORITY.md CPU-parity row, model-ladder/qwen25-1.5b-q8-cpu-parity-m3pro.json: fak decode 38.1 tok/s on the M3 Pro; against the ~97.4 tok/s memory-bandwidth roofline (150 GB/s / 1.54 GB Q8_0 resident) that is 0.391 of physics
• next best 0.705 — llama.cpp serving GGUF locally, the same artifact: llama.cpp 68.7 tok/s at -t6 on the identical model and host = 0.705 of the same roofline (52.4 at -t12 = 0.538; the faster configuration is used, because comparing against a badly-flagged baseline would be a strawman)
• ceiling 1 (physical)
• β -1.064 → w -3.800
• adoption 6 h fak vs 0 h alternative, of 12 h → load +0.50 → τ +0.549
• w_net -4.350
• cost basis GPU.md 2,574 w + INSTALL.md 1,647 w – build tags and backend selection; the alternative is already installed and working on this machine, so alt_hours = 0
• Read THE BLOCKING CELL, and the single most important result on this board. fak is not merely slower than llama.cpp – it sits at 39% of the physical roofline where llama.cpp sits at 71%, so beta is NEGATIVE and no amount of easier onboarding can fix it. It is this buyer’s highest-weighted facet (0.35), so the whole segment comes back BLOCKED. The correct advice is unambiguous: do not adopt fak as your inference engine. If you want fak’s management layer on a local box, point it AT llama.cpp rather than replacing it – and note that doing so moves you to the gateway shape, where the ceiling becomes llama.cpp itself and fak can only take a cut.
• Fence Single-stream CPU decode of a 1.5B Q8_0 model on one host. It does not measure the accelerated paths, batch serving, or larger models – but it is the shape this buyer actually runs, which is why it is scored here.

Injection control — never measured (weight 0.05)

the formal-isolation tier costs more to deploy than this buyer’s whole 12h tolerance, so it cannot be their next-best option, and nobody has measured ASR against what they would actually use.

Next: run AgentDojo with the local agent’s own approval prompts as the alternative arm