I run agents for many customers, on my own infrastructure, and I pay for every token they burn. You set a cap somewhere, an agent loops overnight, and the budget's gone by morning. A dashboard tells you what you spent after you've spent it. I wanted the spend checked before the turn runs.
Reserved before the turn
Spend is estimated and reserved before a turn runs. A turn logs its estimate up front:
[run] estimate | Estimated per-turn tokens (pre-plan) | {"stage": "estimate", "input_tokens_est": 0, "output_budget": 4000, "est_turn_tokens": 115943, "reservation_amount_dollars": 2.0}
The reservation is configured per app:
{"economics": {"reservation_amount_dollars": 0.2}}
If the reservation would take the user over their limit, the turn doesn't run. The limit holds because the check happens on the way in, before any tokens are spent.
A reservation is a hold, not the final cost
This was the most important correction to my own thinking. The reservation answers one question: can this user's funding cover the initial hold? It's not a fixed price for the turn.
The turn runs. LLM calls, embeddings, search - each one is metered as it happens. When the turn finishes, settlement reconciles what was actually spent against what was reserved. If actual usage is lower, the unused hold is released. If it's higher, settlement applies the actual recorded cost.
Reserve on the way in. Settle from actual usage on the way out. The reservation is neither a promised price nor a hard maximum - it's admission control. Separate controls handle quotas, concurrency limits, and runtime caps. If actual spend outruns the user's funding, the project budget absorbs the shortfall - and records exactly who caused it.
Where the metering happens
Any tool can be marked economically trackable. The tracking sits on the call as a decorator - track_llm, track_embedding, track_web_search - so usage is counted wherever the call happens: in app code, in the agent harness, and in generated code running inside the sandbox.
The request context follows the call chain across those boundaries. When work moves into a trusted child process or a supervisor container, a small context snapshot travels with it and gets restored before provider tools run. The cost lands on the user who caused it, even when the agent's own generated code made the call.
Generated code doesn't receive provider credentials or network access. When it needs a paid capability, it asks a trusted supervisor-side tool. That tool runs with the original request identity and accounting context, and the provider call is metered on the trusted side.
One honest limitation: arbitrary uninstrumented code is not automatically metered just because it runs on KDCube. A new paid service needs an accounting integration that reports its real usage. The runtime can enforce only the economic events it can actually observe.
The same guard works outside chat
Chat turns use the economics-aware entrypoint, but the model isn't limited to chat. A background job, API call, or scheduled task can wrap its accountable work in the same guard:
async with EconomicsGuard(...):
result = await do_accounted_work()
On entry, the guard verifies feasibility, reserves funding, and binds accounting to a stable request ID. On exit, it aggregates that request's events and settles the actual cost. Same payer identity, same quota policy, same funding and settlement rules - whether the work started from a user message or a cron job.
Try to break it
The economics and accounting modules are on GitHub, with the reservation logic and the tracking decorators. If you can get a call to escape the meter - slip a cost past the accounting from inside the sandbox - that's the issue I most want to see.
Next: my agents act on users' Gmail and Slack every day - external agents like Claude Code included - and none of them has ever seen a provider token. The auth chain that makes that work.
Second in a series on the parts of the agent stack that aren't the agent. The first, on dropping tool calling, is here.
Top comments (1)
Hey Elena! 👋 This post hit different. The reserve-before-execution pattern and the way you keep generated code away from provider credentials — that's the kind of architecture I'd love to weave into the series. The control-plane/data-plane separation fits a few upcoming stratagems better than anything I've seen in fiction.
Would you be cool with me drawing inspiration from this for a future episode? Full credit, obviously. 🙏
Either way — solid work. This is the real stuff. 👊