GitHub Agentic Workflows Token Optimization Commentary: Why CLI dictionary collection and inference gates should be designed first rather than adding many MCP tools

Publication date: 2026-05-09 | Category: Development information

1. One-line problem definition

Key summary: The cost of AI code automation is not only because the models are expensive, but also because even read operations that do not require inference are burned in LLM turns It gets bigger

In an article published on May 7, 2026, GitHub measured the Agentic Workflows actually running in its repository and revealed which points were leaking tokens. The target audience is platform engineers, DevEx staff, and security/quality automation teams that run agents like Copilot CLI, Claude CLI, and Codex CLI within GitHub Actions. The real problem is simple. Agents that run automatically for each PR accumulate costs unnoticed, and a significant portion of those costs occur in the data collection stage, which does not require judgment.

The scope of this article is Token Optimization Operation Standard for GitHub Agentic Workflows. It does not cover specific model vendor comparisons or general prompt writing tips. Also, I do not support the dichotomy that “MCP is bad and CLI is always good”.

2. First, conclusion

Key takeaways:The order of greatest cost reduction is not model downgrade, but removing unnecessary MCP schema → downloading dictionary data → relevance skipping the LLM itself. gate.

• Teams to apply right now:Teams that already run repetitive GitHub Actions agents such as PR triage, issue classification, security check, and review comment creation
• Team that is still too much: A team with a small repository that only conducts one-off experiments, and the implementation time is more expensive than the cost due to low frequency of workflow execution
• My judgment: The key to optimizing Agentic Workflow is not “making agents smarter,” but Eliminating sections through design that agents do not need to think about. It is.

The most compelling figure in the GitHub case was that the Auto-Triage Issues workflow showed 62% savings after optimization. This change came not from a fine-tuning of the prompts, but from a structural change that took the read operations out of the LLM loop. So, I think it is better to view the token reduction project as workflow structure improvement rather than “model cost saving”.

3. Decomposition of core structure

Key takeaways: The structure revealed by GitHub is not just a cost dashboard, but is comprised of four layers: Measurement, Audit, Auto-Optimization, Execution Plane Separation There is

1. Instrumentation Layer: Every workflow leaves an artifact of token-usage.jsonl, recording input/output/cache tokens, model, provider, and time for each API call.
2. Audit Tier: Daily Token Usage Auditor aggregates recent runs and reports patterns such as abnormal increases, most expensive workflows, and spikes in LLM turns.
3. Optimization Layer: Daily Token Optimizer reads workflow sources and logs, issues specific inefficiencies and suggestions for corrections.
4. Execution layer: Actual optimizations are reflected by structural changes such as MCP tool pruning, gh CLI pre-download, runtime CLI proxy, relevance gate.

To put it simply, GitHub did not complain that “agents are expensive,” but first created an observation system that automatically tells where and why it is expensive. The reason this is important is because token optimization can easily end up at the level of “let’s just use a cheaper model”.

4. Description of design intent

Key summary: GitHub's real design intention is not to abandon MCP, but to reduce MCP to be used only in sections where inference is needed There is

MCP (Model Context Protocol) is an open standard that allows AI apps to connect with external tools in a standard way. The problem is that, apart from the benefits of standardization, it is easy to keep prompting for tool schemas that are not needed in one workflow. According to the GitHub description, a GitHub MCP server with 40 tools can add 10 to 15 KB of JSON schema to the context per call.

So the direction GitHub has chosen is not “Let’s get rid of MCP,” but “Remove static read operations using gh CLI or dictionary files, and leave only the sections that require agent judgment in MCP/LLM”. This judgment is quite reasonable. This is because reading PR diffs, receiving a list of changed files, and searching issue metadata are close to mechanical tasks even if done by a person.

Something is giving up here. The freedom to use all the tools you need ad-hoc on the fly is reduced. What you get in return is reproducibility, predictable costs, and a lower probability of runaway loops. I think this trade-off is almost always beneficial in CI-type agents that run repeatedly.

5. Evidence and Comparison

Key takeaways: The criteria for comparison is not “which looks cooler”, but Token cost, number of inference turns, operational control, quality Maintain.

GitHub public figures show that removing unused MCP tools 8-12KB context per call was reduced, saving thousands of tokens per workflow. Also, after structural optimization, Auto-Triage Issues 62%, Daily Compiler Quality 19%, Daily Community Attribution They said they confirmed an improvement of 37%. This figure is not at the level of “let’s write a slightly shorter prompt”, but rather it is evidence that changing the architecture will change the cost curve.

Also, GitHub used Effective Tokens(ET) instead of the simple number of tokens. The formula in the official article is ET = m × (1.0 × I + 0.1 × C + 4.0 × O). This is an attempt to create an indicator that is closer to the actual cost by reflecting the output token cost higher and the cache-read token cost lower. This perspective is also important. Even if there are the same 100,000 tokens, the operating cost is different depending on which token it is.

6. Actual operation flow / step-by-step execution method

Key takeaway: The safest order is instrumentation and pruning in the first week, CLI dictionary collection in the second week, and attaching relevance gates in the third week.

1. Leave token usage logs as artifacts
   Leave token usage logs in the same format for each workflow for comparison.
   

   - name: Upload token usage
     uses: actions/upload-artifact@v4
     with:
       name: token-usage
       path: token-usage.jsonl
       retention-days: 5

2. Reduce MCP tools that are not actually used first
   Check the tool manifest and actual tool call logs to remove zero-call tools. Especially in the PR review workflow, it is almost a waste if gist, webhook, and org management tools are included.
