GitHub Slashes Agent Token Spend 62% — 2026-05-30

GitHub published production data on May 30, 2026, showing it cut token costs in its own agentic CI workflows by as much as 62% — not through model swaps or architectural rewrites, but through disciplined measurement, schema pruning, and a pair of autonomous agents that keep the savings compounding day after day.

Background You Need

The explosion of AI agents in software development has brought a cost problem that most teams are still figuring out. Unlike a single chat completion, an agentic workflow makes dozens or hundreds of LLM calls in sequence — each one carrying tool definitions, prior context, and intermediate outputs. The bill scales fast, and it scales in ways that are genuinely hard to reason about without instrumentation.

Model Context Protocol, or MCP, has become the dominant standard for giving agents access to external tools — repository APIs, file systems, issue trackers, and more. The appeal is obvious: register a server once, and any agent in your environment can call its tools. The hidden cost is less obvious. Every LLM call re-sends the full schema for every registered tool, whether those tools are used in that call or not. A GitHub MCP server with 40 tools adds roughly 10 to 15 kilobytes of token overhead per turn — overhead that the model reads, processes, and gets charged for even when the agent never touches those tools.

GitHub has been running agentic workflows in its own CI infrastructure for long enough to accumulate the kind of production data most teams are still waiting to see. Their engineering team built an internal measurement framework, identified the most expensive patterns, and then published what actually worked. The tooling — a CLI called gh-aw — ships today.

What's New

The core of GitHub's approach is a cost metric they call Effective Tokens, or ET. The formula normalizes costs across model tiers: ET = multiplier × (1.0 × input + 0.1 × cache + 4.0 × output). Haiku carries a 0.25× multiplier, Sonnet 1.0×, and Opus 5.0×. The 4× weight on output tokens reflects their actual price premium relative to input tokens. This matters because a 10% ET reduction means a 10% cost reduction regardless of which model the workflow runs on — you can compare a Haiku workflow against a Sonnet workflow on the same scale.

The first intervention was MCP schema pruning. GitHub audited which tools each workflow actually called and stripped the rest from the registered schema before each run. One workflow had eight unused tools contributing zero tool calls across hundreds of runs — removing them brought ET down meaningfully because those schemas were a non-trivial fraction of total context per call. The results across specific workflows: Auto-Triage Issues dropped 62%, Smoke Claude dropped 59%, Security Guard dropped 43%, and Community Attribution dropped 37%. The caveat, which GitHub is candid about, is that pruning doesn't always help. In at least one case, unused tool manifests were such a small fraction of total context that removing them produced no measurable ET reduction. Audit first.

The second intervention was replacing in-loop MCP tool calls with pre-fetched data. For predictable inputs — PR diffs, file contents, repository metadata — GitHub now writes the relevant data to workspace files before the agent loop starts. The agent reads from files instead of firing MCP calls mid-loop. This eliminates entire categories of tool invocations, not just their schema overhead. The principle maps cleanly to a pattern already common in well-structured agent frameworks: separate data retrieval from reasoning. The agent should arrive at its first reasoning step with the information it needs already present, not go fetch it reactively.

The third and arguably most durable intervention is the audit loop itself. GitHub runs two agents on a daily schedule: a Token Auditor that analyzes cost logs across all workflows and flags anything running above expected ET thresholds, and a Token Optimiser that reads both the source code and the run logs for flagged workflows and opens a specific GitHub Issue describing the problem and a proposed fix. This isn't a one-time cleanup — it's a feedback mechanism that catches regressions and new workflows before they compound. Our read is that this is the piece most teams will underestimate. Pruning a schema today and forgetting about it means costs drift back as workflows evolve. Automating the detection loop is what makes the savings structural rather than episodic.

The Pushback

The numbers are real, but they come from GitHub's own workflows running on GitHub's own infrastructure — a context that may not transfer cleanly. Teams with smaller workflow counts or less predictable tool usage patterns will have fewer obvious pruning targets. The pre-fetch approach also assumes you know in advance what data the agent will need, which works for structured CI tasks like PR triage but breaks down for exploratory or open-ended agent work where the next tool call depends on the previous result. GitHub's workflows are unusually well-defined; most agentic applications in the wild are not.

There's also a question of maintenance burden. The Token Auditor and Optimiser agents are themselves LLM workflows with their own token costs, and the gh-aw CLI tooling is new enough that operational maturity is unproven at scale. The approach GitHub is describing requires instrumentation infrastructure — a log format, a cost database, a way to attribute ET to specific workflow runs — that most teams haven't built yet. The techniques are sound, but the prerequisite work is non-trivial for anyone starting from scratch. That doesn't diminish what GitHub has published here; if anything, it underscores how far ahead they are in treating agent cost as a first-class engineering concern rather than an afterthought.

Source