Every coding agent you run inside an IDE - Claude Code, Codex, Cursor - spends tokens before you type a single word. That spend is invisible. You see a chat box; underneath, the model is already reading a small book of instructions, tool schemas, and configuration that someone assembled on your behalf. The size of that book is your starting cost, and it has a direct effect on latency, on price, and on how much room is left for the model to actually think about your problem.
This post breaks down where those tokens go, segment by segment.
The one idea: standing tax vs metered
A model has a fixed context window - say 200k tokens. It is tempting to picture that as a big bucket you slowly fill over a long session. In practice it is a budget that is partly pre-committed before the conversation even starts.
Two kinds of cost live in that budget:
- Standing tax - loaded before the conversation begins and re-sent on every single turn, whether or not you use it. It is multiplied by every request in the session, so it crowds out the window before you have done anything.
- Metered - paid only when something is actually invoked or produced. It grows as you work, but you control when.
Optimizing context consumption is mostly one move: push things out of the standing column and into the metered one. Here is what each segment is.
System prompt
The agent's identity, safety policy, tool-use protocol, and output conventions - plus a dynamic environment block (working directory, OS, git status, date, model) spliced in per session. It is a structured document, not a blob: safety and identity go first so later text cannot override them, operational rules sit in the middle, and per-session context is injected at well-defined seams. This is also where instruction priority is set, which is why a skill that says "always use TDD" loses to your project's instructions that say "don't." Standing cost.
Tool definitions
Every callable tool ships a JSON schema - a name, a description, and typed parameters. The model needs all of it in context to call the tool correctly, and a tool you never touch this session still costs its full schema on every request. That pressure is why some agents defer tool loading: keep only the tool names in the standing baseline and fetch the full schema on demand, paying a round-trip only when the tool is actually relevant.
MCP servers
This is the line item that surprises people. Connect an external server - Linear, Playwright, a docs bridge - and it advertises its tools, every one of which is injected into your context as standing cost. Forty Linear tools plus twenty-five Playwright tools is thousands of tokens paid on every turn, even if you call one tool once.
Two things make MCP cost sneaky:
- It is not knowable from a config file. The tool definitions only exist once you launch the server and ask it for its tool list. The honest unit is "capacity cost per server," measured by launching and inspecting - not a number you can read off a setting.
- The cost is decoupled from use. A server you connected three weeks ago "just in case" is taxing every request today.
The flip side: MCP is the cost you chose, so it is the one you can take back. Disconnect an unused server and its whole schema set leaves the budget. When in doubt, prefer servers with a small, sharp tool surface - eight focused tools beat fifty overlapping ones, both on tokens and on the model's ability to pick the right one.
Memory and project instructions
Your project's instruction file, the memory index, recalled facts. The right structure mirrors skills: a lean index of one-line pointers loaded always, with detail files pulled in only when a specific memory is recalled. Keep the always-on part tight - it is multiplied by every turn like everything else in the standing column.
Invocable capabilities: skills, slash commands, subagents
Skills, slash commands, and subagents are mechanically the same animal, and they get the economics right through progressive disclosure:
- Names and descriptions are always loaded (standing) - the model can only choose a capability it can see.
- The full prompt body is deferred (metered) until you actually invoke it.
So a hundred installed skills cost a hundred one-line descriptions in the baseline - cheap
- and you pay the multi-thousand-token body only for the one you use. But progressive disclosure does not mean free: the description line is paid forever, on every turn, for every installed capability. Spend your words there carefully, and keep the body as long as it needs to be.
A note on plugins: a plugin is not its own line item. It is a container that bundles skills, slash commands, MCP servers, and hooks, which each land in the segments above. Counting "plugins" as a separate slice would double-count the wrapper and its contents.
Conversation and tool results
The baseline gets you to the starting line; tool results fill the rest of the window. A
single unfiltered cat of a large file, a sprawling git log, or a listing of
node_modules dumps thousands of tokens into the history - where it then re-rides every
subsequent request for the rest of the turn. A token you keep out of history is a token
you do not re-send next turn, so the savings compound. This is the dynamic-cost twin of the
MCP problem: noisy output is a tax you keep paying after the one moment you needed it.
What to actually do
- Prune MCP servers. Disconnect anything you are not using this week. Usually the single biggest standing-cost win, and invisible until you check.
- Measure, do not guess. You cannot eyeball MCP cost from a config file - launch the server, look at the tool list, count the tokens.
- Favor focused tool surfaces. Fewer, sharper tools beat many overlapping ones.
- Write tight descriptions, generous bodies. For every skill, command, and subagent, the description is the forever-cost; the body is pay-per-use.
- Keep memory lean. Index always-on, detail on recall.
- Filter noisy tool output. Keep the raw dumps out of history so you stop re-paying for them every following turn.
The throughline: know which tokens are standing and which are metered, and move things from the first column to the second. A lean baseline is not about doing less - it is about keeping the window clear so the model has room to work on the problem you actually care about.
Where Poco fits
Poco works both columns. On the metered side, it filters the noisy tool output - the big
cat, the long git log - before it lands in your history, so you stop re-paying for it
every turn. On the standing side, Poco's AI Discovery measures the footprint you carry into
every session: the MCP servers, skills, plugins, and subagents that make up your standing
tax, so you can see what each one actually costs and prune what you are not using.