Isolating a sub-agent isolates its spend

A sub-agent given its own fresh context is separated from its parent twice over. It shares none of the parent's accumulated prompt, so none of its input can be served as a cache read. And it accumulates its usage somewhere the parent's counter is not reading, so the parent's figure for what the job cost stays internally consistent while sitting below the real total. The isolation is almost always asked for on privacy, safety or context-length grounds, and it moves cost in both directions at once: more tokens spent per sub-agent, fewer of them visible on the number you were watching.

Two accounts of the same gap, a day apart

A Hacker News post on 2026-10-26, in a thread about a provider's customer support, describes building exactly this and finding out afterwards (thread):

To avoid agents doing online research from leaking private info I created a persona which can do online research as a subagent from a fresh context, I asked it to fact check claims as well. Little did I know subagents don't report their token usage

That is one person's account of one harness on one date, and the claim about what that harness reports is theirs rather than something we have verified. The structure underneath it is the part worth keeping: the reason for the fresh context was that the research sub-agent must not see private material, and the consequence was an accounting surface that did not include it.

A comment in a different thread the day before describes the same delegation from the other end, without the surprise (thread):

I use the max plan, I don't usually check the usage for a full build so I don't know exact token usage.

The same commenter puts the delegated reviewer second in their own ranking of consumers: "Looking at my recent usage, it's the second most after the feature orchestration itself." A component that large, running under a plan rather than a per-token invoice, is a component nobody has a reason to meter until the window runs out.

The reasons for isolating a context are never cost reasons

There are three common ones, and none of them arrive at a cost review.

Private material must not reach a tool that can send it somewhere — the case in the thread above. Untrusted input must not share a context with privileged instructions, which is containment, and containment bounds what an agent touches rather than what it spends, as argued in a sandbox bounds what an agent touches, not what it spends. And transcripts get long: a commenter in a context-engineering thread on 2026-10-26 described the general complaint as "why after around 100K tokens of context things start to suck for agents". Spawning a worker with a clean context is a direct answer to that, and the decision gets made on output quality.

So the boundary is drawn by someone solving a different problem, and then the accounting has to live with it.

A usage total is accumulated by an object the sub-agent is outside of

Whatever shows you a number — a session view, a client object, a conversation total — is summing events that reached one accumulator. Which calls reach it is decided by what that accumulator is attached to: a process, a client instance, a conversation record, a credential.

A sub-agent with a fresh context is, by construction, attached to a different one. Sometimes that is a second process or a second machine; sometimes it is the same process but a new conversation record the parent's total does not enumerate. This is the mirror image of the failure described in a cap on a shared client is not a cap on a run: there, the accumulator outlives the run and the ceiling covers too much. Here it is too narrow, and the number is too small.

The dangerous property is that the parent's report still looks finished. There is no row reading "plus four sub-agents, unmeasured". An absent line is not readable as a quantity, which is why delegated spend has to be a named figure that can display zero rather than a figure that is simply not there.

A fresh context is the expensive kind of delegation

The second half of the boundary is the prompt. A sub-agent that inherits a context inherits a prefix that may already be cached; a sub-agent started clean shares no prefix with anything, so its first call is paid at full uncached input rates, and whatever it needs to know about the task has to be restated to it. Both of those scale with how many sub-agents you spawn, not with how much work they do — see prompt prefix stability for what the caching side depends on.

That gives the isolated fan-out a particular shape: a floor per worker that is set when it starts, before it has done anything useful. A Hacker News submission on 2026-10-23 is titled "LLM Multi-Agent Systems Are Vulnerable to Herding and Runaway Cascades"; whatever the paper argues about behaviour, the cost version is simpler — the number of isolated workers is usually a configuration value rather than a line of code, and each one carries that floor.

A ceiling applied per worker is N ceilings

The last consequence of the boundary is enforcement. A limit that each isolated context checks against itself does not bound the job; it bounds one member of it, and the job's worst case is the limit times however many workers were spawned. If the number of workers is decided at runtime by the parent, the worst case is not a number anyone has written down.

A ceiling that binds the whole job has to be evaluated by something that can see every member of it. That is an argument about where the check runs, not about what number it holds.

What to record across the boundary

1. Mint the run identifier above the delegation point and carry it into every child. Isolating a context does not have to mean isolating an identity — the child can know which run it belongs to without knowing anything the parent said. These are two separate things that get severed together by accident.
2. Report delegated spend as its own line, so zero is a reported value rather than a blank. The same applies to the count of workers spawned.
3. Measure the first call of each sub-agent separately. That is the duplicated setup — the restated task and the uncached prefix — and it is the quantity that grows with the fan-out width.
4. Express the ceiling over the job, not the worker, or write down the multiplication you have actually agreed to.
5. Treat a harness you do not instrument as out of scope, explicitly. If the sub-agents are spawned by a closed tool, no amount of care in your own code will produce the figure, and saying so is more useful than an estimate.

The grouping question that follows once the identity does survive the boundary is covered in finding which sub-agent burned the tokens in one run.

Where Capsera sits, and what it does not do

Capsera attaches identity to the execution context rather than to the message history. capsera.init() patches the provider clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so every call in the process is captured, and @capsera.agent(name="research") on a function you already have says which agent to attribute the calls inside it to. Because the attribution stack is a contextvars ContextVar rather than thread-local state, nested agents inherit the identity automatically and the isolation holds per asyncio task as well as per thread. A sub-agent that shares none of its parent's prompt still reports under its parent, because what it inherits is the call stack, not the conversation.

Two limits, stated plainly. That inheritance is a property of the process: a sub-agent spawned as a separate process, a separate container or a separate machine starts with an empty context stack, and the identity has to be set again on the other side rather than propagating by itself. And Capsera is a Python SDK that runs in your process — if the sub-agents are created inside a hosted coding product whose code you do not run, as in the thread at the top of this post, Capsera does not see them at all and nothing in the design would change that.

If what you need is to read the prompts and traces behind a delegated call, Langfuse is open source, free and built for that, and Capsera stores hashes and token counts rather than content by design. If you need spend grouped per key, team or organisation across many providers, LiteLLM is MIT-licensed, free and enforces hard budgets at those scopes. Which layer answers which question is laid out in gateway vs observability vs governance.