Spending fewer output tokens

The last post established that the answer is the bill: about 98% of a typical call's cost is what the model writes back, not the prompt you sent. This one is the practical follow-up — what actually reduces that number, what only appears to, and how skills and plugins fit in.

Where an output token actually comes from

Before cutting, know what you are cutting. A billed output token is one of three things, and they respond to completely different controls.

Thinking tokens are billed and you never see them. Tool-call arguments are billed — a model that writes a 40-line JSON payload pays for all of it. The visible answer is often the smallest of the three on agentic work.

That split explains why the obvious lever usually disappoints. If your bill is mostly thinking and tool calls, telling the model to "be concise" trims the part you were already looking at.

The levers, in order of leverage

Effort first. output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"} is the dial that governs both how deeply the model thinks and how many tool calls it makes. It defaults to high. Lower effort means fewer and more-consolidated tool calls, less preamble, and terser confirmations — it moves all three token categories at once, which nothing else does.

The counterintuitive part: on the newest models, dropping effort often costs less quality than you would expect. Anthropic's own migration guidance for Claude Opus 5 says low and medium are unusually strong there and recommends sweeping downward from the default rather than assuming the top setting is correct. Effort settings carried over from an older model are rarely the right ones.

Then the prompt — for the visible part only. A short conciseness instruction is measurable but bounded:

Roughly a fifth off the user-facing text. Worth doing, and not a substitute for the effort dial.

Two prompt-level habits are worth more than the wording:

• Delete your verification scaffolding. Instructions like "double-check your answer" or "add a final verification step" were good advice on older models and are now a tax: current models verify their own work unprompted, and telling them to do it again buys a second pass you pay for. This inverts a standard prompting rule, so a prompt library that applies it uniformly needs a carve-out.

• Cap delegation. Subagents multiply cost — each one re-establishes context, explores, reports back, and then the coordinator reads the report. Claude Opus 5 reaches for them readily, so an explicit ceiling ("never more than N in parallel", "don't delegate work you could finish in a handful of tool calls") is a real saving on agentic harnesses.

The two caps are not the same thing

This is where money gets wasted through a misunderstanding.

max_tokens is a hard ceiling that the model cannot see. It does not encourage economy; it truncates. Hit it and you get a half-finished answer plus stop_reason: "max_tokens", and you pay for every token generated on the way to being cut off — then usually pay again on the retry.

task_budget is the opposite: a ceiling the model is aware of. The server injects a countdown the model reads while working, so it prioritises and wraps up gracefully instead of being guillotined. It applies to a whole agentic loop rather than one response, and the minimum is 20,000 tokens. It is beta, behind the task-budgets-2026-03-13 header, and it goes inside output_config alongside effort.

Use max_tokens as a safety rail against runaway generation. Use task_budget when you actually want the model to spend less.

What does not save anything

Hiding the thinking. This one costs people real money because it feels like it should work:

Setting display: "omitted" removes reasoning from what you receive. It does not remove the reasoning, and the tokens are billed identically. If you want less thinking, lower the effort — that is the only control that reduces it.

Streaming is the same story from a different angle: it improves perceived latency and avoids HTTP timeouts on large outputs, and it changes the bill by exactly zero.

Don't generate the tokens at all

The largest savings are architectural rather than parametric.

Programmatic tool calling. Normally each tool call is a round trip: the model calls, the result lands in its context, it reasons, it calls again. With programmatic tool calling the model writes a script instead; the script calls the tools, processes the results with ordinary control flow, and only its final output returns to the model. Token cost scales with that final output rather than with every intermediate result — on a loop that reads twenty files and needs three facts, the difference is not marginal.

Structured outputs. Constraining the response to a JSON schema via output_config.format removes the preamble, the explanation, and the closing offer to help. If you are parsing the answer anyway, you were paying for prose no code ever read.

The Batch API. 50% off all token usage — input and output — if the work tolerates asynchronous completion. Most classification, extraction, and enrichment pipelines do.

Skills: pay for instructions only when they are used

A skill is a SKILL.md file: YAML frontmatter with a description, then the instructions. The economics are in how it loads. Only the description sits in context by default; the body loads when Claude decides the skill is relevant. As the documentation puts it, a skill's body loads only when it's used, so long reference material costs almost nothing until you need it.

That makes skills the correct home for anything long that is only sometimes relevant. A deployment checklist pasted into CLAUDE.md is paid for on every single turn of every session. The same checklist as a skill is paid for on the turns that deploy.

Where they live:

• Personal, across all your projects: ~/.claude/skills/<name>/SKILL.md

• Project, committed with the repo: .claude/skills/<name>/SKILL.md

A skill also becomes a slash command with the directory's name, so .claude/skills/deploy/SKILL.md gives you /deploy.

Plugins: skills you can install

A plugin is a shareable bundle — skills, subagents, hooks, MCP servers, and more — with a manifest at .claude-plugin/plugin.json. Installing one:

Concretely, to add Anthropic's community marketplace and install from it:

/plugin marketplace add anthropics/claude-plugins-community
/plugin install

claude-plugins-official, Anthropic's curated marketplace, registers itself the first time you start Claude Code interactively.

To develop one rather than install one, claude plugin init my-tool scaffolds a plugin under ~/.claude/skills/my-tool/ that loads automatically on the next session. To test a plugin without installing it, claude --plugin-dir ./my-plugin loads it for that session only. Plugin skills are namespaced — /my-plugin:hello rather than /hello — so two plugins can ship a skill with the same name.

The relevance to this post: a plugin is a distribution channel for the prompt-level savings above. An output-style skill that enforces terse answers, a review skill that stops the model re-verifying, a delegation policy that caps subagents — write it once, install it everywhere, and it applies without anybody remembering to paste it.

The order to work in

Set effort deliberately, per route, and sweep it rather than inheriting a number from an older model. Add a conciseness instruction and delete your verification scaffolding. Cap delegation if your harness has subagents. Reach for task_budget on agentic loops and keep max_tokens as a rail, not a budget. Then look at whether the tokens need to be generated at all — programmatic tool calling, structured outputs, batch.

And do not spend an afternoon hiding the thinking. It is billed either way.