The Hidden Token Tax in Every AI Agent You Build — And How to Fix It

GitHub runs agentic workflows ("gh-aw" workflows) that trigger automatically on repository events — auto-triaging issues, guarding security, attributing community contributions. Because these fire on every relevant event in CI, no human watches the token meter on any single run. GitHub's own framing: costs "can accumulate out of view."

The team's investigation surfaced three distinct sources of waste — the three components of the token tax:

1. Tool schema bloat. Every tool you register with an agent ships its full JSON schema in every request, whether the agent calls it or not. GitHub measured this directly: "For a GitHub MCP server with 40 tools, this can add 10–15 KB of schema per turn. If the agent only uses two tools, the remaining 38 are pure overhead added to every request."

1. LLM-reasoned work that should have been deterministic. Agents were using LLM-powered tool calls to fetch data — pull request diffs, file contents — that a plain CLI command returns deterministically. GitHub's contrast: "Calling gh pr diff … is a deterministic HTTP request to GitHub's REST API with no LLM involvement."

1. Runaway loops from misconfiguration. When an agent can't reach a tool it expects, it can thrash. GitHub's most extreme example: a misconfigured sandbox in the "Daily Syntax Error Quality" workflow caused "a 64-turn fallback loop."

The single most instructive case GitHub published: in the Glossary Maintainer workflow, one tool — search_repositories — "was called 342 times in one run, accounting for 58% of all tool calls, despite being completely unnecessary." More than half of an entire run's tool traffic was tax.

Here is the conceptual heart of GitHub's approach, and the part most teams get wrong: a raw token count is not a cost signal. A run that uses 100,000 cache-read tokens is far cheaper than a run that uses 100,000 output tokens, because providers price those token types very differently. If you optimize against raw volume, you can "improve" a number while spending more money.

GitHub's answer is a normalized unit they call Effective Tokens (ET):

ET = m × (1.0 × I + 0.1 × C + 4.0 × O)

``

Where, per GitHub's definitions:

| Symbol | Meaning | Weight | GitHub's stated reason |

|--------|---------|--------|------------------------|

| m | model cost multiplier | Haiku 0.25× · Sonnet 1.0× · Opus 5.0× | Normalizes across model tiers |

| I | newly-processed input tokens | 1.0× | Baseline |

| C | cache-read tokens | 0.1× | "served from cache at a fraction of the cost of fresh input" |

| O | output tokens | 4.0× | "the most expensive token type across all major providers" |

The payoff of this normalization, in GitHub's words: a 10% ET reduction "represents genuine 10% cost savings regardless of model choice." That is the property a raw token count does not have.

