# AI Coding Token Usage by Task Type > Inline completion costs hundreds of tokens; a single agentic coding task burns 1–3.5 million. Here is the per-task-type breakdown, with sources, so you know which work actually moves your bill. Source: https://tokenade.net/en/stats/token-usage-by-task-type · Updated: 2026-10-16 If you bill your AI coding agent by the token, the single most useful thing you can know is which kind of work spends the money. An inline completion costs you a few hundred tokens; the same model running an agentic task on the same repo can burn one to three and a half *million* tokens per task. That is not a rounding error — it is the difference between a rounding error and a real invoice. I build token-reduction tooling for a living, and the recurring surprise for teams is always the same: the work that *feels* expensive (long answers, big files) is rarely where the tokens go. The tokens go into context the agent re-reads on every turn, into tool schemas carried on calls that never use them, and into the loop tax of multi-step tasks. This page collects the per-task-type numbers from real sources so you can reason about your own bill instead of guessing. All figures are quoted as of mid-2026 and should be re-verified at the primary source before commercial use. ## Key takeaways

Token cost by task type, at a glance

## 1. How many tokens does a single inline code completion use? A single inline completion runs roughly **550–2,500 total tokens** — a few hundred input, a few hundred output — according to Iternal's 2026 use-case cost profiles. [1] This is the floor for AI coding. Completion is a short prompt (the surrounding code) and a short response (the next few lines), so it stays cheap even at high frequency. The catch is volume: a developer accepting suggestions all day fires thousands of these, and editors often send a fresh context window with each keystroke pause. The per-event cost is trivial; the daily aggregate is not. If completion is most of your usage, the lever is caching the stable file prefix, not shortening answers — output is already tiny. For the underlying unit, see the glossary on the [token](https://tokenade.net/en/glossary/token) and the [context window](https://tokenade.net/en/glossary/context-window). ## 2. How many tokens does a code explanation or review cost? A code explanation runs **800–4,000 tokens** and a single-file code review **2,500–12,000 tokens**, per the same 2026 profiles. [1] These are still "read a bounded thing, write a bounded answer" tasks, so they sit an order of magnitude above completion but nowhere near agentic territory. The cost driver here is how much code you stuff into the prompt: review the whole file and you pay for the whole file every turn. Code, incidentally, tokenizes worse than prose — roughly **1.5–2.0 tokens per word** versus prose's approx 0.75, because of brackets, identifiers, and punctuation. [1] A 1,000-line file is around 10,000 tokens before the model says anything. Why that ratio happens is a [tokenizer](https://tokenade.net/en/glossary/tokenizer) question, not a model one. ## 3. How many tokens does a bug-debugging prompt use? A one-shot bug-debugging prompt costs **1,500–7,000 tokens**, but a complex debugging *session* with a frontier model can consume **500,000+ tokens**. [1] This is where task-type accounting gets slippery. "Debug this" as a single question is cheap. "Debug this" as an agent that reads ten files, runs the tests, reads the failure, and tries again is a different animal — the loop, not the prompt, sets the cost. The jump from 7K to 500K isn't the model getting verbose; it's the number of turns, each one re-sending the accumulated context. That re-sending is exactly what [output filtering](https://tokenade.net/en/glossary/output-filtering) and [context compression](https://tokenade.net/en/glossary/context-compression) attack: keep the signal the agent needs across turns, drop the rest. ## 4. How many tokens does one agentic coding task burn? An agentic coding task in the SWE-bench class averages **1,000,000 to 3,500,000 tokens per task**, including retries and self-correction loops. [1] A 2026 systematic study across eight frontier LLMs on SWE-bench Verified puts the gap even more starkly: agentic tasks consume **1,000× more tokens** than code reasoning and code chat, and it is input tokens — not output — that drive the bill. [2] This is the line item that matters. Three orders of magnitude separate a completion from an agentic task, and that gap is structural: every tool call ships its schema, every turn re-reads context, every wrong path costs a full round trip. Input tokens dominate — in agentic workloads they vastly outnumber output tokens, so the price of what the model *reads* is the price of the session. This is the mechanism I keep coming back to in [agentic coding](https://tokenade.net/en/articles/agentic-coding): the bill is a context-management problem wearing a reasoning costume. ## 5. How much does the same agentic task vary run-to-run? The identical agentic task can vary by **up to 30× in total tokens** across runs, per the 2026 study of eight frontier LLMs on SWE-bench Verified trajectories. [2] Critically, higher token usage does not translate into higher accuracy: accuracy often peaks at intermediate cost and saturates or even declines at higher costs. GitHub's own engineering team reported the same pattern in production: a workflow that normally finishes in four LLM turns occasionally takes eighteen, and a single run may handle a five-line fix while the next handles a 200-line pull request — raw token counts tracking the *path the agent took*, not the difficulty of the problem. [3] The practical consequence: per-task budgets are inherently noisy, so the durable win is cutting the per-turn floor (less context, fewer tool schemas) rather than chasing a clean per-task number that doesn't exist. ## 6. How much of agentic token spend is just re-reading context? On one production GitHub workflow, **82–83% of input tokens were cache reads** — deterministic data-gathering, not inference — and removing unused tools from the agent's MCP config saved **8–12 KB of context per call** with no behaviour change. [3] This is the most actionable number on the page. A 40-tool MCP server can add 10–15 KB of schema to *every* turn, and in one of GitHub's workflows a single unnecessary tool was called 342 times — 58% of all tool calls — for a job that only scanned local files. [3] The fixes that worked were unglamorous: prune the toolset, move deterministic reads out of the agent loop, and switch cheap turns to cheaper models. GitHub's full report quantifies sustained reductions of **62%, 43%, 59%, 37%, and 19%** on five different production workflows after exactly these changes. [3] A parallel finding from research: on SWE-bench Verified, simple *observation masking* — omitting older observations from context rather than summarising them — **halves cost** relative to the raw agent while matching the solve rate of more complex LLM-summarisation approaches. [4] The same levers — MCP output compaction and [semantic code search](https://tokenade.net/en/glossary/semantic-code-search) instead of bulk re-reads — are what I describe in [reducing AI coding agent token usage](https://tokenade.net/en/articles/reduce-ai-coding-agent-token-usage).

