Why a Six-Word Question Costs What It Does

The response is short. The request contains every file that was read and every command that was run since this morning.

A one-line question is not a small request

The complaint arrives in some form every week: a session has been open for hours, the last few exchanges were trivial, and the usage figures do not reflect that at all. The natural interpretation is that something is wrong with the metering.

Nothing is wrong. Each request carries the whole conversation. Ask a six-word question in a session that has been running all day and the request still contains every file that was read, every tool result, every previous exchange. The response is short; the request is not.

That single fact explains most of what people find surprising about agent usage, and once it is clear the rest of this article is mostly mechanics.

Tool results are the bulk of it

Worth being specific about where the volume comes from, because it is not the conversation. Every time the agent uses a tool, the result comes back and becomes part of the context, and it is sent again with every subsequent request.

A test run that printed four thousand lines is now four thousand lines attached to everything that follows. A directory listing of a large repository, a verbose build log, a file the agent read to check one function — all of it persists. The exchange that felt expensive was probably not; the command whose output nobody read is.

Caching changes the price, not the volume

Prompt caching means the repeated prefix does not have to be reprocessed at full cost, which is a large saving and is frequently misunderstood as meaning the history stops counting.

It does not. The tokens are still read, at a reduced rate, on every request. So a long session is cheaper than it would be without caching and still scales with its own length. The mental model to hold is a discount on a growing number rather than a cap.

The cache has a lifetime, and the miss is the expensive part

Here is the mechanic that produces the most confusing bills. The cached prefix expires after a period of inactivity. Come back after lunch and your first message reprocesses the entire context at full rate before anything else happens.

The lifetime varies by how you are accessing the service — longer on a subscription, shorter on metered API access by default — which means the same working pattern costs different amounts depending on an arrangement most people have never looked at. If your usage spikes at the start of each session-after-a-break, that is what you are seeing.

Idle sessions are not free

The most counterintuitive item, and the one that produces genuine bewilderment. A session that is open and untouched can still be spending, because several mechanisms start a turn without you.

A scheduled task attached to the session fires on its interval and sends the whole context each time. A message delivered from another session arrives as a new turn. Background check-ins on in-flight work do the same. Each of those is a full-context request initiated while you were at lunch.

The practical consequence: closing a session you are finished with is not tidiness, it is cost control, and a long-lived session with a scheduled task attached is a standing charge.

Compaction is itself a large request

When a conversation approaches the window limit it gets summarised, and summarising means reading everything being summarised. So the moment a session becomes too big is also a moment it costs a lot, and the cost is proportional to how big you let it get.

Clearing between unrelated tasks avoids that entirely and costs nothing. The instinct to keep one session running all day because the context might be useful is usually wrong: most of the context is not relevant to the next task, and you are paying for it on every request and again at compaction.

Delegation multiplies, and it also isolates

Two effects pointing in opposite directions, which is why delegation shows up in usage discussions as both cause and cure.

Multiple agent instances working in parallel each maintain their own context, so consumption scales with the number of them and how long each runs. That is the multiplying direction, and it is steep — running several coordinating instances can consume several times what a single session would.

The isolating direction is delegating a verbose operation to a subagent: it reads the four thousand lines of test output, and only a summary comes back to the main conversation. The bulk never enters the context that gets resent forever. Used that way, delegation is one of the strongest levers available, which is why it appears on both lists.

The habits that move the number

In rough order of effect. Clear between unrelated tasks — the single biggest one, and free. Match the model to the job rather than leaving the largest one selected for mechanical work. Delegate verbose operations so their output stays out of the main context. Disable tool integrations you are not using, and check what is actually consuming your window rather than guessing. Filter noisy command output before it becomes context, which a hook can do mechanically.

And keep always-loaded instructions short: anything that loads at session start is present in every request for the whole session, whether or not it is relevant. Detailed workflow guidance belongs in something loaded on demand instead, which is the argument in the context file token budget.

Measure before you optimise

All of the above is generic advice, and the specific answer for your sessions is usually one thing dominating. Look at what is actually consuming the window and what is attributed to which activity, rather than applying a list.

