finance
Scaling the Discipline: Token Economics for Teams and Architectures
Token Economics Series: Part 1: Your AI Bill Is Lying to You | Part 2: The Practitioner’s Toolkit | Part 3: Scaling the Discipline | Cheat-Sheet
Individual token discipline is necessary but insufficient. You can master every lever from Part 2 — model selection, effort tuning, context hygiene, caching awareness — and still watch your team’s inference bill climb because the real cost profile isn’t determined by individual behaviour. It’s determined by architectural decisions and team culture. This article is about how to scale token economics from personal practice to organisational capability.
The Architecture Is the Budget
Here’s what I’ve learned building AI-powered products and helping teams do the same: the most impactful cost decisions aren’t made at the command line. They’re structural. They happen when someone decides how the agent configuration is shaped, what loads when, what delegates to what, and how context flows through the system.
A badly architected AI workflow is expensive regardless of how disciplined the individual practitioners are. You can have a team of people who all switch to Haiku for quick questions, compact religiously, and track their spend on a dashboard — and still burn through your budget because the underlying architecture is wasteful. Every session loads 800 lines of instructions. Every task runs in the main context window. Every tool response dumps its full output into the conversation. No amount of individual hygiene compensates for structural bloat.
This is the same lesson FinOps taught us about cloud. In cloud computing, architecture is cost structure. You don’t optimise an over-provisioned Kubernetes cluster by telling developers to turn off their laptops at night. You redesign the cluster. The FinOps analogy from Part 1 applies directly: the teams that got cloud costs under control didn’t do it through austerity. They did it through architecture.
AI inference works the same way. The architecture is the budget. Everything else is rounding.
Cost Architecture Patterns
I’ve identified four architectural patterns that have the biggest impact on inference costs. Each one prevents a class of waste structurally — not through discipline, not through reminders, but through how the system is built. That’s the key distinction. Discipline is fragile. Architecture is durable.
Subagents as Context Isolation
This is the single most important architectural pattern for cost control, and most people underuse it dramatically.
The core insight: subagents get fresh context windows. When you spawn a subagent, it starts clean. Its file reads, tool outputs, exploration, and dead ends — none of that bloats your main session. The subagent does its work, and only a summary returns to you. If the subagent reads fifty files to find the three that matter, your main context gets a paragraph, not fifty files’ worth of tokens.
Think about what this means for a typical debugging session. Without subagents, you read a file. It’s not the one you need. You read another. Wrong again. You read a third. Getting closer. You read a fourth. Found it. Now your context has four full files in it, three of which are irrelevant, and they’ll be re-sent with every message for the rest of the session. That’s thousands of tokens of waste, compounding with every exchange.
With a subagent: “Explore the authentication module and find where the token refresh logic handles expired sessions.” The subagent reads however many files it needs. You get back: “The token refresh logic is in src/auth/refresh.ts, lines 45-78. It handles expired sessions by…” Your context gained a few hundred tokens of precisely relevant information instead of thousands of tokens of exploration waste.
The decision framework is straightforward. If a task involves reading many files, searching across a codebase, or exploring unfamiliar territory — delegate it. If it’s a focused edit to a file you’ve already discussed, do it inline. The threshold is lower than most people think. I delegate anything that might touch more than two or three files I haven’t already loaded.
Model tiering makes this even more powerful. Your main session might run on Opus for high-level planning and architectural decisions. Your subagents can run on Sonnet or even Haiku for execution tasks. The model: frontmatter in subagent definitions makes this trivial — model: haiku and your file exploration runs at a fraction of the cost. The built-in Explore subagent already does this: it’s read-only, scoped to code search, and returns summaries. Use it.
One trade-off to be aware of: Agent Teams — where multiple Claude instances work simultaneously — use roughly 7x the token consumption of standard sessions. That’s powerful for parallelising large tasks, but it’s expensive. I use Agent Teams for genuinely parallelisable work where the time savings justify the cost. For sequential tasks, a single session dispatching subagents one at a time is dramatically cheaper.
Skills as On-Demand Context
Your CLAUDE.md loads at session start and stays in context for the entire session. Every line of it is re-sent with every message. If your CLAUDE.md is 500 lines of detailed instructions covering coding standards, testing patterns, deployment procedures, and content guidelines, that’s 500 lines of tokens you’re paying for on every single exchange — including the ones where you’re asking a quick question about CSS.
Skills load only when invoked. That’s the fundamental difference, and it’s the migration path that most teams need.
The exercise is straightforward: go through your CLAUDE.md and ask, for each section, “Does every session need this?” Project structure and key conventions — yes, keep those. Detailed deployment procedures — no, make that a skill. Content writing guidelines — no, skill. Database migration patterns — skill. Testing standards for a specific framework — skill.
The target is CLAUDE.md under 200 lines. That’s Anthropic’s guidance, and it’s good guidance. Everything else becomes a skill that loads when someone types the slash command. The context savings compound across every message in every session.
There’s an even more aggressive optimisation: disable-model-invocation: true in a skill’s frontmatter. By default, Claude can see skill descriptions and decide to invoke them autonomously. With this flag, even the description stays out of context until the user manually invokes the skill. If you have fifteen skills and only use two or three per session, this keeps the other twelve completely invisible to the model — zero context cost.
And skills can specify their own model and effort level. A formatting skill that runs Prettier and fixes lint issues? model: haiku, effort: low. It doesn’t need frontier reasoning to run a formatter. A code review skill that analyses architecture decisions? model: opus, effort: high. Each skill runs at the cost appropriate to its complexity.
This is the same principle as the knowledge layer — give agents access to information when they need it, not all the time. Context is expensive. Load it on demand.
Hooks as Pre-Filters
Hooks intercept tool calls before or after execution. They’re cheap — usually a shell script or a lightweight model call — and they prevent entire categories of waste structurally.
The most impactful hook pattern I’ve deployed is a PreToolUse hook on the Bash tool. Without it, Claude will happily cat a 10,000-line log file into context when what you actually need is the five lines containing the error. The hook intercepts the Bash call, checks if it’s about to dump a large output, and transforms it into a grep for the relevant pattern instead. The model gets what it needs. Your context stays clean. You didn’t have to remember to say “only show me the errors” — the architecture handled it.
PreToolUse on the Read tool is the second hook I recommend. Set a threshold — say, 1,000 lines — and block reads of files above it. Instead, the hook suggests using a subagent to explore the file. This prevents the accidental context bomb that happens when someone asks Claude to “read the main config file” and it turns out to be 3,000 lines of YAML. Without the hook, those 3,000 lines are now in your context forever (or until you compact). With the hook, the model gets a nudge to delegate instead.
PostToolUse hooks on Write and Edit solve a different problem: the lint-fix-re-lint cycle. Claude writes a file. The linter catches a formatting issue. Claude reads the linter output, fixes the formatting, writes again. The linter catches something else. Another round trip. Each cycle burns tokens on output that should have been correct the first time. A PostToolUse hook that runs npx prettier --write on every file write eliminates this entirely. The file is formatted on save. No lint errors. No rework cycle. No wasted tokens.
Here’s one I particularly like: a PostToolUse prompt hook that uses Haiku to audit file writes. type: "prompt" with model: "claude-haiku-4" — every time Claude writes a file, Haiku does a quick security review. Does it contain hardcoded secrets? Does it write to a sensitive path? Does it disable security checks? This costs almost nothing — Haiku is extremely cheap — and it catches a class of mistakes that would be expensive to fix later. It’s security review as architecture, not as process.
The key insight with all of these: each hook prevents a class of waste structurally. You don’t need to remember to grep instead of cat. You don’t need to remember to use a subagent for large files. You don’t need to remember to format before committing. The hooks do it for you, every time, automatically. That’s what scales.
MCP Tool Hygiene
MCP (Model Context Protocol) servers extend Claude’s capabilities with external tools — GitHub, databases, search engines, custom APIs. They’re powerful. They’re also a context cost that most people don’t think about.
Even with deferred loading — which is the default, meaning only tool names enter context and full schemas load on use — every active MCP server contributes some context overhead. If you have eight MCP servers configured and you’re using two of them in a given session, six servers’ worth of tool names are sitting in your context doing nothing except costing tokens.
The /mcp command lists your configured servers. Audit it. Disable anything you’re not actively using. You can re-enable it in thirty seconds when you need it. The context savings from removing five unused MCP servers isn’t enormous per message, but it compounds across every message in every session.
MAX_MCP_OUTPUT_TOKENS is a blunter but useful lever. It caps the size of MCP tool responses — the default is 25,000 tokens, which means a single MCP tool call could dump 25,000 tokens into your context. If you’re using MCP for something that typically returns small responses, cap it lower. If an MCP tool response hits the cap, you’ll get a warning, which is better than silently ingesting a response that bloats your context.
There’s a broader trade-off worth articulating. CLI tools — gh, aws, gcloud, sentry-cli — have zero per-tool listing cost. They’re just Bash commands. No schema in context. No server overhead. The output still enters context when the command runs, but there’s no standing cost for having the tool available. MCP servers are more capable — they support richer interactions, structured outputs, and the model can reason about them more effectively — but they’re more expensive in context. For simple operations where a CLI command would suffice, the CLI is the more cost-efficient choice.
Team Governance Without Gatekeeping
Everything so far has been about architecture — the technical decisions that shape cost profile. But scaling token economics to a team involves something harder: culture. And the cultural challenge is getting this exactly right: you want awareness, not austerity.
I’ve seen teams respond to a scary AI bill by locking things down. Usage caps so tight people can’t finish tasks. Mandatory approval for anything above Haiku. Model access restricted to the point where the AI tools become annoying enough that developers route around the restrictions. That’s gatekeeping, and it backfires. People find workarounds. Shadow AI usage emerges. The bill doesn’t go down — it just becomes invisible.
The alternative is awareness. Make the cost visible. Make the tools available. Help people understand what things cost and why. Trust that informed professionals will make reasonable decisions — because they almost always do, once they can see the numbers. This is the same philosophy we bring to building AI-first teams: empower people with information and trust, don’t constrain them with policies and approvals.
Visibility at the Team Level
Individual visibility — /cost, /context, status lines — is necessary but doesn’t give you the team picture. For that, you need the Admin APIs.
The Usage Report API (GET /v1/organizations/usage_report/messages) is the primary endpoint. It returns token counts — uncached input, cached input (reads), cache creation, and output — bucketed by time period (1m, 1h, or 1d). The power is in the group_by parameter: you can slice by model, workspace, API key, service tier, context window size, inference geography, and speed mode. Want to know which team is using the most Opus? Group by workspace_id and filter by model. Want to see if anyone’s using the expensive extended context? Group by context_window.
The Cost Report API (GET /v1/organizations/cost_report) gives you the same data in dollars rather than tokens. It covers token usage, web search, and code execution costs, grouped by workspace or description. When you group by description, the response includes parsed model and inference geography fields — useful for understanding not just what was spent but where and on what.
For non-technical stakeholders — finance, management, anyone who needs to see the numbers without running API queries — the Console Dashboard provides visual cost and usage reporting. It’s not as flexible as the API, but it answers the questions that most stakeholders actually ask: how much are we spending, is it going up or down, and which teams are driving the growth.
The cadence matters. I recommend weekly spend reviews, not real-time policing. Daily monitoring creates anxiety. Monthly reviews arrive too late to course-correct. Weekly hits the sweet spot — frequent enough to spot trends and catch anomalies, infrequent enough that it doesn’t feel like surveillance. Frame it as a team retro item, not an audit. “Here’s what we spent this week, here’s what we spent it on, here’s anything that looks unusual.” Five minutes. No blame. Just visibility.
Guardrails That Help
Visibility alone isn’t always sufficient. Sometimes you need guardrails — but the right kind. Guardrails that help people stay within reasonable bounds, not guardrails that prevent them from doing their jobs.
Workspace spend limits are the most important guardrail. Set them in the Console. They’re hard caps — when a workspace hits its limit, spending stops. This prevents surprises. Nobody wakes up to a $10,000 bill because a batch job ran away overnight. Set them generously enough that normal work isn’t affected, tight enough that anomalies get caught. Review and adjust quarterly.
availableModels in managed settings lets you curate the model menu. This isn’t about restricting access — it’s about sensible defaults. If your team doesn’t need fast mode at $30/$150 per million tokens, don’t put it in the menu. If Haiku handles 80% of your use cases, make sure it’s prominent. The goal is to make the cost-effective choice the easy choice. People will use whatever’s in front of them. Put the right models in front of them.
Per-key tracking for attribution without blame. The Admin API supports filtering and grouping by api_key_id, which means you can see which API key — and by extension which developer, service, or project — is driving consumption. Use this for understanding, not for scorecards. “The authentication service is using 3x more tokens than anything else — let’s investigate why” is productive. “Developer X spent the most this month” is corrosive.
One thing to be aware of: rate limits are organisation-level, not per-user. One wasteful session can affect everyone on the team. This is the strongest practical argument for team-wide awareness — your runaway batch job doesn’t just cost money, it throttles your colleagues’ interactive sessions. When the whole team understands this, peer pressure does the governance work for you, and it’s more effective than any policy.
The Observability Stack
For teams that want deeper visibility than the Console dashboard provides, there’s a growing ecosystem of observability integrations.
| Platform | Mechanism |
|---|---|
| Datadog | Native integration tile. Ingests Admin API data. Pre-built dashboards. FOCUS-compliant cost attribution. |
| Honeycomb | Custom OpenTelemetry collector (anthropicusagereceiver). Minute-level granularity. |
| LiteLLM | Open-source Python proxy. Virtual keys for per-developer/team tracking. PostgreSQL-backed budgets. |
| Bifrost | Compiled LLM gateway. Prometheus metrics. Virtual keys. Hierarchical budget controls. Zero-latency passthrough. |
When does each make sense?
Datadog is the right choice if you’re already in the Datadog ecosystem. The native integration means you can correlate AI spend with application metrics — inference cost alongside latency, error rates, and deployment events. The FOCUS-compliant cost attribution means finance can consume the data without translation. If you’re paying for Datadog already, this is the lowest-friction path to AI observability.
Honeycomb is for teams that want granular, event-level analysis. The custom OpenTelemetry collector gives you minute-level data, which means you can trace cost spikes to specific workflows, specific times of day, specific events. If your question is “why did our inference cost triple between 2pm and 3pm on Tuesday,” Honeycomb will answer it.
LiteLLM is the open-source option for teams that want full control. It sits as a proxy between your application and the API, providing virtual keys for per-developer tracking, PostgreSQL-backed budget enforcement, and model routing. If you want to build a custom cost management layer without vendor lock-in, LiteLLM is where to start.
Bifrost is for latency-sensitive workloads where you can’t tolerate a proxy adding milliseconds. It’s a compiled gateway — not interpreted, not proxied — that provides Prometheus metrics and budget controls with effectively zero latency overhead. If you’re building real-time applications where every millisecond of inference latency matters, Bifrost lets you add observability without paying for it in response time.
The Maturity Model
Putting it all together — individual practice, team governance, architecture — here’s how I think about the progression. Four stages, three dimensions.
| Stage | Individual | Team | Architecture |
|---|---|---|---|
| Unaware | No visibility, default everything | No tracking, no policy | Monolithic context, no delegation |
| Reactive | Check /cost occasionally, switch models when rate-limited | Monthly bill review, surprise at totals | Ad-hoc subagent use |
| Intentional | Status line always on, model/effort matched to task | Weekly spend review, workspace limits set | Skills extracted from CLAUDE.md, hooks filtering waste |
| Optimised | Cost per task tracked, cache patterns understood | Per-team attribution, observability dashboards | Full cost architecture: tiered models, context isolation, pre-filters |
Most teams I talk to are somewhere between Unaware and Reactive. They’ve signed up for the API or the subscription, they’re using the tools, and they have a vague sense of what it costs. Some have had the “surprise bill” moment that moves them from Unaware to Reactive. Very few have made the deliberate investment to reach Intentional, and almost none are at Optimised.
That’s not a criticism. It’s where the industry is. These tools are new. The practices are still forming. Most teams are still figuring out what AI can do for them, and cost optimisation feels premature when you’re still discovering use cases.
But here’s the thing: the jump from Unaware to Intentional isn’t that hard. It’s a week of work, maybe two. Set up status lines. Extract your CLAUDE.md into skills. Add a couple of hooks. Configure workspace limits. Start a weekly spend review. That’s it. You’re Intentional. And the difference between Reactive and Intentional — in both cost and capability — is enormous.
The billion-token brag from Part 1 is a symptom of Stage 1. The teams proudly sharing their consumption numbers have no framework for knowing whether those tokens did useful work. They’re measuring volume, not value. Moving to Stage 2 means starting to ask the question. Moving to Stage 3 means having the infrastructure to answer it.
What’s Coming
I’m writing this in early 2026, and the landscape is already more complex than it was six months ago. More models, more pricing tiers, more capabilities, more ways to spend money on inference. The next twelve to eighteen months will accelerate this.
The models arriving in late 2026 and 2027 will be more capable — and more expensive. Extended reasoning, multi-step verification, agent-native architectures that spawn their own subprocesses. The pricing models will get more complex too: per-token, per-task, per-capability, tiered by context size and speed. The simple “input tokens times price equals cost” calculation is already breaking down with cache pricing and reasoning tokens. It’s only going to get more layered.
Teams with discipline now will adapt. They have the visibility infrastructure. They have the architectural patterns. They have the cultural habit of asking “what does this cost and is it worth it?” When a new model arrives at 3x the price of the current frontier, they’ll evaluate it deliberately — use it where it matters, avoid it where it doesn’t, measure the impact. They’ll absorb the complexity because they’ve built the muscles.
Teams without discipline will hit walls. A model that’s 3x more expensive lands, someone turns it on because it’s the best, and the bill triples. No one knows why. No one knows where the spend is going. The response is a blunt cut — “everyone back to the cheap model” — which kills the productivity gains that justified the AI investment in the first place.
The inference model selection landscape is only getting more complex. More models, more trade-offs, more combinations of capability and cost. Part 2’s toolkit will grow — new commands, new visibility tools, new cost levers. But the principles are stable. Visibility before control. Architecture before culture. Intentional spending, not minimum spending. These don’t change when the models change. They become more important.
This isn’t a one-time optimisation. It’s an evolving practice. Like security, like testing, like code quality — it’s something you build once, maintain continuously, and improve iteratively. The teams that start now have a compounding advantage. The teams that start later will have to catch up while also dealing with more complex tools, more expensive models, and higher stakes.
The Series in Review
This series followed an arc: from waste to visibility to structure.
Part 1 was the provocation — the argument that token consumption is not a vanity metric, that most people are spending inefficiently, and that the problem is about to get worse as models get more powerful and more expensive. The billion-token brag isn’t a badge of honour. It’s a symptom of a discipline that doesn’t yet exist.
Part 2 was the toolkit — the specific levers, commands, and patterns that give you visibility and control over your own consumption. Model selection, effort tuning, context management, caching, and the architectural choices that shape your personal cost profile. Individual mastery.
This article — Part 3 — was the scaling story. Individual discipline is necessary but insufficient. The real cost profile is determined by architecture (subagents, skills, hooks, MCP hygiene) and culture (visibility, guardrails, awareness over gatekeeping). The maturity model gives you a map. The patterns give you the building blocks.
And the Cheat-Sheet distils all of it into a single reference.
I’ll close with the same line I used in Part 1, because it’s become more true as the series progressed: the question isn’t whether you can afford to use these models. It’s whether you can afford to use them badly. The models are getting more capable, which means the potential value is getting larger. But so is the potential waste. The gap between teams that use AI well and teams that use AI badly is going to widen — not because the tools are different, but because the discipline is different.
If you’re reading this and recognising your own team in the Unaware or Reactive stages of the maturity model — that’s fine. That’s where most people are. The path from there to Intentional is shorter than you think, and the impact is larger than you expect. Viewyonder helps teams build exactly this discipline. We’ve done it for our own products and we’ve done it for our clients’ teams, because the bill always comes due, and it’s better to be ready.
For a complementary perspective on managing the complexity that AI velocity creates, read Entropy at Velocity — it covers the codebase coherence problem that runs parallel to the cost problem.
Steve Chambers is the founder of Viewyonder, a GenAI consultancy pioneering people with AI at work. He’s built token economics practices for his own products and his clients’ teams — because the bill always comes due, and it’s better to be ready. If you’re scaling AI usage and want to scale the discipline to match, get in touch.