One endpoint in front of every model you use — hosted or local. Kevin records what each request cost and which unit of work caused it, in a ledger on your own disk, and enforces a hard spend cap before a runaway loop becomes an invoice. Not a spend dashboard. A per-request record.
Every node below is a real module. The paths under them are real.
Claude Code, an agent, a script — anything that speaks the Anthropic Messages API.
Drop-in /v1/messages endpoint. No code changes: you change a base URL.
fabric_proxy/server.py
Dispatches to the provider that owns the requested model, applies tier selection when a tier is set, and refuses the request if the estimated cost breaches the hard cap.
fabric_proxy/router.py
Anthropic, OpenAI, Groq, or a local Ollama / vLLM on your own GPU. Provider-neutral by design — competitors are inventory, not enemies.
Computes routed cost, the counterfactual baseline cost, compression ratio and latency for this exact request.
fabric_proxy/kevin_value.py
Append-only record on your disk, stamped with the build version that produced it.
KEVIN_HOME/db/walt.db
Automatic difficulty-based downgrading — picking a cheaper model than the one you asked for — is not implemented. router.py says so in its own docstring: today it honours the model you request. In 2026 that kind of routing stopped being a differentiator anyway; the hyperscalers ship it free inside your account and the model vendors ship one that routes to themselves. The part that is built, and that none of them give you, is the next box along.
An AI bill you cannot decompose is a bill you have to take on faith. Kevin writes a row per request, correlated to the ticket and unit of work that caused it, so spend is attributable after the fact — not just visible in aggregate on someone else's dashboard. The rows are on your disk, in SQLite, and you query them yourself.
daemon/fabric_proxy/telemetry.py — table fabric_calls
| Field | Why it is there |
|---|---|
| model_routed provider | Which backend actually served it. |
| input_tokens output_tokens | The billable units, measured not estimated. |
| cost_routed_usd | What this request actually cost you. |
| model_baseline cost_baseline_usd | What it would have cost on the baseline model — the counterfactual, kept rather than discarded, so savings is a query. Null on rows written before these columns existed: an unknown baseline is stored as unknown, never as zero. |
| compression_savings_usd | The second axis, kept separate from routing. Collapsing the two is how a savings claim becomes unfalsifiable. |
| latency_ms | What the routing decision cost in time. |
| ticket holon | The work item that caused the spend. This is what makes cost attributable. |
| pub_ver | Provenance: the build version that wrote the row, so you can tell which code produced which numbers. |
That last field matters more than it looks. Records written by stale code are the reason cost questions turn into archaeology. A row that can name its own author is a row you can trust or discard on evidence.
Returned inline, so the caller sees the economics of its own request.
// shape produced by fabric_proxy/kevin_value.py "kevin_value": { "model_routed": "…", "model_baseline": "…", "provider": "…", "cost_routed_usd": 0.000000, "cost_baseline_usd": 0.000000, "routing_savings_usd": 0.000000, "compression_ratio": 0.00, "total_savings_usd": 0.000000, "routing_reason": "…", "latency_ms": 0 }
Routing — serving a request on a cheaper model than the default one.
Compression — sending fewer tokens for the same task.
They are reported separately on purpose. Collapsing them into one headline number is how savings claims become unfalsifiable.
Kevin runs on your hardware, below rack scale, with no vendor service sitting between your request and your model. Nothing phones home to make a routing decision.
A vendor's router routes to that vendor. Kevin dispatches to whichever provider owns the model you named — Anthropic, OpenAI, Groq, or a model on your own GPU, which is priced at zero because it costs you nothing marginal. Same endpoint, same ledger, either way.
The event bus, service fleet, knowledge graph and edge device layer are one system with one operational surface — not a stack you integrate yourself.
Model catalogues churn constantly — providers deprecate models on weeks of notice. A router absorbs that; a direct integration eats it.
Infrastructure decisions are easier when the vendor tells you the answer is sometimes no. These are the cases where a rented API is genuinely the better choice, and we would rather you learn them here than three months into a deployment.