For months, the discussion around AI coding tools has revolved almost exclusively around one question: Which model is the best? Claude Opus or Sonnet? GPT-5.4 or GPT-5.3-Codex? Haiku for simple tasks? That is the wrong question.
Choosing the right model is a lever. But it is not the lever. If you run agentic sessions like chats, you cannot optimize your way out of the problem through model choice—no matter how inexpensive Haiku is. The real cost lever is discipline: how you specify tasks, how you control context, and how you manage sessions.
This post explains why—and what you can do about it.
Why this is relevant right now
The market is shifting. Within a few months, almost every major provider has switched to token-based billing or announced it. GitHub Copilot is switching from request-based to token-based billing on June 1, 2026. Claude Code is already there. OpenAI and Cursor—same picture.
This is no coincidence. It is the logical consequence of the adoption curve: 84% of developers use AI tools, 41% of code is already AI-assisted, 90% of Fortune 100 companies pay for AI coding tools. At this level of usage, providers can no longer sustain flat-rate subsidies.
What this means in practice: GitHub writes in the announcement of the new billing model that it is “common for a handful of requests to incur costs that exceed the plan price.” This is not an edge case for heavy users—this is the new normal for anyone using agents seriously.
The good news: From our project experience, a significant portion of these costs arise from avoidable patterns. Not from the task itself, but from the way you work.
Why agent sessions are structurally different
This is the core of the problem—and it is not intuitively clear to most developers.
Most developers’ mental model is shaped by ChatGPT: an open tab, open for hours, question in, answer out, new question. Long sessions are harmless. Costs are linear. Agentic sessions work differently. In the chat model, each response is independent. One question costs a fixed amount, the next costs the same. Consumption is linear and predictable.
In the agent model, every turn re-reads the entire history as input. The agent does not remember—it re-reads the entire conversation. This has concrete consequences:
- Turn 1 – Read spec and plan: around 5,000 tokens
- Turn 2 – History from Turn 1 plus new file: around 15,000 tokens
- Turn 5 – Four turns of history plus tool output: around 60,000 tokens
- Turn 10 – Entire history so far plus new tools: around 150,000 tokens
- Turn 30 – All of the above plus a new file: over 400,000 tokens
What ends up in the context without you actively deciding: the system prompt, AGENTS.md, all MCP tool schemas, every file content read, every terminal output (npm test with 200 tests produces thousands of lines), every git diff, every tool output. Five connected MCP servers alone can generate up to 18,000 tokens of overhead according to Anthropic—per turn, even if not a single tool is called.
What this costs in practice: Anthropic publishes real enterprise average values in the Claude Code Cost Docs: Around $13 per developer per active day, $150 to $250 per month. A GitHub Copilot Business seat costs $19 per month—and includes $19 in AI credits. At $13 per active day, this budget covers one and a half working days. The rest of the month, you pay on top. With discipline—shorter sessions, cleaner specs, more controlled context—this daily value drops drastically, and the included budget actually lasts for a month.
The difference is not the model. It is how you work.
Three disciplines that make the difference
The three disciplines are not independent tips—they interlock. Spec-Driven Development reduces what goes into a session in the first place. Context Engineering reduces what is loaded into the context per turn. Session discipline limits how long a session runs before the context becomes exponentially expensive. Together, they address all three phases of the same problem.
1. Spec-Driven Development: Think first, then code
The opposite of Spec-Driven Development is called Vibe Coding: sending an agent after a vaguely defined goal—without requirements, without constraints, without clear success criteria.
Vibe Coding works for throwaway prototypes. For production code, it is expensive. Without a precise spec, the agent explores: it scans the repository for orientation, makes its own assumptions about framework choice, data model, and error handling, iterates multiple times in the wrong direction, and generates significantly more token consumption than a targeted implementation. The result may run—but it violates unspoken requirements or makes architectural decisions that were never approved.
Spec-Driven Development transforms specifications from passive documentation into executable contracts. A good spec has six elements:
- Outcomes – What the desired state is, not how it is achieved
- Scope Boundaries – What is explicitly out of scope
- Constraints – Tech stack, architecture rules, limits
- Prior Decisions – What has already been decided and is not up for discussion
- Task Breakdown – Sequenced, dependency-ordered steps
- Verification Criteria – Measurable, testable acceptance criteria
The actual token-saving effect comes from the workflow that follows: The workflow separates two steps that most teams conflate: thinking and implementing.
First comes the spec—and that with a powerful model. The effort pays off: A strong model produces a plan with real depth that recognizes dependencies, identifies scope traps, and formulates implementation steps so clearly that little room for interpretation remains. The result is three documents: proposal.md for what, why, and scope, design.md for the technical design with affected files and APIs, and tasks.md as a sequenced implementation plan with testable acceptance criteria. Then follows human review—a person checks the plan and approves it.
Only then does implementation begin. And that with a less expensive model in a fresh agent with fresh context. The decisive effect: A precisely elaborated scope can be executed by a lighter model with high quality. The agent does not need to explore, guess, or iterate. It works through a clear plan. The entire exploration history of the planning phase is discarded—what remains are the results. This means implementation starts with a fraction of the input tokens that a directly started agent run without prior spec would have consumed.
2. Context Engineering: The right thing in, not everything
“Context is king” is common advice. It is half right. Too little context and the agent makes false assumptions. Too much context creates noise that degrades reasoning quality while making every turn more expensive. The precise statement is: The right context is king.
The central structure is a hierarchy:
Always loaded – AGENTS.md: One-time investment per repository. Contains project structure (prevents discovery loops through the entire repo), build and test commands, and conventions that deviate from the standard. Gets cached—cache hits cost only 10 percent of the normal input price when re-read.
What does not belong in AGENTS.md: general project documentation, feature descriptions, anything that changes more than monthly. The test criterion for every line: Does this rule deviate from default behavior, and is it relevant for more than 30 percent of daily tasks? If no—out, or into a skill.
Loaded on demand – Skills and Prompt Files: GitHub Copilot distinguishes between two mechanisms for on-demand context:
- Skills are Markdown files with heavy, reusable guidance—the agent scans only the directory at session start, knows which skills exist, and loads the full content including MCP tool definitions only when it actively needs them.
- Prompt Files (
.github/prompts/*.md) are the second mechanism: predefined workflows for repetitive tasks like “create a unit test” or “write a PR description,” which are explicitly invoked.
Both separate what is always loaded from what only comes into context on demand. It gets even more granular: Custom Instructions can be restricted to specific file patterns with applyTo globs: applyTo: "**/*.test.ts". This means: Testing conventions only land in context when test files are being edited. This eliminates the most common anti-pattern: loading all MCP tool schemas from the start, even when the majority are never called.
Check VS Code extensions and open tabs: Two often overlooked context inflators: installed VS Code extensions and open tabs. Many extensions automatically inject instructions, workspace information, or tool definitions into the agent context—without active configuration. At the same time, all open files land in the context with every Copilot request, regardless of whether they are relevant to the current task. It is worth checking both: disable extensions that do not contribute, and close unnecessary tabs. Especially in enterprise environments with standardized workstations, this adds up quickly.
Session-specific: Explicitly referenced files (@file.ts instead of #codebase), the current spec, concrete error outputs. Direct referencing instead of repository discovery prevents the agent from scanning half the codebase to find the entry point.
3. Session Discipline: The anti-chat behavior
The third discipline is the easiest to understand—and the hardest to enforce against your own habits.
One session = one bounded task. No open tab for the entire day. No “let’s have the agent check this too.” On topic change: /clear. If the agent gets stuck in a dead end: stop, roll back to the last clean commit, more precise spec—not “fix that” as the next turn.
Proactive compacting: /compact actively use it at the end of a subtask, do not wait for automatic compacting at 95 percent context capacity. Important: review the generated summary. Critical architecture decisions and conventions belong in AGENTS.md—not in the history that gets lost during compacting.
Sub-agents for parallel workstreams: Instead of one large agent for an entire feature, specialized agents with their own fresh context take over:
- A frontend agent works exclusively in the UI area and knows only the relevant UI tools
- A backend agent is restricted to the API and service layer, without access to infrastructure
- An infra agent operates only in the Terraform modules and cloud resources
An orchestrator coordinates the results—but receives only compact summaries, not the complete chat history of each individual agent.
Set explicit bounds: Agentic loops iterate until the goal is reached—or until the token budget is exhausted. Explicit stop conditions prevent this: max_attempts: 2 in the agent configuration, or a clear instruction in the prompt like “stop after the first green test run.” Without these bounds, a single agentic run can escalate uncontrollably.
Steering discipline: Supervised sessions allow early corrections—before a misunderstanding goes 20 expensive turns deep. Overnight runs are not time savers per se, but a conscious trade-off. Without a very good spec and explicit bounds, an overnight run can burn more tokens and produce more rework than a supervised 2-hour session.
Model choice: A lever, not the lever
Model choice is genuinely relevant—but it does not fix poor discipline. A 30-turn endless session with Haiku is not cheap, it is just slowly expensive.
The three-tier logic still has its place:
| Tier | Suitable for | Not suitable for |
|---|---|---|
| Lightweight | Summarizing, formatting, rename, simple tests, boilerplate | Complex implementation, architecture |
| Standard | Feature development, bug fixes, refactoring, planning | Deep reasoning, heavy decisions |
| Powerhouse | Architecture decisions, plan reviews, heavy bugs, complex specs | Simple, repetitive tasks |
For supported models, a second dimension comes into play: The Reasoning Level (low / medium / high). Many current models allow explicit control of their thinking depth. High reasoning consumes significantly more internal tokens—pure waste for simple tasks, but for complex architecture decisions or heavy debugging scenarios it can save turns and rework. The rule of thumb: treat reasoning level like model tier—calibrate to the task, do not leave it at maximum.
An important nuance: Token price is not the same as task cost. A stronger model can be cheaper overall for complex tasks because it needs fewer turns to hit the goal. A cheaper model that iterates three times and produces rework may cost more than a more expensive one that delivers precisely once. That is why we deliberately recommend a powerful model for the spec phase—not despite the higher token costs, but because of the higher efficiency in results. For simple, clearly defined tasks, the opposite applies: there, a stronger model brings no better quality, only higher costs. The measure is not the price per token—it is the price per completed task.
For organizations, Auto Model Selection is recommended as the default setting: GitHub automatically selects the appropriate model for each task—simple completions land with lighter models, complex reasoning tasks are escalated accordingly. This takes the decision away from developers in daily work, without removing the option for manual override.
A specific warning for Annual Plan subscribers: Those who stay on the old Annual Plan as of June 1 will get new model multipliers. Claude Sonnet 4.6 jumps from multiplier 1 to 9. Opus 4.6 from 3 to 27. That is a 9x increase for the same usage. Anyone actively working with premium models should switch to a Monthly Usage-Based Plan before June 1—prorated credits will be credited. Current multipliers and prices can be found directly in the GitHub Copilot Models & Pricing Documentation.
But the thesis remains: Model choice without the three disciplines does not solve the problem. It only slows it down.
Tools: What you already have—and three you should deploy
Create visibility: /usage and /context in Copilot CLI show token consumption and context capacity at any time. Preview Bill has been available in the Billing Overview since early May 2026—mandatory to understand your own baseline before switching.
Workflow mechanics: Plan Mode (Shift+Tab in Copilot CLI) is officially recommended by GitHub for token efficiency: structured plan before implementation, significantly fewer exploratory loops. /compact for proactive context compression. @datei.ts instead of #codebase for direct file referencing.
Configuration (Enterprise/Business Admins): Scope MCP toolsets—only what the project needs. Content Exclusion for build output, generated files, logs. Limitation: Content Exclusion does not work for CLI, Cloud Agent, and Agent Mode—only for Inline and Chat.
GitHub Spec Kit
GitHub provides the Spec Kit, an open-source toolkit that implements the SDD workflow directly in the editor. The three slash commands /specify, /plan and /tasks guide you structurally through the planning phases and automatically produce proposal.md, design.md and tasks.md —without manual effort outside the editor.
Spec Kit additionally brings constitution.md into the workflow: a document for non-negotiable project principles like security rules, testing requirements, and architecture constraints that take precedence regardless of any individual feature. The resulting spec files are committed to the repository and versioned. They are thus the persistent onboarding document for any agent working on the repo—today and in six months.
RTK and Caveman Mode: Two sides of the same problem
| Tool | Problem it solves | Effect |
|---|---|---|
| GitHub Spec Kit | Missing structure before agent runs | SDD workflow directly in the editor |
| RTK | Terminal output inflates context | Up to 90% less output from test runs |
| Caveman Mode | Agent produces verbose reasoning output | Up to 75% fewer output tokens in loops |
RTK – Rust Token Killer targets terminal output. Anyone who has ever watched an agent run with active test execution knows the problem: the complete output from npm test —every successful line, every runtime indication, every summary—lands completely in the context of the next turn. RTK hooks in as a pre-hook before CLI commands and compresses this output before it reaches the agent. For the agent, the compression is completely transparent—it sees the relevant result, not the raw output. In a typical 30-minute session, RTK reduces context consumption from test runs by up to 90 percent, from git diffs by about 75 percent—over a session, 60 to 90 percent fewer terminal output tokens. RTK can be installed via Homebrew with one command and configured for GitHub Copilot.
Caveman Mode targets the agent’s own output. Agentic reasoning loops produce verbose language by default: introductions, explanations, hedges, before the actual answer comes. Instead of “I am happy to help you. The error you describe is likely in the Authentication Middleware, specifically…” the agent produces with Caveman: “Bug auth middleware. Token expiry. Fix.” This enables up to 75 percent output token savings in agent-internal loops—without quality loss in the actual implementation. If you do not want to install Caveman, you can achieve the same effect via Custom Instructions: “No introductions. Answers concise. Details only on explicit request.”
The next step: Orchestrated agent pipelines
Before we talk about fully autonomous pipelines, it is worth looking at something that is already available today: the GitHub Copilot Cloud Agent.
The Cloud Agent receives an issue as input and works autonomously—without tab switching, without steering, without human corrections in the middle. That is exactly what makes it the direct test case for the three disciplines.
The issue is the spec. A vague issue with three bullet points produces an exploratory agent that scans the repository, makes assumptions, and burns expensive turns. A precise issue with acceptance criteria, file references, and explicit out-of-scope produces a targeted implementation. AGENTS.md is the entire context the Cloud Agent knows—without this file, it produces code that does not fit the project. And because there is no steering, session hygiene is no longer an option, but a prerequisite.
The Cloud Agent is thus the litmus test: Those who master Software Design Description (SDD), Context Engineering, and Session Discipline can use it productively and cost-effectively. Those who do not see the same burn as with a derailed local session—only without the ability to intervene.
What comes next: Structured multi-agent pipelines
Multiple Cloud Agent runs, orchestrated on clearly bounded sub-issues, with automated PR reviews between steps—that is the next maturity level. Buildable today with existing tools.
The question then shifts from “good prompt” to “good system design”: A planning agent defines the approach, an implementation agent executes, an evaluation agent checks against the spec, a manual review gate opens only for anomalous results. Stripe reportedly produces more than 1,300 AI-generated PRs per week following this principle—not through a free agent, but through multiple specialized ones in a structured workflow.
Fully autonomous shipping—without human review in the loop—already exists in controlled contexts. It requires very high test coverage as a proxy for manual review, narrow task scope, and complete observability. This is not a free pass for agents, but the opposite: maximum structure as a prerequisite for maximum autonomy.
The common denominator of all these expansion stages: The higher the autonomy, the more critical the initial spec quality becomes. Those who do not give up Vibe Coding will not be able to operate structured agent pipelines productively—not because the tools are missing, but because the foundation is missing.
Conclusion: The thesis holds
Back to the original question: Which model is the best?
The honest answer: It hardly matters, as long as the three disciplines are not in place. Haiku in an open 30-turn session without a spec is not cheap. Opus in a clean 5-turn session with a precise spec is not expensive.
The biggest cost lever in AI engineering is not the model. It is discipline.
Three measures that can be implemented immediately:
- Introduce Spec-Driven Development. Install GitHub Spec Kit,
/specifyrun before the next feature. Investing one turn in planning saves ten turns in exploration. - Create AGENTS.md per repository. One-time investment. Project structure, commands, critical conventions. Gets cached, pays off in every session.
- RTK configured for GitHub Copilot and up to 80 percent terminal output savings, transparent to the workflow.
These are not hacks. They are the fundamentals for the kind of AI-assisted development that will still work in six months—regardless of how pricing models evolve. Token-based billing is not the last step in this evolution.
