Improving token efficiency in GitHub Agentic Workflows (opens in new tab)

GitHub’s Agentic Workflows can quietly accumulate substantial token costs because they run automatically in CI. GitHub improved efficiency by instrumenting token usage, auditing workflows, pruning unused MCP tools, and replacing many MCP data-fetching calls with deterministic GitHub CLI commands. Early results show that reducing context and removing unnecessary LLM reasoning can save thousands of tokens per run, though measuring true efficiency requires accounting for model choice and workload quality.

Logging Token Usage

• GitHub runs hundreds of agentic workflows against real GitHub Actions limits.
• Different agent frameworks produced incompatible usage logs, so GitHub used its API proxy to normalize data across Claude CLI, Copilot CLI, and Codex CLI.
• Each workflow now emits a token-usage.jsonl artifact containing:
  • Input, output, cache-read, and cache-write tokens
  • Model and provider
  • Timestamps
  • One record per API call
• These records make it possible to compare historical runs and identify recurring sources of waste.

Automated Auditing and Optimization

• A daily Token Usage Auditor aggregates recent usage by workflow and reports:
  • Significant increases in token consumption
  • The most expensive workflows
  • Anomalous runs, such as a workflow taking 18 LLM turns instead of its usual four
• A daily Token Optimizer examines flagged workflows, their source YAML, and recent logs.
• It creates GitHub Issues with concrete inefficiencies and recommended fixes.
• The auditing workflows also consume tokens, creating a feedback loop in which their own costs are monitored.

Removing Unused MCP Tools

• MCP tool names and JSON schemas are typically included in every stateless LLM request.
• A GitHub MCP server with roughly 40 tools can add 10–15 KB of schema to every turn.
• If a workflow uses only two tools, the other 38 create repeated overhead without adding value.
• GitHub compares configured tools with actual tool calls and recommends removing unused registrations.
• In smoke tests, pruning tools reduced each call’s context by 8–12 KB and saved several thousand tokens per run without changing behavior.

Replacing MCP Calls with GitHub CLI

• GitHub found larger savings by replacing MCP calls for predictable data retrieval—such as pull request diffs, file contents, and review comments—with gh commands.
• MCP calls require an additional reasoning cycle: the model chooses a tool, constructs arguments, and processes the response.
• Commands such as gh pr diff make deterministic API requests without involving the LLM in the retrieval step.

Two migration patterns were used:

• Pre-agentic downloads

  • Workflow setup steps run gh commands before the agent starts.
  • Results such as diffs and changed-file lists are saved to workspace files.
  • The agent reads the files directly, eliminating MCP round trips.

• In-agent CLI proxy substitution

  • When data must be selected dynamically, the agent runs commands such as gh pr view --json.
  • A transparent proxy routes CLI requests to GitHub’s API without exposing credentials.
  • This preserves the zero-secrets security model while avoiding MCP overhead.

Measuring Efficiency

• Lower token counts do not necessarily mean better workflows; a workflow may simply be doing less work.
• Model selection also affects cost. Claude Haiku and Sonnet may use similar numbers of tokens, but Haiku is substantially cheaper.
• GitHub therefore uses an Effective Tokens (ET) metric that weights usage by token type and model cost:

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

• m represents the model multiplier: Haiku 0.25×, Sonnet 1.0×, and Opus 5.0×.
• I is newly processed input, C is cache-read tokens, and O is output tokens.
• Output tokens receive greater weight because they are typically the most expensive component.

GitHub’s experience suggests that agentic workflow authors should measure usage continuously, remove tools that workflows do not actually use, and move routine API retrieval outside the LLM reasoning loop wherever possible.