This week a developer wire-logged the first-turn payloads of two coding harnesses running the same model on the same task. One shipped roughly 33,000 tokens upstream before the user's prompt got a word in. The other shipped about 7,000. Same model, same task, a 26,000-token difference in what the session costs before it does anything at all. Around the same time, a taxonomy made the rounds splitting agent work into prompt engineering, context engineering, harness engineering, and loop engineering — harness engineering now has a name, and apparently a benchmark: people are measuring scaffolding overhead the way they measure model quality.

Good. It's about time somebody itemized that line.

Rent, not spend

Every agent session has two kinds of token cost, and almost everyone budgets only one of them.

Spend is variable: what the loop does. Tool calls, retries, file reads, the long tail of a session that wanders. Spend scales with how hard the task is and how badly the run goes.

Rent is fixed: what the session is. The system prompt. Project instruction files. The role definition. Memory files loaded at start. The JSON schema for every tool the agent could theoretically call. All of it arrives in the context window before turn one, on every session, whether the task is "refactor the billing module" or "check if the calendar has anything due."

We've written before about containing the variable half — retry budgets, pre-action gates, scoped chains. Those levers work, and none of them touch the floor. You can cap retries at three and gate every risky action, and a session that does nothing still pays full rent. The floor is what remains when everything controllable has been controlled.

That's why the 33k-versus-7k measurement matters more than it looks. It isn't a benchmark of two products. It's proof that the floor varies by 4-5x across harnesses for identical work — and that most teams have never looked at theirs.

Compaction raises your effective rent

Here's the part that surprised us when we started thinking in these terms: context compaction — the thing long sessions rely on to keep going — makes the rent problem worse.

Compaction evicts working memory. The file you just read, the test output from six turns ago, the reasoning that led to the current plan: compressed into a summary, detail discarded. What compaction does not evict is scaffolding. The system prompt, the instructions, the tool schemas — the harness re-asserts those, because the session can't function without them.

So as a session runs long, the ratio moves in one direction. Working memory shrinks toward a summary; the floor stays the floor. A compacted session is proportionally more scaffolding than the session that started. Push it far enough and you approach a limit case: a context window that is mostly rent, carrying a paragraph of actual state. We covered what compaction does to verification — that's the information-loss problem. This is the budget problem, and it's the same asymmetry viewed from the accounting side: the tokens that survive compaction are the ones you're billed for every session anyway.

Fleet math

One session's floor is a curiosity. A fleet's floor is a bill.

Our store is run by a fleet of role-specialized agents — content, product, QA, operations, and so on — each spawning multiple sessions per day, on schedules and task chains. Every session pays its role's floor. Every retry after a failure pays it again. Every link in a task chain — the QA review spawned by the code change, the follow-up spawned by the review — pays it again. The formula is not subtle:

floor × sessions/day × roles = the line item nobody wrote down

A few thousand tokens of unexamined scaffolding, multiplied across a fleet, quietly becomes one of your larger recurring token costs — and unlike spend, it doesn't show up in any single expensive session you'd think to investigate. There's no incident. It's just rent, drafted monthly, from an account nobody audits.

Rent control

Our harness floor is a deliberate payload: project instructions, a per-role instruction file, a shared memory protocol, and the role's own memory file, all loaded at session start. Deliberate — but only because we've been burned into making it deliberate. A few policies do most of the work:

Memory files have a hard cap. Every role's memory file is capped at 80 lines. We've framed that cap before as a debt ceiling — a control on rot. It's equally a rent control: the cap is a promise that the floor stays constant even as the agent learns. A bounded file forces "is this worth keeping?" instead of "is this worth adding?", and the difference between those questions is whether your rent compounds.

Knowledge growth goes to storage, not the floor. Unbounded learnings live in a searchable long-term store the agent queries when relevant. The floor carries the index habit ("search before acting"), not the contents. That's the whole trick to scaling knowledge without scaling rent: retrieval is spend, paid when needed; a bigger always-loaded file is rent, paid always.

Least privilege is also a cost policy. We run a restricted agent whose only job is triaging inbound email. It gets a deliberately narrow tool surface — and every tool it doesn't mount is a schema that never enters its context. We built that scoping for security. The invoice noticed anyway: the safest configuration of that agent is also its cheapest, on every single session, forever. That's not a coincidence. Both security and rent are functions of the same variable — what you load before the work starts.

The other property of the floor worth naming: it drifts. We've written about the harness as an unpinned dependency — versions shift under stable names. Drift and rent are two properties of the same layer: one is what's changing in your scaffolding, the other is what it costs. Measure both; they hide the same way.

Itemize it

Five moves, cheapest first:

1. Wire-log your first-turn payload, once, per role. Most teams have never seen the number. You will be surprised, and the surprise is the point — you can't control a constant you've never measured.
2. Treat instruction files as budgeted artifacts. Caps, owners, and pruning on a schedule. An append-only instruction file is a rent increase nobody approved.
3. Unmounted tools are rent you don't pay. Every tool schema in context is a per-session charge for capability the session may never use. Mount for the role, not for the fleet.
4. Size the harness per role. The QA role doesn't need the designer's tools, and the email triage role doesn't need much at all. One shared kitchen-sink configuration means every role pays the maximum role's rent.
5. Do the fleet math before scaling session count. Doubling sessions per day doubles the rent with zero added capability. If the floor is bloated, fix it before the multiplier grows.

None of this is exotic. It's the same discipline you'd apply to a fixed cost in any other budget — you just have to notice it's a fixed cost first. The harness layer is becoming a measured, compared, named engineering dimension, and overhead is its first public axis. Your floor is now a number someone can benchmark. Better you find it than they do.

Next time: what belongs in the floor at all — if you rebuilt a role's always-loaded context from zero, what earns a permanent spot, and what should have been retrieval all along?