3. Always download the necessary GitHub data before starting the agent
   PR diff, changed files, and review comments are usually prepared in advance. It is possible.
   

   mkdir -p .agent
   GH_TOKEN="$GITHUB_TOKEN" gh pr diff "$PR_NUMBER" > .agent/pr.diff.txt
   GH_TOKEN="$GITHUB_TOKEN" gh pr view "$PR_NUMBER" --json files,comments,reviews > .agent/pr-view.json

4. Change the agent prompt to 'Read the file to make a decision'
   Reading the workspace file first instead of inducing an MCP call reduces the number of inference turns. It decreases.
   

   First read .agent/pr.diff.txt and .agent/pr-view.json,
   Do not call MCP without further inquiry.

5. If runtime inquiry is absolutely necessary, use a CLI proxy
   As in the GitHub case, the method is to only allow structured queries such as gh pr view --json through a proxy, rather than giving the token directly to the agent. It’s safe.
Create a skip gate of
6. LLM
   For example, create a pre-rule so that PRs with unchanged security-sensitive paths do not run Security Guard. Leave
   

   if ! git diff --name-only "$BASE_SHA" "$HEAD_SHA" | grep -Eq '(^infra/|^auth/|secret|policy)'; then
     echo 'skip_agent=true' >> "$GITHUB_OUTPUT"
   fi

7. Look at efficiency and quality together
   If you do not look at LLM call count, turns per run, and completion rate together like GitHub, you may mistakenly think that efficiency has improved when in reality you worked less.

7. Pitfalls

Key takeaways: Cost savings failures often come not from model selection, but from allowing wrong instrumentation, wrong gates, wrong paths

• Mistake 1. Misunderstanding that quality has been maintained by only looking at the total amount of tokens
  Prevention: Look at the number of LLM turns per run, completion rate, result length and review pass rate together.
  Recovery: Sample before and after efficiency change. Please review your PR again to ensure there are no actual omissions.
• Mistake 2. Carrying unused MCP tools
  Prevention: Pull the tool-call histogram at least once a month to remove zero-call tools.
  Recovery: Separate toolsets for each workflow, and eliminate common full-set defaults.
• Mistake 3. Relevance gate is too aggressive and even skips necessary checks
  Prevention: Manage the sensitive path list together with the code owner, and check the skip rate weekly.
  Recovery: false Add the negative pattern to the gated regular expression and temporarily revert to conservative mode.
• Mistake 4. Tool calls are blocked due to allowlist/path rules, resulting in a runaway loop
  Prevention: As in the GitHub case, relative path, glob, and temporary directory rules are installed first in the test workflow. Please verify.
  Recovery: View the failure log, modify the blocking rule, and rerun the smoke test with the same conditions.

8. Strengths and Limitations

Key takeaway: This approach is very powerful for iterative workflows, but difficult to replicate for conversational agents with many user-specific interactions.

• Strengths: Increased cost predictability, reduced tool calls, mitigation of runaway loops, great optimization effect when repeating the same workflow
• Limitations: Limited effectiveness in dynamic inquiry tasks where pre-filing is difficult, risk of omission exists depending on gate design quality, preparation time is required
• Counterexample: In cases where users require different permissions and different queries each time, such as a chat-based support agent, the per-user authentication advantages of MCP may be more important than a pure CLI replacement.

In other words, it is more accurate to say that this pattern is not “the correct answer for all agents” but close to the correct answer for the repetitive automated GitHub workflow

9. Points to study more deeply

Key takeaway: The next step is not a religious battle between MCP or CLI, but finding Which read operations can be separated from inference It's work.

• Collect the schema size and actual tool usage distribution for each MCP server.
• Divide what data is always needed and what is conditional data by PR/issue/workflow type.
Try defining a cost normalization metric such as
• ET to suit your team situation.
• Collect false negative cases of the skip gate and see how far you can regularize them.
• Check whether the conversational agent and CI-type agent are operated with the same architecture.

10. Action Checklist + Author's Perspective

Key takeaway: If you want to reduce agent cost, you should fix read path and execution conditions before prompting

• All repeatable agent workflows leave token usage artifacts
• MCP toolsets for each workflow are separated to include only the tools actually used
• PR diff, file list, and basic metadata are downloaded as files before starting the agent
• Runtime additional query is only allowed by CLI proxy or minimum MCP
• Security/quality check workflow has a relevance gate
• View efficiency indicators and quality indicators together
• Verify allowlist and path rules with smoke test

Definition of Done: Primary optimization is complete when the ET or equivalent metric decreases by at least 20% without quality degradation after tool pruning, pre-data download, and skip gate application in one repetitive workflow.

My recommendation: If you are already running an agent in GitHub Actions, the next optimization task for the next branch should be to look at To what extent MCP calls can be replaced by files/CLI/gates rather than model replacement. That's right. Conversely, if you still have a small number of workflows and run them infrequently, it is better to instrument them first rather than prematurely optimize them. Costs add up fastest when you can't see them.

Reference material

• GitHub Blog - Improving token efficiency in GitHub Agentic Workflows (2026-05-07)
• Model Context Protocol - What is MCP? (Confirmation date: 2026-05-09)
• GitHub Docs - Store and share data with workflow artifacts (Confirmation date: 2026-05-09)
• GitHub CLI Manual - gh pr diff (Confirmation date: 2026-05-09)
• GitHub CLI Manual - gh pr view (Confirmation date: 2026-05-09)
• Firecrawl Blog - MCP vs CLI for AI Agents (2026-04-10, refer to industry comparison perspective)