Cost and Context

Step 7 of Becoming an Agentic Animal. What to learn, why it matters, and how to do it with Tropo.

Step 6 ended on a number you should not forget: a crew can do what one agent cannot, and it can cost fifteen times what a single chat costs. Power has a bill. This step is the skill that decides whether you can afford fluency, and it is the one that quietly separates people who run crews from people who run up bills. It comes down to treating two things as the scarce resources they actually are: the tokens you spend, and the context you spend them on.

Most people get this exactly backwards. They hear that the context window is getting bigger every year and conclude the move is to stuff more into it. The expert does the opposite. They know that context is precious, that more of it is often worse, and that the real craft is deciding what not to put in front of the model. This step teaches that craft.

What to learn

The context window is finite, and it degrades before it is full. Everyone knows the window has a hard limit. Fewer people know the subtler and more important fact: quality starts dropping well before you hit that limit. As you pack more in, the model gets less reliable about using any one piece of it, even on easy tasks. So context is not a bucket you fill to the brim for free. It is more like attention: the more you cram in, the less the model attends to each part.

Every token is billed, on every call. The cost of running an agent is driven by tokens, the input you send and the output you get back, counted on every single call. That has a consequence people miss: a long context is not a one-time cost. An agent loop re-sends its growing context turn after turn, so a bloated window does not cost you once. It costs you every step, multiplied by however long the loop runs.

Put those two together and the lesson is sharp. A stuffed context window is worse on both axes at once: it costs more and it performs worse. There is no tradeoff to manage here, no "more context, more money, but better answers." Past a point, more context is just more money for worse answers. The discipline, then, is not accumulation. It is curation.

You have three levers, and they are real. You are not stuck choosing between "enough context" and "affordable." Three techniques let you have both: cache the parts that do not change, compact the window when it fills, and spawn sub-agents to do expensive work in their own context instead of yours. Learn those three and the bill stops being the thing that decides what you can build.

Why it matters

The naive instinct, fill the giant window, fails for two independent reasons, and it is worth seeing both clearly because they reinforce each other.

The first is quality, and it is measured, not theoretical. A 2025 study from Chroma tested eighteen frontier models, the ones you actually use, and found that performance "degrades as input length grows," even on deliberately simple tasks, and well before the window is full. Anthropic, writing about how to engineer context for agents, puts the principle plainly: "Context is a critical but finite resource," one with "diminishing marginal returns," because a model has a limited "attention budget" it draws down as the context grows. The window is not free real estate. Every low-value token you leave in it is taxing the model's attention to everything else.

The second is cost, and it compounds the first. Because you are billed per token on every call, the context you carry is a recurring charge, not a one-time one. A single bloated prompt is a small waste. The same bloat carried across a fifty-step agent loop is that waste fifty times over. This is the real reason the crew in Step 6 cost fifteen times a chat: more agents, doing more steps, each re-reading context, is tokens on tokens on tokens.

Make that concrete, because the multiplication is easy to underestimate. Say an agent carries fifty thousand tokens of context, a few documents, some history, its standing instructions, and runs a modest twenty-step loop. It does not pay for fifty thousand tokens. It pays for something closer to a million, because that whole context rides along on every one of the twenty calls. Now picture the lazy version, where you pasted in three times the context you actually needed. You did not just triple the waste; you tripled it on every step. The size of the window you carry is not a setting you pick once. It is a multiplier on everything the loop does, and it is the single biggest lever on what your agents cost.

So the expert's posture is the opposite of the beginner's. The beginner asks, "how much can I fit?" The expert asks, "what is the least I can put in front of the model to get this step right?" That second question is the whole skill, and it is why this guide has hammered curation from the start: the memory you fold in Step 3, the board you read instead of scanning every file in Step 5, the typed graph you query instead of dumping in Step 4, every one of them is, underneath, a way to spend less context for the same result. Treating attention as scarce is not a cost-saving afterthought. It is the same discipline that makes the answers good.

And here is the part that makes it affordable rather than merely frugal: the three levers genuinely move the numbers. Caching a stable block of context, the instructions and tool definitions you send every single call, can cut its cost by as much as ninety percent, because the model is re-reading something it has already seen. Compaction lets a long run continue past the window limit by summarizing what came before. And a sub-agent, the move you already met in Step 6, turns out to be a context tool as much as a parallelism one. None of these is exotic. They are the standard equipment of anyone who runs agents at scale, and they are why a fifteen-times-a-chat crew is something a single person can actually afford to operate.

How to do it with Tropo

The studio is built to spend context cheaply, and the easiest way to picture why is to picture a workshop. A craftsman who walks into a well-run shop, the work plan already on the bench, the layout efficient, every tool within reach, wastes no motion just finding things. A studio is that shop for an agent, and the clearest proof is not hypothetical: it is how this very series got written. Here is each move, in practice.

