How to Reduce Droid Token Usage

Part of the reduce AI agent token usage pillar. Comparing terminal agents? See the Qwen Code and Grok CLI versions. This page is about Factory's Droid CLI, the droid command.

How do you reduce Droid token usage?

Look at /context and /cost, lower compactionTokenLimit so compaction fires sooner, give compaction and light subagents a cheaper model, set reasoningEffort per task, and keep side questions out of the transcript with /btw. Then fix what enters the conversation: files and command output.

Droid has an unusually complete settings file for this. Compaction threshold, compaction model, per-tier subagent models, spec-mode model: each has its own key. What none of them does is shrink a tool result before the model reads it. That's still the biggest line item in most sessions.

Sources: settings and commands were read in Factory's Droid settings reference and CLI reference on 14 October 2026. Tokenade's figure comes from the open token optimizer benchmark.

Why do Droid tokens matter even on a subscription?

Because Factory meters usage in rolling windows, and tokens are what fill them.

Factory's individual plans page describes three rolling rate-limit windows, 5-hour, 7-day and 30-day, each running independently. Standard Usage is consumed first; after that, Droid Core models draw from a separate pool, and Extra Usage is prepaid credit. The same page links to a model catalog with multipliers that drive usage costs.

So a wasteful session doesn't just cost more. It brings the next rate-limit wall closer. If you bring your own key, Factory says BYOK is free up to an allowance on all individual plans, then charged according to your plan.

The mechanics underneath are the usual ones. Each turn re-sends the conversation, including every file read and every Execute result. A test log read at turn 4 is paid again on every later turn until compaction drops it.

How do you see where Droid's tokens go?

Four commands, from the current window to your plan.

• /context shows the context window usage breakdown with a progress bar.
• /cost shows usage statistics.
• /stats [period] shows usage over relative periods or date ranges.
• /limits manages token usage limits and overage preferences; the plans page points to it for monitoring.

For a running view, set showTokenUsageIndicator to true in ~/.factory/settings.json. It adds a live token usage indicator at the bottom of the input, which is the cheapest way to notice a session ballooning while it happens.

Which built-in settings actually cut the bill?

Four keys in ~/.factory/settings.json, in rough order of return.

1. compactionTokenLimit. The token threshold that triggers automatic compaction. The default is model-dependent. Lower it and less history rides along; compactionTokenLimitPerModel overrides it model by model.
2. compactionModel. same uses the session model to write the summary. Point it at a cheaper model and every compaction costs less.
3. subagentModelSettings. Subagents are routed by complexity tier. lightModel covers light work, such as the built-in explorer; mediumModel covers tiers like the built-in worker. Both inherit the session model by default. A cheaper light model is the easiest win here.
4. reasoningEffort. It sets how much structured thinking the model does, from off to max depending on the model. Factory's docs give per-model defaults: Claude Opus 4.8 defaults to high, Claude Sonnet 4.5 to off.

On a Factory plan, there's also Droid Core: a free pool of open-weight models with its own rate limits. Factory's own advice is to run Missions on Droid Core when possible.

Should you start Droid sessions in Spec Mode?

For anything bigger than a small fix, yes: a plan you approve is cheaper than an implementation you steer.

sessionDefaultSettings.interactionMode decides whether new sessions start in Auto or Spec Mode; droid exec --use-spec does the same for a headless run. In Spec Mode, Droid plans before it executes, and you can give that step its own model and effort with specModeModel and specModeReasoningEffort.

The token argument is about failure, not planning. Correcting an implementation mid-flight re-sends the whole failed attempt on every turn of the repair. Correcting a plan is a short exchange before any file has been touched.

Which commands keep a Droid session lean?

The ones that keep the transcript short, not just the ones that summarise it.

• /btw <question> asks a side question without polluting the main transcript. Every off-topic question you'd otherwise type is a block re-sent on each later turn.
• /compress [prompt] compresses the session and moves to a new one with a summary. The optional prompt says what the summary should keep.
• /clear clears the conversation but keeps your current model and autonomy. /new starts fresh and resets both to defaults.
• /fork copies the session into a new one, so you can try a risky direction without dragging its dead ends back into the main thread.

