Your AI Coding Seat Bills You Before You've Asked It Anything | Edition 330

A manager approves an AI coding seat for the team — Claude Code, Cursor, an agent subscription — and the bill that shows up a month later is bigger than the sticker price suggested. Ask why, and the usual answer is “the AI wrote a lot of code.” That's rarely the real story.

The real story is standing overhead: instructions that load before the agent has read a single word of the actual question, tool definitions that ride along on every request whether or not they get used, commands that dump pages of output back into the conversation, and scheduled jobs that pay the full cost of waking up on a timer. None of this is a bug. It's how these products are built to work — and it's a line item almost nobody has looked at directly, because it never shows up as a separate charge. It's baked into every request.

What you're actually paying for

Every message sent to an AI coding agent carries more than the message. Before the model reads the prompt, it reads everything the product loaded to set up the session — and that load happens again, in full, more often than most people paying for the seat would guess.

1. Config files that load before anything is typed

Claude Code's own documentation is direct about this: CLAUDE.md — the project instruction file teams write once and expect to sit quietly in the background — is “loaded into the context window at the start of every session, consuming tokens alongside your conversation.” That's not a one-time setup cost. It's paid again at the start of every session, and Anthropic's own context-window documentation lists it, alongside “auto memory, MCP tool names, and skill descriptions,” among the things that load in before you type anything.

Cursor runs the same pattern under a different name. Its documentation describes rules marked “Always” as included in model context on every request — not once per project, every time. A team that has stacked several always-on rule files gets a specific, ongoing outcome: that whole stack rides along on every single message, whether the task in front of the agent needs any of it or not.

2. Tools that are connected but never called

Connect a tool to an agent — a database, a ticketing system, an internal API via MCP (the Model Context Protocol) — and its definition doesn't wait to be used before it costs something. Anthropic's Claude Code documentation places “MCP tool names” in the same before-you-type-anything bucket as CLAUDE.md: they load into context at the start of the session, full stop. A connector added for one project six months ago and never removed is still riding along on every request today, whether or not the agent ever reaches for it.

3. Automated output that talks back — and isn't trimmed by default

Modern coding agents can run their own follow-up scripts after an action and route the result back into the conversation — a lint pass, a test suite, a build. Claude Code documents a specific hook for exactly this moment (its PostToolUse event fires right after a tool runs), and it does cap some of what a hook can add back: a hook's supplementary note to the model is capped at 2,000 characters per tool call, and very long strings get middle-truncated past 10,000 characters.

What isn't trimmed by default is the thing that actually floods a conversation: the raw output of the command itself. A default npm install, a bundler build, a test run with a progress bar — none of that is filtered automatically. Every line becomes something the model has to read, and something the seat holder pays to have it read, on every run, unless someone has deliberately set up a filter. That gap is what this edition's fix, below, is built to close.

4. Scheduled jobs that start over, every time

Recurring automation is usually sold as the efficient version of a task — check the deploy every 15 minutes instead of babysitting it by hand. But “recurring” and “cheap” aren't the same claim. Claude Code's own scheduling documentation draws a sharp line between its ways of running work on a timer: a cloud-hosted scheduled task has “no access to local files” because each firing is a fresh clone — unlike a desktop task or an in-session loop, which can inherit an existing setup. A fresh clone means the full startup load — config files, connected-tool definitions, all of it — gets paid again at every firing, not once. A job checking in every 15 minutes doesn't pay that startup cost once a day. On that schedule, it pays it roughly 96 times.

The four-question audit

None of this requires reading logs or pulling in an engineer to instrument anything. Before approving or renewing an AI tooling seat for a team, ask four questions — and expect a real answer to each one.