Let the tools do the work the model would otherwise do in its head. The deepest way a studio saves context is by doing work outside the window entirely. When an agent needs every open task in a project, it does not read three thousand files into its context and reason over them; it runs one SQLite query and gets back five rows. When it needs to count, transform, or check something mechanical, it runs a small Python script that returns the answer. The query and the script do the work for almost no tokens, in a place that is not the context window, and only the result comes home. A query against thousands of files is more efficient than the model reading those files in, by the same margin that looking something up in an index beats reading the whole book. As our own architecture puts it, you use the cheapest correct tool for each sub-task: deterministic work gets a script, judgment work gets the model, and the model's scarce attention is saved for the judgment.

Cache the part that never changes. Every agent in the studio boots from the same large, stable block: its instructions, its tools, its standing rules. That block is identical on every call, so it is exactly what caching is for. You mark the stable prefix as cacheable, and from then on the model is handed a pointer to something it has already read instead of paying full price to read it again:

[ cached: studio instructions + tool definitions + agent identity ]   <- sent once, ~10% price thereafter
[ live:   this turn's actual task and the files it touches        ]   <- the only part you pay full price for

The rule of thumb is simple: the more of your context is stable across calls, the more of it should be cached. A studio with a big, consistent operating manual is the best case for caching, not the worst.

Compact the window when it fills. A long working session eventually approaches the window limit. The move is not to stop; it is to compact: summarize the conversation so far into a dense brief, then continue from that brief instead of the full history. You spend a few hundred tokens writing the summary and buy back thousands of tokens of room. If that sounds familiar, it should. It is exactly what Step 3 called retirement: an agent whose context is full writes a dense transfer to its successor, who starts clean. Compaction is that same move at the scale of a single session. The studio does the small version automatically and the large version as a governed ceremony, and they are the same idea: trade a cheap summary now for a lot of usable room later.

Spawn a sub-agent to spend its context instead of yours. This is the lever people underuse, and it is the one that wrote this series. To research each of these articles, the strategist on this crew, Metis, did not read a dozen sources into her own context window. She spawned a research sub-agent, handed it the question, and let it burn its window reading and verifying, then return only a short, condensed list of what it found:

Metis (main context):  "Verify the memory-and-lifecycle literature. Return a tight reference list, flag anything you can't confirm."
  -> research sub-agent (its own fresh context window)
       reads ~15 sources, checks each, discards the noise
  <- returns ~1 page of verified references

Metis keeps her context clean for the writing; the expensive reading happened somewhere else.

This is exactly what Anthropic found running their own multi-agent system: "Subagents facilitate compression by operating in parallel with their own context windows... condensing the most important tokens for the lead." A sub-agent is not only faster because it runs in parallel. It is cheaper on context because the expensive, messy exploration happens in a window you throw away, and only the distilled answer comes home. Every article in this series was researched that way, which is the only reason one agent could write seven deep pieces without drowning in its own sources.

Put the three together and the discipline is one sentence: keep your own context small and sharp, cache what repeats, compact what piles up, and send the expensive reading out to a sub-agent. Do that and a crew stops being a luxury you cannot sustain and becomes a tool you can run all day.

Do this now

Catch yourself the next time you are about to paste a giant document into a session to "give the agent context." Stop, and do the sub-agent move instead: spawn a helper, tell it to read the document and come back with only the five things that matter for your task, and carry on with those five things instead of the whole file. Watch your own window stay clean and your answers stay sharp. You just spent context like an expert, and the difference between that and dumping the file in is the difference between a crew you can afford and a bill you cannot.

The next rung

You can run a crew now, and you can afford to. But there is one scarce resource left that no amount of caching or compaction can buy back, and it is not the agent's. It is yours. Your attention, across a crew that can now do more than you can personally watch, is the final constraint. The last real skill is learning to spend it well: when to drive and when to delegate, when to put yourself in the loop and when to stay out, how to run a crew without drowning in it. In Step 8, you become the captain.

Your ambition has a studio. Let's build.

---

References

• Hong, Troynikov & Huber (Chroma), "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (2025) — across eighteen frontier models, performance degrades as input length grows, even on simple tasks.
• Anthropic, "Effective context engineering for AI agents" (2025) — "context is a critical but finite resource" with "diminishing marginal returns"; the model's "attention budget"; and compaction: summarize a near-full window and continue from the summary.
• Anthropic, "Prompt caching with Claude" (2024) — caching a stable prompt prefix can reduce cost "by up to 90% and latency by up to 85% for long prompts."
• Anthropic, "How we built our multi-agent research system" (2025) — "Subagents facilitate compression by operating in parallel with their own context windows... condensing the most important tokens for the lead"; multi-agent systems use ~15× the tokens of a chat.
• Andrej Karpathy (2025) — context engineering as "filling the context window with just the right information for the next step." (The framing of context as the scarce resource is ours, anchored to these.)

Cost and Context | Step 7 of Becoming an Agentic Animal | UID 0a78485b | Metis G81 | v1 first-cut 2026-06-16