In headless runs, droid exec accepts --disabled-tools and --restrict-tools. Fewer tools means fewer tool definitions in each request, and less temptation for the agent to wander.

One setting looks like a saving and isn't: toolResultDisplay: "compact". It changes how tool results render in your transcript, not what the model receives.

What do Droid's settings leave untouched?

The content of tool results: files read, Execute output, MCP responses.

Compaction is damage control. By the time compactionTokenLimit is reached, a 2,000-line build log has already been re-sent on every turn since it arrived. A cheaper compaction model makes the clean-up cheaper; it doesn't stop the mess.

That's where Tokenade works. On Droid, tokenade install adds hooks to ~/.factory/hooks.json: PreToolUse and PostToolUse on Execute, plus SessionStart, UserPromptSubmit and PreCompact. Shell output reaches the model folded to its decisive lines. It also writes its rules to ~/.factory/AGENTS.md and wraps the servers in ~/.factory/mcp.json.

Droid is one of the agents with a full row in the compatibility matrix: command output, web search, MCP results, code search, context, re-read dedup, documents and secret redaction are all covered automatically. No proxy needed. The full brief is at tokenade.net/agents/droid.md.

On the open token optimizer benchmark it cuts session cost by 39% on long sessions against running no tool at all. That campaign ran on Claude Code, not Droid: the mechanism is the same, the measurement isn't.

How to apply this today

1. Turn on showTokenUsageIndicator and run /limits to see where you stand in each window.
2. Lower compactionTokenLimit, and set compactionModel to a cheaper model.
3. Set subagentModelSettings.lightModel so exploration doesn't run on your most expensive model.
4. Pick reasoningEffort per task instead of leaving the deepest level on.
5. Use /btw for side questions and /new when the task changes.
6. Then fix what enters the chat: install Tokenade.

What goes wrong (anti-patterns)

Asking side questions in the main thread. Each one is re-sent until the session ends or compacts. That's exactly what /btw is for.

Letting subagents inherit the top model. The default is inherit. An explorer reading files on your most expensive model is the costliest way to grep.

Treating compaction as the fix. It shortens history after the damage. The log was paid for on every turn before it.

Setting toolResultDisplay to compact and calling it done. Your terminal looks tidier. The request is the same size.

FAQ

How do I check token usage in Droid?

Run /context for the current context window, with a progress bar, and /cost for usage statistics. /stats covers longer periods, and /limits shows where you stand against your plan's limits. Setting showTokenUsageIndicator to true in settings.json adds a live token counter under the input.

How do I change when Droid compacts?

Set compactionTokenLimit in ~/.factory/settings.json; it's the token threshold that triggers automatic compaction, with a model-dependent default. Use compactionTokenLimitPerModel for per-model values, and compactionModel to choose which model writes the summary. You can also compact by hand with /compress, optionally with a prompt saying what to keep.

Do Droid subagents use the same model as my session?

By default, yes. subagentModelSettings routes subagents by tier, light, medium and heavy, and each tier inherits the session's model unless you pin one. Setting a cheaper lightModel moves light work such as the built-in explorer off your main model. A custom droid with its own model bypasses this routing.

Does /btw save tokens in Droid?

It keeps them out of the main conversation. /btw asks a side question without polluting the main transcript, so the question and its answer aren't re-sent on every later turn of your task. For a quick lookup in the middle of a long session, that's cheaper than asking inline.

Is Tokenade compatible with Factory Droid?

Yes, fully. tokenade install wires Droid through hooks in ~/.factory/hooks.json, writes rules to ~/.factory/AGENTS.md, and wraps the MCP servers in ~/.factory/mcp.json. Every feature in the compatibility matrix is covered automatically on Droid, with no LLM proxy required.

---

See also:

• How to reduce AI agent token usage — the tool-agnostic pillar
• How to reduce Grok CLI token usage — xAI's terminal agent
• How to reduce Claude Code token usage — the same levers on Claude Code
• Reduce tokens in long sessions — why the history compounds