The common findings are boring and actionable: an integration nobody uses occupying a large share, one command whose output is enormous, an instruction file that has grown to several hundred lines, a scheduled task nobody remembers creating. Each is a five-minute fix once identified and invisible until measured.

Long context is a behaviour, not an accident

The framing that helps most: the length of your context is a choice you are making continuously, by what you let into it and how long you keep sessions alive. It does not accumulate for reasons outside your control.

Teams that treat usage as an external constraint end up rationing access. Teams that treat context length as something they manage end up with the same capability at a fraction of the consumption, and the difference is a handful of habits rather than any restriction on what people are allowed to do.

What this means for a team's limits

Two implications for anyone administering this. First, the developers who exhaust their allowance fastest are usually not doing more work; they are keeping longer sessions and never clearing. That is coachable, and coaching it is considerably better received than a quota conversation.

Second, when someone hits a limit, the useful diagnostic is which behaviour dominated their recent usage — long context, cache misses, a heavy scheduled task, parallel instances. Each has a different remedy, and the generic advice to "use it less" addresses none of them.

The one-paragraph version

Every request carries the whole conversation, tool output is most of the weight, caching discounts the repetition without removing it, the discount lapses after a period of inactivity, idle sessions can still spend, and compacting a large session is itself expensive. Clear between tasks, keep noisy output out of context, delegate verbose work, and close sessions you are done with.

None of that constrains what you can do with an agent. It constrains how much you pay for the parts of the conversation you were not using.

The two questions worth asking about your own setup

First: what is in my context right now that I do not need? Not hypothetically — look. The answer is usually an integration nobody disabled, a file read forty exchanges ago for a task that is finished, and the full output of a command whose only relevant line was the last one.

Second: how long has this session been open, and is that on purpose? A session kept alive because clearing feels wasteful is the most common avoidable cost in this whole area, and the instinct is exactly backwards — the context you are preserving is mostly irrelevant to what you are about to do, and you are paying for it on every message.

Why this gets misread as unfairness

Worth addressing directly, because it affects how teams respond. The experience of hitting a limit after what felt like light use reads as arbitrary, and arbitrary limits produce resentment and workarounds rather than adaptation.

The mechanism is not arbitrary and it is not visible without looking, which is the whole problem. Someone who understands that tool output persists and that idle sessions can spend will change their habits in a week. Someone who believes the metering is capricious will not, because there is nothing to change. Explaining the mechanism is therefore more useful than any policy.

Cheap habits, ranked

Clear between unrelated tasks. Close finished sessions, especially any with a scheduled task attached. Filter the output of your noisiest command. Turn off integrations you are not using today. Delegate anything that produces walls of text. Keep the always-loaded instruction file short and move detail into things that load on demand. Start fresh rather than resuming a large session after a long break.

Seven habits, none of which restrict what you can ask for, and together they routinely halve consumption for the same work. That is a better return than any amount of arguing about limits.

Session hygiene is a skill worth teaching

A closing thought for anyone introducing this to a team. Everything in this article is learnable in twenty minutes and almost nobody arrives knowing it, because none of it is visible from the interface. The context does not display its own size, the tool output does not announce that it will persist, and an idle session gives no indication that it is spending.

So the default state of a new user is one that consumes several times more than necessary, and they will conclude the tool is expensive rather than that their habits are. A short walkthrough — here is what stays in context, here is what clearing does, here is why you should close that session — is one of the highest-return pieces of onboarding available, and it takes longer to schedule than to deliver.

One number worth internalising, because it reframes everything else: in a session that has read forty files and run twenty commands, the message you just typed is a rounding error in the request that carries it. Your typing is never the cost. What is already in the context is the cost, and the only levers that matter are the ones that decide what gets in and how long it stays.

The last thing worth saying is that none of this is a reason to be sparing with the tool. The habits above exist so that you can use it freely for the work that matters, rather than rationing it because a long-forgotten session has been quietly re-sending an afternoon of build logs since Tuesday. Managing context is what buys you the freedom not to think about cost during the work itself, which is the point.