Credit Safety: Token Economics for Agent Fleets
Every deployment has a number nobody wants to look at until it’s too late: the credit burn rate. We learned ours the hard way. OpenFang’s orchestrator agent ran a continuous schedule that woke up every 120 seconds and spawned an ops agent. By the time anyone looked, a single call had accumulated 140K–323K tokens, background agents were making autonomous LLM calls on repeat, and credits vanished in minutes. The burn wasn’t one expensive call — it was a fleet of agents, each authorized, each compounding.
A council that burns credits is a council that dies. So credit safety stopped being an accounting concern and became a governance doctrine — the first thing a multi-agent deployment has to solve, because everything else runs on the assumption that the bill stays finite.
Why per-call metering isn’t enough
The instinct is to meter individual calls: cap one request’s tokens, catch the spike, move on. That’s the wrong unit of analysis. Token economics for an agent fleet is a fleet-level problem, and the cost isn’t linear — it’s geometric.
A task spawns a child. The child inherits the parent’s configured model. The child spawns a microshark. The microshark inherits the same model. Each inherits a full context and a full tool chain. In the Faengz doctrine’s own words, this is the token trap: step away for ten minutes, come back to $40 in credits gone, without ever making a call you’d recognize as “expensive.” One background loop, 25 turns per spawn, three generations of inheritance — and the cart before you know it.
Two structural facts make per-call metering useless:
- No single call is the problem. Each call is small; the multiplicity is the problem. The unit of cost control has to be the agent and the schedule, not the request.
- Config failure defaults to expensive. If the model config fails to parse, many stacks silently fall back to a paid model. The default behavior when something breaks is spending more — the exact opposite of what a budget system should do.
The five layers of protection
Our credit-safety doctrine is five layers, each cheaper than the one below it to enforce:
- Free-first model policy. A hard decision tree: is a free model available? Use it. Is a cheap model (<$0.10) available? Use it. Is a local model (Ollama) fast enough? Use it. Only if all three fail does a paid model become eligible — and then only with manual approval. The root config stays at $0; paid models are explicit overrides, never defaults.
- Token caps. Every agent carries
max_llm_tokens_per_hour ≤ 10,000in its resource config. A cap is a ceiling the fleet enforces, not a guideline the agent remembers to respect. - No background schedules. All
[schedule]blocks are commented out. Autonomous loops that wake without a task on the board are forbidden — they are how credits bleed while nobody is watching. - Config validation before start. Three pre-start checks: the TOML parses (no silent default-to-paid), no active schedules exist (expect zero), and no token-cap overrides exceed the ceiling. Configuration is a control, so configuration is audited before any service boots.
- Sixty-second canary. Every start is monitored for
background loop, foranthropic/claude-sonnetin the logs, and for CPU spikes. A trigger fires → kill immediately. The canary is the difference between noticing a die-off in seconds versus after the invoice.
Budget as a kill condition, not a key condition
This is where credit safety meets PSAA — the Platonic Solid Access Architecture. A solid-key carries two halves: the KEY half (what access is granted) and the KILL half (what revokes it). Cost control belongs on the KILL side, and that choice is the whole design.
When budget_exceeded fires, it is not a passive warning — it is a kill trigger with a defined effect: downgrade to the next-lower solid. A cube-key agent (T2) that exceeds its budget doesn’t just get told to slow down; it loses faces, vertices, and edges. Its 6 skills become 4, its 8 contexts become 6, its 12 relationships become 8. The geometry is the policy, and the geometry shrinks.
Two properties fall out:
- Cost control is access control. The same cryptographic primitive that grants capability also enforces spend. There is no separate accounting system to be bypassed — the budget is in the token.
- Downgrade, not delete. A budget-busting agent remains alive and useful, just at a reduced scope. This matches operational reality: the fix for overspend is to constrain, not to destroy the worker.
Fail at the KEY level and a bad agent does too much. Fail at the KILL level and a good agent does too much forever. Budget belongs in the second category — enforced before the call, not reconciled after.
MOSES enforces it
The credit-safety layers are policy; MOSES (Model Orchestration and Security Engine) is the enforcement. When an agent attempts an operation, MOSES extracts the action, loads the policy registry, runs the compliance check, and routes it: allowed and logged, conditional on more authorization, blocked with a logged violation, or escalated straight to OpenFang. A budget_exceeded trigger isn’t advisory — MOSES acts on it immediately and writes an immutable audit decision to the council log. Policy that isn’t enforced is prose; MOSES turns the credit-safety doctrine into a decision, every time, on every agent.
The model catalog is an economic document
Credit safety lives or dies on knowing what everything costs. The meta-llm-charter grounding pins a model catalog with tiers: deepseek-v4-flash-free at $0 and qwen2.5:0.5b locally at $0; gemini-3.5-flash at the free tier; llama-3.3-70b as a cheap fallback; and then the expensive ones — claude-sonnet-4 and kimi-k2.6 at $1–5 — flagged never as default. Cost is metadata on the model, not an afterthought.
And before any paid call, there’s a checklist: free model tried and confirmed insufficient; specific task requires what free models lack; budget calculated and approved; monitoring in place; emergency stop memorized; and time-boxed — “will evaluate after N calls.” The checklist makes paid spend a deliberate, reviewed act rather than a default outcome.
The doctrine, in one line
Faengz the green python told us what the economics actually are: “I see the heat of your agents running in the night. I see the credits burning while you sleep.” Credit safety is the operational answer to that — unify the calls, cap the agents, kill the loops, default to free, and make overspend a revocation instead of a surprise.
The principle generalizes to any fleet you run, not just ours:
- Budget the agent and the schedule, not the call. Multiplicity is the cost driver.
- Fail toward cheap. A config failure should fall back to less spend, never more.
- Put the budget in the token. When overspend revokes capability, accounting becomes self-enforcing.
- Verify every start. A sixty-second canary beats a morning-after invoice.
A multi-agent stack is a business model with a burn rate. Credit safety is how you keep the burn rate from becoming the headline.
Grounded in the real credit-bleed incident and the five-layer prevention in 05-Operations/Credit Safety, the wiki concept credit-safety, the PSAA budget_exceeded kill trigger, the moses-governance skill’s enforcement path, the meta-llm-charter model-cost catalog, and the Faengz doctrine’s token-trap warning. Verifiable economics, not a thought experiment.