Where this leaves your bill

The pattern across every task type is the same: completion and explanation are cheap and bounded, while anything agentic is dominated by context the model re-reads and tool schemas it carries but never uses. Output length is the least of your problems.

Tokenade attacks exactly that part of the spend — semantic code search instead of bulk file reads, output filtering, skeleton compression, and MCP result compaction — and opens a local, graphical report of the saved tokens (tokenade dashboard) so you can see which features, agents and projects it actually moved. It works with Claude Code, Cursor, Codex, Copilot, and Windsurf; it's free and open source (MIT/Apache-2.0), and the compaction runs entirely on your own machine — none of your code leaves it. For the full per-tool comparison, see the best Claude Code token optimizers.

## Source notes The per-task-type token ranges (completion, explanation, review, debugging, agentic) are from Iternal's 2026 "AI Token Usage Guide", a secondary compilation of 2026 cost profiles across providers — useful for relative magnitudes by task type, less so for any single provider's exact rate. The 1,000× agentic-vs-chat ratio, the up-to-30× run-to-run variance, and the input-token dominance finding are from Bai et al. (arXiv:2604.22750), a primary analysis of eight frontier LLM trajectories on SWE-bench Verified, co-authored with researchers from the Stanford Digital Economy Lab and Microsoft Research. The observation masking cost halving is from Lindenbauer et al. (arXiv:2508.21433), presented at DL4C / NeurIPS 2025. The cache-read share, MCP-schema overhead, unused-tool call counts, and the 62%/43%/59%/37%/19% optimization results are from GitHub's own engineering blog reporting on production agentic workflows — primary, first-party data, though from a single organisation. Re-verify all figures at the primary source before citing commercially.

Sources and references

  1. [1] Iternal. "AI Token Usage Guide (2026): 10 Use Case Cost Profiles". iternal.ai, 2026. Link ↗
  2. [2] Bai, Longju; Huang, Zhemin; Wang, Xingyao; Sun, Jiao; Mihalcea, Rada; Brynjolfsson, Erik; Pentland, Alex; Pei, Jiaxin. "How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks". arXiv:2604.22750, April 2026. Link ↗
  3. [3] Cox, Landon; Kiefer, Mara (GitHub). "Improving token efficiency in GitHub Agentic Workflows". github.blog, May 7, 2026 (updated May 13, 2026). Link ↗
  4. [4] Lindenbauer, Tobias; Slinko, Igor; Felder, Ludwig; Bogomolov, Egor; Zharov, Yaroslav. "The Complexity Trap: Simple Observation Masking Is as Efficient as LLM Summarization for Agent Context Management". arXiv:2508.21433, Aug 2025 (NeurIPS DL4C 2025). Link ↗