My AI minions gained a new capability last month: they started costing me money in ways I hadn’t anticipated. One developer ran a heavy context window during peak hours and torched through a week’s budget in an afternoon. One step closer to world domination… but first, somebody needs to explain token economics to the entire team.
That afternoon forced me to build a real framework for AI token cost management instead of the informal “just use it reasonably” guidance I’d been relying on. This post is that framework.
Why AI Token Costs Are Harder to Manage Than SaaS Licenses
Traditional SaaS is predictable. Per seat, per month. You know what you’re paying before the invoice arrives. Token-based AI pricing is not that. Every prompt, every context window, every response is metered, and the meter runs differently depending on what your team is actually doing with the tools.
Three things catch SMB teams off guard. Peak hours burn faster, because when your whole team is prompting between 9am and 11am, every active user is drawing from the same allocation simultaneously. Token pooling doesn’t work the way most people expect, because most enterprise tier plans are structured per user with individual rate limits rather than a shared organizational bucket. And context length is the hidden multiplier that nobody talks about during the sales conversation. A user who dumps entire documents into context generates roughly five times the input tokens of someone who summarizes first and asks a targeted question. One habit, five times the cost.
The Actual Numbers
Claude API pricing runs roughly $3 per million input tokens and $15 per million output tokens for Sonnet. Haiku is $1 per million input and $5 per million output. For a developer doing active Claude Code work, expect somewhere between $13 and $30 per active day depending on context habits. Across a five-person technical team where everyone is active daily, you’re looking at $3,000 to $7,500 per month. That number surprises people who budgeted based on per-seat SaaS logic.
Prompt caching is one of the most underused cost controls available right now. If you have a system prompt that loads on every API call, enabling caching drops that repeated content to roughly 10% of the normal input rate. For teams running standardized workflows where the same instructions fire repeatedly, this cuts costs 30 to 40% without changing anything about how the team works. It’s the easiest money you’ll save.
A Budget Framework That Actually Works
Classify Your Use Cases Before You Route Them
Not all AI tasks need the same model, and treating them as if they do is where most of the unnecessary spend lives. Three tiers cover the majority of team workloads. High-stakes reasoning tasks where accuracy and nuance matter most belong on Opus. Standard professional work like drafting, summarizing, analyzing, and communicating belongs on Sonnet. High-volume routine tasks like categorization, tagging, formatting, and simple Q&A belong on Haiku. Routing 70% of your volume to cheaper models cuts total spend 50 to 60% with almost no quality loss on the tasks that don’t need the heavier model. The classification conversation takes an afternoon. The savings are immediate.
Give Users Visibility Into Their Own Consumption
When people can see what they’re spending, they self-regulate. This isn’t a policy point, it’s a behavioral one. Users who have no feedback loop have no reason to change habits. Tools like LiteLLM or Portkey add per-user logging without changing the developer experience at all. Set soft limits that trigger alerts rather than hard blocks, because hard blocks mid-workflow create more problems than they solve and train your team to work around the guardrails instead of within them.
Train Context Hygiene as a Team Habit
Before pasting a large document into context, write a two-sentence summary and ask the model whether it needs the full document. In roughly half the cases it doesn’t, and the answer is just as good. This is a thirty-second habit that can meaningfully reduce per-user consumption. It’s also the kind of practice that separates teams who use AI well from teams who use AI expensively.
Budget AI as a Real Line Item
Treat AI spend like any other operational tool cost. Give it a monthly budget, an owner, and a review cadence. I allocate by team function and keep a separate sandbox budget for experimentation that I can kill without touching production. The goal is visibility, not control for its own sake. Once you can see the number, you can manage it. Until you can see it, you’re just hoping.
The Mistake You Don’t Have to Make
A fellow CIO I know rolled out AI access across his team with a “be reasonable” policy and no usage tiers. No visibility, no framework, just access. By month three, one person was feeding entire client contracts into context on a weekly basis. He had no way to trace what was driving costs because he had never built a system to track it. He retrofitted a classification framework at month four, which works, but it cost more time and political capital than building it at the start would have.
The right time to build this is before you hand out access, and most people don’t because it doesn’t feel urgent yet. Nobody has complained. No bill has surprised you. The team is excited and you want to keep the momentum going. So you skip it.
Then month three arrives and the bill is higher than expected and you’re reverse-engineering who used what and why. That’s the moment most people build the framework, and it’s the worst time to do it because now it feels punitive instead of structural.
Ask yourself why you don’t have visibility into AI usage costs. Because you didn’t set up tracking. Why didn’t you set up tracking? Because you didn’t define usage tiers. Why didn’t you define usage tiers? Because you didn’t know what your team would actually use AI for. Why didn’t you know that? Because you handed out access before you had a use case inventory. Why didn’t you have a use case inventory? Because nobody asked for one before the rollout.
That’s the chain. Every link is fixable, and Claude can help you work through all of it before you flip the switch. Start a planning conversation, paste in your team’s likely use cases, and ask Claude to help you define tiers based on data sensitivity, context window size, and how frequently each use case runs. Document the output in whatever system your team already lives in. Low, medium, and high sensitivity with concrete examples for each tier is enough to give you visibility before a surprise bill forces the conversation.
Treat AI Spend Like Infrastructure, Not a Perk
The right mental model here is cloud compute, not software licenses. Nobody gives developers unlimited EC2 access with no tagging, no budgets, and no visibility. You instrument it, you set guardrails, you review it on a cadence. The tooling for AI cost management is less mature than AWS Cost Explorer right now, but the discipline is exactly the same. Organizations that are managing AI token costs well have made a conscious decision to treat it as infrastructure spend with real governance rather than an experiment they’ll sort out later.
The teams that get ahead of this in the next twelve months are going to have a significant operational advantage over the ones who are still untangling their first surprise invoice. The framework isn’t complicated. Build the tiers, add the visibility, train the habits, and put it on the budget. That’s the whole thing.
If you’re starting from scratch, pick one team or one workflow and run the classification exercise this week. You’ll have a working tier structure in an afternoon and a cost baseline within thirty days. That baseline is what makes every subsequent decision smarter.