The general principle (author's framing): whatever you build, measure the thing that maps to money, and normalize it so the number means the same thing across models and across cache states. "Tokens used" is a vanity metric. A cost-weighted, normalized unit is an engineering metric.

GitHub did not theorize about savings — they shipped fixes and measured the result over many post-deployment runs ("post-fix runs"). These are the three techniques, each tied to a published, measured outcome.

Technique 1 — Prune the tool manifest.

Remove every tool registration the agent does not actually call. GitHub's measured result: "removing unused tools from the MCP configuration reduced per-call context size by 8–12 KB, saving several thousand tokens per run with no change in behavior." No behavior change, several thousand tokens saved per run. This is the cheapest win available and almost every agent has it sitting unclaimed.

Technique 2 — Move deterministic work out of the LLM loop.

If the data is fetchable with a deterministic command, fetch it with a deterministic command — ideally before the agent starts reasoning. GitHub replaced LLM-mediated MCP data fetches with pre-agentic gh CLI downloads written to workspace files, and routed in-agent CLI traffic through a lightweight HTTP proxy "without exposing authentication tokens to agents." GitHub's governing maxim: "the cheapest LLM call is the one you don't make."

Technique 3 — Eliminate misconfiguration-driven loops.

Validate sandbox and permission configuration before deployment. The 64-turn fallback loop in "Daily Syntax Error Quality" was not a model problem — it was a config problem that the model paid for, turn after turn.

The measured outcomes GitHub published, after applying these fixes (each requires "at least eight runs in both the pre- and post-optimization periods" to count):

| Workflow | Improvement | Sample / note |

|----------|-------------|---------------|

| Auto-Triage Issues | 62% reduction | 109 post-fix runs · 7.8 M ET saved in aggregate |

| Smoke Claude | 59% reduction | — |

| Security Guard | 43% improvement | — |

| Community Attribution | 37% improvement | 8 post-fix runs |

| Daily Compiler Quality | 19% improvement | 12 post-fix runs |

These are GitHub's reported figures, not extrapolations.

You cannot fix what you cannot see, and GitHub is explicit that the win came from instrumentation first. Their recommendation, quoted: "Add the API proxy, turn on logging, and let the data tell you where to look." They warn against retrofitting observability later.

What they instrumented. GitHub built an API proxy that captured token consumption across agent frameworks. The artifact: "Every workflow now outputs a token-usage.jsonl artifact with one record per API call that contains input tokens, output tokens, cache-read tokens, cache-write tokens, model, provider, and timestamps." One record per API call — granular enough to attribute waste to a specific tool or turn. The audit loop. GitHub then deployed two agentic workflows to close the loop on themselves:

• A Daily Token Usage Auditor that aggregates consumption and flags unusual spikes.
• A Daily Token Optimizer that analyzes the logs and the source code and recommends specific fixes.

The lesson generalizes cleanly: instrument every call into a structured log, aggregate it on a schedule, and have something — automated or human — read the aggregate looking for the 342-call search_repositories hiding in your own workflows.

The hardest part of token optimization is not finding savings — it's proving the savings are real and not a quality regression in disguise. An agent that "uses fewer tokens" because it gave up early is not an improvement.

GitHub's validation methodology is the part to copy most carefully:

1. Compare windowed periods, not single runs. Pre-optimization baseline vs. post-optimization period, with "at least eight runs in both" before a result counts. Single-run comparisons are noise.
2. Hold quality constant with proxy signals. Direct outcome measurement is hard for agentic workflows, so GitHub tracked three proxies: output tokens per LLM call, turn counts per run, and tool-call completion rate. Their stated bar: for the optimized workflows "all three remained stable across the optimization period even as token consumption fell." Tokens down, quality proxies flat = genuine efficiency. Tokens down, turns also collapsing = the agent quit early.
3. Watch LLM call count alongside token count. GitHub's signal of genuine improvement: "constant LLM turns-per-run and falling tokens-per-call indicate genuine efficiency improvement."

Connecting this to your own dashboard. This is exactly why a normalized per-task efficiency number beats a raw total. On vybecoding.ai's AI metrics dashboard, the new Effective Tokens card reports tokens spent per successful completion — raw volume divided by tasks that actually succeeded. The shape of the idea is GitHub's: when that number falls while success rate holds, you have real efficiency; when raw volume falls because completions also fell, the per-task number exposes it instead of hiding it.

A concrete checklist, ordered by return on effort (ordering is the author's; each item maps to a GitHub-reported mechanism):

1. Audit your tool manifest today. List every registered tool. List every tool actually called in your last 20 runs. Delete the difference. GitHub: 8–12 KB per call, several thousand tokens per run, zero behavior change.
2. Find your deterministic calls. Any tool call whose result is a pure function of its inputs (a diff, a file read, a list) is a candidate to move out of the LLM loop and pre-fetch. "The cheapest LLM call is the one you don't make."
3. Log every API call to a structured artifact. One JSONL record per call: input, output, cache-read, cache-write tokens, model, provider, timestamp. You cannot optimize blind.
4. Define a normalized cost unit. Weight output heaviest, cache-read lightest, multiply by a model-tier factor. Optimize against that, never raw tokens.
5. Validate over windows with quality proxies frozen. ≥8 runs each side; track turns/run and completion rate so a "win" can't be a silent regression.
6. Hunt for runaway loops. Misconfiguration is a token bill, not just a bug. The 64-turn loop was free to write and expensive to run.

The uncomfortable takeaway from GitHub's data: the biggest wins were not clever prompt engineering. They were deleting overhead nobody had measured. The token tax is paid by default. You only stop paying it once you can see it.

---

Sources used in this guide:

• Landon Cox & Mara Kiefer, GitHub Blog — "Improving token efficiency in GitHub Agentic Workflows", published May 7, 2026 (updated May 13, 2026). All quantitative claims (the ET formula and weights, the 19–62% reductions, the 8–12 KB / 10–15 KB schema figures, the 342-call / 58% Glossary Maintainer example, the 64-turn loop, the ≥8-run validation rule, and all direct quotes) are drawn from this article.

Where this guide turns a GitHub-specific result into a general recommendation for your own agents, that generalization is the author's framing and is marked as such in the text.