Engineering teams embracing modern coding agents frequently hit the same inflection point: developer velocity surges, but token bills quickly outpace budgets.
The standard advice is usually: "Use lower cost models for simple tasks."
In practice, manual model switching does not work. When an engineer is in a flow state debugging an issue or shipping a feature, constantly running /model adds pure cognitive friction. Developers either leave frontier models like Claude Sonnet or Opus on by default, or switch to Haiku, hit a subtle capability wall, and get frustrated.
The solution is not manual switching. It is automated routing and architecturally cost-aware orchestrations (agent skills).
Best of all, you do not need to write complex orchestration code yourself. You can prompt your agent to analyze and refactor your existing skills for you.
A Real-World Example
To see what a cost-aware orchestration looks like in practice, consider a common developer workflow: a skill that automatically inspects your branch, generates a standardized pull request description, and applies issue labels.
Originally, this entire workflow ran monolithically on Claude Sonnet, costing ~$3.40 per execution.
I refactored the workflow into a two-tier orchestration:
-
Mechanical Scaffolding (Claude Haiku): Verifying branch naming conventions, fetching git diffs, pulling issue tracker details, and drafting the PR body—moved to
model: haikuin an isolated scratchpad (context: fork). -
Judgment Gate (Claude Sonnet): Handed off only the final PR URL and diff range to a labeling skill running on
model: sonnetto evaluate whether the code changes represent architectural technical debt, a security-sensitive change, or feature work.
The result: PR templates and labels retained 100% of their quality, while execution cost plummeted from dollars to <$0.5. We apply this exact same pattern to complex incident triage and log diagnosis pipelines.
Why This Works: Where Token Costs Actually Go
Why does splitting a workflow slash costs so dramatically? When you inspect token usage dashboards in LLM observability tools, the breakdown reveals a hidden trap:
- User prompts and replies are small: Input prompts usually average under 1,000 tokens, and agent code replies rarely exceed 2,000 tokens.
- Cache re-reads dominate spend: In typical multi-turn agent sessions, 75% to 95% of total billable tokens come from repeatedly re-reading conversation history.
The Monolithic History Problem
When an agent operates in a single, unbroken loop, every tool output—like a 30,000-token git diff, a massive API response, or pages of raw logs—is appended to the conversation transcript. The model must re-read that entire history on every subsequent turn.
By turn 8, the model burns thousands of expensive frontier tokens just re-reading past tool outputs. What looked like a simple automation quickly balloons into a $3 to $5 run.
The Two Levers That Lower Costs
- Asymmetric Model Tiering: Routine, formulaic steps (CLI commands, git checks, template formatting) run on lower capability flash model at near-zero cost. Reserve frontier models strictly for high-stakes judgment (evaluating tech debt, diagnosing root causes, reviewing security boundaries).
-
Context Forking (
context: fork): Run data-heavy tasks inside an isolated subagent. The subagent inspects the large diff or log, extracts the key facts, and returns only a compact ~200-token summary back to the primary agent. The raw payload is discarded, keeping the parent context lean and prompt cache hits high.
Prompt Your Agent to Refactor
You do not need to manually edit YAML frontmatter or learn prompt schemas by hand. You can instruct your coding agent to audit and refactor your skills using three simple prompts.
Bellow prompt examples are created for Claude models.
Step 1: Audit the Skill
Point your agent at your skill definition or workflow config:
Audit this skill definition (@SKILL.md or plugin config) for token efficiency:
1. Identify Mechanical / Procedural steps (git commands, template formatting, CLI checks).
2. Identify Heavy Data steps (fetching raw diffs, reading large logs, full API payloads).
3. Identify High-Order Judgment steps (categorization, root-cause analysis, code critique).
Summarize current model assignments and highlight where context accumulates.
Step 2: Perform the Refactor
Instruct the agent to apply the two-tier pattern:
Refactor this skill using the two-tier cost pattern:
1. Set the primary skill frontmatter to 'model: haiku' and 'context: fork' for all mechanical steps.
2. Extract the judgment steps into a private subagent (e.g., `<name>-evaluator`) set to 'model: sonnet', 'context: fork', and 'user-invocable: false'.
3. Enforce context boundaries: pass only compact IDs/diff ranges to the subagent, and ensure it returns only a distilled summary, never raw tool dumps.
Show the diff and generate the updated SKILL.md files.
Step 3: Verify the Changes
Run a quick sanity check before committing:
Check the refactored skill against these rules:
1. Are formulaic steps pinned to Haiku?
2. Do subagents return distilled summaries rather than raw payloads?
3. Is control flow organized in explicit sequential steps rather than open-ended model wandering?
Going forward: Optimization Skill
While the manual prompts above can be applied to any skill or workflow right now, the natural next step is automating this process into agent toolkits.
By building a specialized skill-cost-optimizer, the optimization tool itself can dogfood this exact architecture as a follow up step of skill-creator.
Top comments (0)