How to Reduce Kilo Code Token Usage

You reduce Kilo Code token usage in two moves: route each request to the cheapest model that can handle it, then shrink what enters the context window before compaction ever has to step in. Kilo gives you unusually precise knobs for both, most of them in kilo.jsonc.

Part of the reduce AI coding agent token usage pillar. Still choosing between the two? Read opencode vs Kilo Code. This page is Kilo-specific: the settings Kilo documents, and what they leave untouched.

Why does Kilo Code burn tokens?

Because every agent step is its own request, and each request re-sends the system prompt, the tool definitions and the whole conversation so far.

Kilo's own cost controls page lists the drivers plainly: model choice, prompt and context size, the number of agent steps, retry loops, unattended tasks and session length. Every token in the system prompt, history, attachments and tool definitions "is billed as input".

The money model makes this hit harder than on a flat subscription. Kilo passes provider pricing through with no markup, plus a 5% payment-processing fee on credit purchases. With BYOK, you pay the provider directly. Either way, nothing absorbs your waste: a re-read file is a line on your balance.

Isn't this the same as opencode?

Close, but not identical, and the differences are exactly the cost knobs.

Kilo describes its CLI as a fork of OpenCode and maintains its own OpenCode-based distribution. The VS Code extension and the CLI share that runtime. So the shape of the problem matches how to reduce opencode token usage: stateless model, growing history, tool output carried turn after turn.

What Kilo adds is the part that matters here:

• Model routing tiers (Auto Frontier, Auto Efficient, Auto Free) through the Kilo Gateway.
• Documented compaction tuning in kilo.jsonc: a trigger threshold, pruning, a verbatim tail, and a separate compaction model.
• Spend guardrails: doom-loop pausing, per-tool approvals, spend alerts and organisation daily caps.

If you use plain opencode, the opencode page is the one for you. If you run Kilo, keep reading.

Which model should Kilo use?

Auto Efficient for everyday work, Auto Frontier only for architecture and hard debugging.

Kilo's Cost Efficiency & Model Selection page calls model choice "the single most effective way to control spend". Its Auto Model tiers route for you:

Auto Efficient is session-aware, per Kilo: it stays on one model across related turns and falls back to a fixed baseline when it can't decide. You switch tier from the model selector in the chat. No other configuration is needed.

Model choice also covers output. Kilo suggests keeping Code mode at 16k max output tokens or below and raising it only in Architect or Debug mode. Every output token you allocate is window space that history can't use.

How do you tune Kilo's compaction?

Leave auto-compaction on, set threshold_percent if you want earlier summaries, and hand summarisation to a cheaper model.

Kilo's Context Condensing docs describe two mechanisms. Compaction replaces older history with an anchored summary: goal, constraints, progress, decisions, relevant files. Pruning is lighter: between turns, it clears completed tool outputs that sit outside a 40,000-token recency window.

All of it lives in kilo.jsonc:

The compaction model is the knob most people miss. Without it, Kilo summarises with your session's model, which may be your most expensive one. In VS Code, the same setting is "Compaction model" under Settings → Models.

Two environment variables override the file: KILO_DISABLE_AUTOCOMPACT=1 and KILO_DISABLE_PRUNE=1. Both make context bigger. Use them to debug a lost-context problem, not to "keep more history".

One documented trap: custom models that don't declare a context window are not tracked, so auto-compaction doesn't run for them. If you plug in a custom endpoint, declare its window or run /compact yourself.

How do you keep files out of Kilo's context?

Mention files, not folders, and deny reads on anything generated.

Kilo's cost page is blunt about @folder: attaching one "sends every file in it as input tokens", even when one or two are relevant. Use @file with exact paths, and include the bug's file plus its closest dependencies only.

Kilo already skips node_modules, dist, build, .git, __pycache__, .cache and vendor. Add your own with a .kilocodeignore at the workspace root, or a deny rule in kilo.jsonc:

That is the cheapest token you'll ever save: one that never enters the window. A coverage report or a build bundle read by mistake gets re-sent on every following turn until compaction or pruning catches it.

Which other Kilo settings cut cost?

Four more, each documented by Kilo.

1. Architect mode for analysis. Kilo notes it cannot modify code, which makes it the cost-effective way to explore before committing. Get a plan, then switch to Code mode.
2. Disable unused MCP servers. Kilo's docs say this "significantly reduces the size of the system prompt sent with every request". That prompt rides along on every step.
3. Keep doom_loop at ask. It's the default: when the agent repeats a failing action, Kilo pauses and asks. Setting it to allow lets a stuck loop bill you indefinitely.
4. Watch the per-request estimate. Kilo shows an estimated cost per request in the chat history. If it climbs on a simple task, stop and look at what the agent is reading.