1. What loads on every single request, before the agent has read anything typed into it? This is the config-file tax — CLAUDE.md, Cursor's “Always” rules, whatever the product calls its persistent instructions. It costs money because it's billed as part of every request's input, not once when the project is set up.
2. What's connected that almost nobody actually uses? Every MCP server or tool integration ships its definition with every request whether it gets called or not. It costs money the way a forgotten subscription does — quietly, every cycle, for something nobody's touched in months.
3. What does the agent run automatically that dumps its output back into the conversation? Install logs, build output, test runs — none of it is trimmed unless someone built a filter. It costs money because the model has to read pages of noise to find the few lines that mattered, and every line it reads is billed.
4. What repeats on a schedule, and does it start over each time? A recurring job that runs as a fresh instance pays the full config-and-tools tax on every firing, not once. It costs money in direct proportion to how often it fires — a 15-minute interval is a very different bill than a nightly one, even though both look like “one automation” on a dashboard.

The one fix worth making first

Of the four, the third is the one that can be acted on this afternoon without touching anyone else's workflow: stop the agent's own tooling from flooding its context with output nobody reads.

The mechanism, in plain English: a small filter sits between the agent and the commands it runs. It watches for the noisy ones — installs, builds, test runs, anything that would normally scroll pages of progress output — and keeps only what a person would actually read afterward: errors, failures, and the final summary line. A short command that already prints two lines passes through untouched; there's nothing to filter.

Where this is actually possible today, by name. Claude Code's own hooks reference documents a PostToolUse hook field called updatedToolOutput, which “replaces the tool's output with the provided value before it is sent to Claude” — for any tool, not a special case. A companion field on the earlier PreToolUse hook, updatedInput, can rewrite the command itself before it ever runs — for example, routing it through a filtering script — which is the other legitimate way to build this. Both are documented, current capabilities of this one product.

Cursor has an equivalent-sounding hook, but the fine print doesn't match. Its documented field for replacing a tool's output after the fact — updated_mcp_tool_output — is explicitly scoped: “For MCP tools only.” It does not cover Cursor's own Shell tool, which is exactly where noisy installs and builds actually run. On Cursor, don't assume this specific trick ports over for shell output — the vendor's own documentation says otherwise. (Cursor's preToolUse can still rewrite a command before it runs, the same pre-execution route described above, so the fix isn't closed off there — it just isn't the same mechanism.)

What this doesn't do. Both vendors are explicit that rewriting output changes only what the model sees, not what happened — the install already ran, the build already completed, any files it wrote are already on disk by the time a filter runs. This is a context-budget fix, not a safety control. And Claude Code's documentation is blunt about the mechanism generally: hook scripts “execute shell commands with your full user permissions” and can modify, delete, or access anything the account can — a real reason to read a filter script before installing it, the same as any other code that touches a machine. It's also worth building the filter to protect, not just trim: keep exit codes and failure text intact, because a filter that swallows a non-zero exit to save space is worse than the noise it removed.

Is it worth a number? We looked for a sourced savings figure and didn't find one — no vendor publishes “installing an output filter cuts your bill by X percent,” and this edition isn't going to invent one. What's verifiable is the mechanism and the shape of the effect: a noisy command that used to hand the model several thousand characters of scrolling progress output now hands it a handful of lines. How much that's worth in any specific bill depends on how noisy the commands actually are.

The habit worth keeping regardless of which fix gets tried: don't take an agent's word that it installed something correctly. Make it prove it — have it run one real noisy command before the change and the same command after, and put both outputs side by side. That's the part of this idea that generalizes past output filtering: any time an AI is asked to change its own configuration, the demonstration is the only evidence that actually means anything.

Where this fits

This is the agent side of a three-part look at where an AI budget actually goes before it reaches the actual question. A companion edition in this series covers the same before-you-ask overhead from the consumer side — the custom instructions and saved-project setup behind a chatbot, not an agent seat. Another covers the per-token pricing and caching arithmetic underneath all of this. Neither is this edition's material to re-explain, and this one stays out of both — read them separately for the rest of the picture.

None of this is an argument against paying for the seat. It's an argument for looking at what's already being paid for before renewing it — or before approving another one for someone else on the team.