Your AI Coding Bill Is Mostly Waste. The Config That Cuts It.

The first time I looked closely at where our AI tokens were going, I was annoyed for about an hour. Not because the bill was huge — because so much of it was waste. Tool schemas for tools the agent never called. The same 80,000 tokens of context re-read on every single turn. A long session that should have cost two dollars costing nine.

None of that is the model's fault, and none of it requires switching to a cheaper model. It's configuration. These are the Octomind settings I reach for on every project, what each one does, and roughly what it saves.

First, Find the Waste

You can't tune what you can't see. Inside any session, /info shows you exactly where the money goes:

/info

It breaks down input, output, cached, and reasoning tokens; cost per request and cumulative; estimated cache savings; and — once compression has kicked in — how many messages were dropped and how many tokens reclaimed. /report gives you the per-request version.

Read it once before you change anything. The two numbers that matter most: how much of your context is cached (cheap to re-read) versus uncached, and how much of every prompt is tool schema for tools you aren't using. Those are your two biggest levers.

Lever 1: Stop Paying for Tools You Don't Use

Every tool exposed to the model costs prompt tokens on every turn. A medium MCP server with ten tools adds roughly 2,000 tokens of schema to every request and every response. Bind five of those "just in case" and you're paying a multi-cent tax per turn before the agent does any work — and a bloated tool zoo also makes the model pick wrong tools more often.

Octomind's answer is capabilities — bundles of MCP servers that load only when you actually need them. The runtime embeds your message, matches it against each capability's hand-written triggers, and flips on the right one without burning an LLM routing turn. It's on by default:

auto_capabilities = true

Three things make this cheap instead of chaotic:

• It's deterministic. A small local embedding model scores your intent against triggers. No "do you need a database tool?" round-trip to the model.
• It's bounded. At most four capabilities stay active at once (MAX_ACTIVE_CAPS); activating a fifth evicts the least-recently-used one. Your tool surface can't grow without limit.
• It abstains when unsure. A margin gate means that when two capabilities are nearly tied for your intent, neither fires — so you don't get the wrong tools loaded on a coincidence.

The practical effect: instead of a 20-tool prompt on every turn, the model sees its baseline tools plus only what the current task needs. For CI or scripted runs where you want a deterministic surface, force-load exactly what you need at boot and skip the matching entirely:

OCTOMIND_CAPABILITIES=codesearch,filesystem octomind run developer:general

The full mechanism — triggers, thresholds, LRU eviction — is documented in Token Efficiency. The headline is simpler: you pay for the tools you use, when you use them.

Lever 2: Compress Context, but Only When It Pays

Long sessions fill up. The naive fix — summarize aggressively — can actually cost money, because compressing invalidates your prompt cache and forces a rewrite. Octomind's compression engine does the math first.

Before it compresses, it computes a net benefit: the cost of carrying full context through the remaining turns versus the cost of compressing now plus carrying the smaller context. If compressing would cost more than it saves, it skips. That single rule is why automatic compression on Octomind doesn't quietly bleed money the way a fixed "summarize every N messages" rule does.

The defaults are sensible, driven by token-pressure levels:

max_session_tokens_threshold = 200000

[[compression.pressure_levels]]
threshold = 60000
target_ratio = 2.0    # light: 50% reduction

[[compression.pressure_levels]]
threshold = 120000
target_ratio = 4.0    # medium: 75% reduction

Two knobs you'll actually touch:

• Compression triggering too often on short sessions? Raise the first threshold (say, 75,000) or empty pressure_levels entirely.
• Sessions sometimes blow past the window? max_session_tokens_threshold is the hard ceiling — when context hits it, compression is forced unconditionally regardless of the cost math. Keep it set.

Watch it work with /info, which shows cumulative tokens saved. The full model — adaptive ratios, the exponential cooldown that prevents compression loops, knowledge retention across compressions — lives in the Compression doc. It's the same machinery that keeps a multi-hour session from rotting; we wrote about that failure mode in What Is Context Rot.

Lever 3: Don't Pay Sonnet Prices to Decide on Compression

A subtle one: every time Octomind considers compressing, it asks a model to make the decision and write the summary. If that's your main expensive model, you're paying premium rates for housekeeping. So it's configured separately, and the default is deliberately cheap:

[compression.decision]
model = "openai:gpt-5-mini"

openai:gpt-5-mini is the shipped default; anthropic:claude-haiku-4-5 is a fine alternative. The point is that your coding model and your compression-decision model are two different choices. Keep the smart, pricey model for reasoning about code and hand the bookkeeping to something that costs a fraction of a cent per call.

The same logic extends to sub-agents: if you delegate context-gathering or simple grunt work to a sub-agent, give it a cheap, fast model in its role config. You don't need your best model to list files.

Lever 4: Caching Is Free Money on Anthropic

If you run Anthropic models (directly or routed through OpenRouter), prompt caching is automatic — your system prompt, tool definitions, and prior turns get reused at roughly a tenth of the input cost. Nothing to configure; it's always on.

There's one opt-in extra worth knowing for long, bursty sessions. When you walk away and come back, the cache may have gone cold, and the next turn pays full price. Cache keepalive pings the provider during idle time to keep it warm:

cache_keepalive_enabled = true
cache_keepalive_max_idle_seconds = 1800

It's Anthropic-only (other providers cache server-side and can't be pinged), and the pings themselves cost a trickle of cache-read tokens — so enable it when you regularly leave sessions idle and resume them, not for quick one-offs.

Lever 5: Set a Hard Ceiling and Sleep Better

Tuning saves money on average. Spending limits save you from the worst case — a runaway loop, a pathological task, a 2 a.m. background job that won't quit. Two limits, in plain USD:

max_session_spending_threshold = 5.0   # stop a session at $5
max_request_spending_threshold = 1.0   # reject any single request over $1

0.0 means no limit. I set these on anything unattended. They're the difference between "huh, that session was pricier than I expected" and a bill that makes you open a support ticket.

The Five-Minute Version

If you do nothing else, do this:

1. Run /info and look at cached-vs-uncached tokens.
2. Leave auto_capabilities = true — don't statically bind servers you rarely use.
3. Keep max_session_tokens_threshold set so context never runs away.
4. Confirm [compression.decision].model is a cheap model, not your coding model.
5. Set max_session_spending_threshold on anything that runs unattended.

None of this touches the model doing your actual work. You keep the smart model for the smart work, and stop paying it to find files, re-read stale context, and decide on its own housekeeping. On a typical day of real coding, those five settings are the gap between a bill that surprises you and one that doesn't.

Want the cheaper-model angle too? We made the case for routing different work to different models in DeepSeek V4 Is 98% Cheaper Than GPT-5.5. Configuration and model choice compound — do both.

Get Octomind — and run /info on your next session. You'll see exactly what I mean.