Prompt caching needs nothing from you. Kilo says it applies caching automatically on supported providers, with cache hits billed at a discounted rate.

For accounts, there are guardrails rather than savings. Spend alerts fire on a rolling limit or an hourly spike, and organisations can set per-user daily caps that reset at midnight UTC.

What do Kilo's settings leave on the table?

The content of tool results: whole-file reads and raw command output still arrive at full size.

Compaction and pruning act after the fact. A 3,000-token file read enters the window, rides along for several turns, and only then gets summarised or cleared. A failing test run arrives as thousands of tokens when twenty lines carry the diagnosis.

Routing lowers the price per token. It doesn't lower the count. And the 40K pruning window is generous: on a busy session, a lot of raw output stays live and billed before it ages out.

That gap is what Tokenade fills on Kilo. It installs as a plugin (~/.config/kilo/plugins/tokenade.ts) and folds every tool result before the model sees it, MCP included. It also writes a short rules file at ~/.kilo/rules/tokenade.md. On the open token optimizer benchmark, it cuts session cost by 39% on long sessions against running no tool at all.

What does Tokenade cover on Kilo Code?

Command output, web search, MCP results, code search, re-read dedup, documents and secret redaction are covered automatically. Context is partial.

The plugin sees each tool result, but not the outgoing request. So history isn't trimmed when the prompt cache expires. The compatibility matrix marks this Partial+: partial with the binary alone, full once the LLM proxy is set up for Kilo.

In practice that division of labour is clean. Tokenade shrinks what each tool returns. Kilo's compaction and pruning manage what's left as the session grows. The technical brief for agents is at tokenade.net/agents/kilo-code.md.

How to apply this today

1. Switch the model selector to Auto Efficient and keep Auto Frontier for architecture and debugging sessions.
2. Set a compaction model in kilo.jsonc or Settings → Models, so summaries don't run on your frontier model.
3. Add read deny rules or a .kilocodeignore for build output, coverage and fixtures.
4. Replace @folder mentions with @file mentions.
5. Disable MCP servers you don't use in this workspace.
6. Install Tokenade so tool results arrive folded. The tool-agnostic levers are in how to reduce AI coding agent token usage.

What goes wrong (anti-patterns)

Running everything on Auto Frontier. It's the right tier for hard reasoning and the wrong one for renaming a variable. Kilo's own docs tell you to start on Efficient.

Disabling pruning to "keep context". Old tool output then stays in the window until full compaction, billed on every turn. If the agent loses detail, narrow the task instead.

Treating compaction as prevention. A summary of a bloated session is still a summary you paid to produce, after paying for the bloat. Cut what enters first.

Leaving doom_loop on allow. Unattended loops are where small inefficiencies become a real invoice. The ask default exists for a reason.

FAQ

Is Kilo Code based on OpenCode?

Yes. Kilo describes its CLI as a fork of OpenCode and maintains its own OpenCode-based distribution, shared with the rebuilt VS Code extension. Cost habits carry over, but Kilo adds Auto Model routing, documented compaction tuning in kilo.jsonc and spend guardrails.

How do I make Kilo Code compact earlier?

Set compaction.threshold_percent in kilo.jsonc, for example 80 to compact at 80% of the model window. The reserved safety buffer still applies and can trigger compaction first. You can also run /compact manually at any time.

Does compaction itself cost tokens in Kilo?

Yes: the summary is written by a model call over your history. That's why Kilo lets you choose a separate compaction model, under Settings → Models or agent.compaction.model in kilo.jsonc. Point it at a cheaper model than your main one.

Does Kilo Code use prompt caching?

Yes. Kilo says it applies prompt caching automatically on supported providers, and cache hits are billed at a discounted rate compared with regular input tokens. No setting is required.

Does Tokenade work with Kilo Code?

Yes. tokenade install adds a Kilo plugin that folds every tool result, MCP included, plus a rules file. Context trimming is partial with the plugin alone and becomes full with the LLM proxy. Details are in the compatibility matrix.

See also:

• How to reduce AI coding agent token usage: the tool-agnostic pillar
• How to reduce opencode token usage: the upstream agent, with opencode stats
• opencode vs Kilo Code: which one fits your workflow
• Token-efficient MCP tool use: why idle tool manifests still bill