The month the Claude bill tripled, nothing had gone wrong. Nobody had been reckless. A scoring routine I had built on the strongest model 'to be safe' was quietly re-reading the entire ICP document on every one of 4,000 leads, every night; two reps had discovered Claude Code and were running it the way you run a faucet; and the marketing Project had grown to the length of a short novel, which every chat in it re-read. Three good decisions, made by three people, on three different bills, adding up to a number that made finance ask me to come explain.
That explanation is the ledger I keep now. The generic cost-control guide covers the levers Anthropic gives you: model choice, caching, effort, batch, token counting. This is the GTM-org version: which levers apply to which of the three bills a sales and marketing team actually pays, how to cap each one before it surprises you, and how to turn the total into a cost per play that a CFO nods at.
A GTM org pays three bills, on three meters
The reason AI spend feels uncontrollable in a GTM org is that it arrives on three meters that behave nothing alike, and most teams look at the total. The first meter is seats: the Claude app, on a Team or Enterprise plan, priced per person per month, fixed regardless of how much they use within the seat's included usage. The second is Claude Code and the other usage-heavy surfaces, which on business plans draw on included usage and then on extra usage or usage credits when someone runs them hard. The third is the API: the routines and agents your builders run, priced per million tokens by model, with no seat involved at all.
Each meter has its own lever. Seats are capped by how many you buy and which tier; that is a procurement decision, made quarterly. Usage by people is capped by spend limits, which admins set at the organization, group, or user level on Enterprise, and by seat tier and extra-usage settings on Team. API spend is capped by design: which model, how much context, whether it is cached, whether it is batched. Pull the seat lever on the API bill or the caching lever on the seat bill and nothing happens, which is exactly what my tripled month looked like from the inside.
So the first move is to split the bill into three lines and name an owner for each. Seats: whoever owns headcount planning for GTM, usually the RevOps or ops lead. Usage by people: the Claude admin, with the dashboard open. API routines: the builder who wrote them, which in a small team is me. Three lines, three owners, three different conversations. The total stops being a mystery the moment it stops being a total.
TipPut the three lines on the same sheet as your other GTM tooling costs, next to the CRM and the data provider. AI spend judged alone always looks high; next to the enrichment bill it looks like a rounding error.
Seats: the fixed bill, and who gets the premium one
At the time of writing, the Team plan prices a standard seat at $20 a month billed annually or $25 monthly, and a premium seat at $100 annually or $125 monthly, with five times the usage of a standard seat and the option to mix seat types across the org. Enterprise is $20 a seat plus usage billed at API rates, with admins setting user and org spend limits. Check the price list before you quote it internally; it moves. The structure is what matters here, and the structure gives you one big decision: who gets premium.
The answer is almost always three or four people, and they are the builders, not the reps. A rep running the pre-call brief and a follow-up a few times a day lives comfortably inside a standard seat. The person building routines in Claude Code, iterating on skills all afternoon, and running a weekly agent that reads the whole pipeline will hit a standard seat's included usage by Wednesday. Giving everyone premium 'so nobody is blocked' quintuples the seat line for a team where most people were never near the limit. I did the math on our team: two premium seats and fourteen standard ones cost less than a third of sixteen premium seats, and the fourteen never noticed.
The dashboard tells you if you got it wrong. Usage analytics on Team and Enterprise shows adoption, spend by model, and where spend concentrates, and members on usage-based Enterprise can see their own consumption by product, model, and skill. When a standard-seat rep keeps hitting the limit, that is a signal they are doing builder work and should have the builder seat. When a premium seat sits at standard-level usage for a quarter, downgrade it. Seats are the one bill you can right-size with a spreadsheet and no engineering.
- Standard seat: reps, marketers, and anyone who runs plays rather than builds them. The large majority of the floor.
- Premium seat: the two to four people who build skills, run Claude Code daily, and operate the routines. Review quarterly.
- Enterprise: when you need group and per-user spend limits, custom roles, audit logs, and usage billed at API rates rather than bundled.
Spend limits: the cap on people, set before you need it
The second bill, usage by people, is where the faucet incident lives, and the fix is administrative rather than technical. On Enterprise, admins set spend limits at the organization level, at the group level with role-based access, and per user, and a member who hits their limit sees a request button that routes to an admin to approve or deny. On Team and seat-based Enterprise, admins control whether extra usage is enabled at all and manage usage credits centrally. There is even a Spend Limits API for Enterprise, so the review queue can be automated against your own policy. All of this existed the month my bill tripled. I had not turned any of it on.
The posture that works: a modest organization-wide default, a higher group limit for the builders, and per-user overrides as the exception with a reason attached. When a rep hits the default, the request lands with the admin, and the conversation is 'what are you running?' rather than 'why is the bill high?'. Two of those conversations taught me more about how the team actually used Claude than the dashboard did, and one of them turned into a skill that everyone now runs at a tenth of the cost, because the rep had been re-pasting a 30-page document into every chat.
Set the limits before the first month, not after the first surprise. A limit imposed after a spike reads as punishment and reps route around it. A limit that was always there reads as the shape of the tool.
TipTurn on the extra-usage request flow rather than blocking at the limit. The request is a free signal about who is doing what, and approving it takes one click.
Routines: model choice is the whole game
The third bill is the API, and here the levers are entirely in the builder's hands. Current list prices per million tokens: Haiku 4.5 at $1 in and $5 out, Sonnet 5 at $2 in and $10 out, Opus 5 at $5 in and $25 out, and Fable 5.1 at $10 in and $50 out. That is a tenfold spread on input between the cheapest and the strongest, and the spread is the lever. My scoring routine was on the strongest model because I was nervous. It was classifying leads into three tiers with a one-line reason. Haiku 4.5 gave the same tiers on a 200-lead sample, and the job went from a line item to a footnote.
The routing rule I use for GTM routines, which the models guide covers in more depth: Haiku 4.5 for classification, extraction, tagging, dedupe, and anything with a short answer and a clear rubric, which is most of what a nightly job does. Sonnet 5 for the plays that write for a human to read: the pre-call brief, the follow-up draft, the digest. Opus 5 or Fable 5.1 only where a wrong answer is expensive and the reasoning is genuinely hard: a forecast narrative, a complex territory plan, a QBR that has to reconcile conflicting data. Default to the middle, test downward, and promote a step only when the output on real inputs is visibly worse.
Then look at the context. The routine that re-read the ICP document per lead was paying for the same 6,000 tokens 4,000 times a night. Two fixes stack: send the lead-specific data, not the whole record, and keep the static context out of the per-lead call entirely by caching it, which is the next section. Between the model change and the context change, that routine now costs under a dollar a night for the same 4,000 leads. It used to be the single largest line on the bill.
- High-volume, simple work: classification, extraction, routing, tagging Haiku 4.5
- Most real work: drafting, research, analysis, summaries, rewriting Sonnet 4.6
- Genuinely hard reasoning and long agentic runs where being right the first time pays for itself Opus 4.8
- Haiku 4.5: scoring, tagging, dedupe, field normalization, intent classification. Short answers, clear rubric, high volume.
- Sonnet 5: briefs, drafts, digests, summaries a human reads. The default for most GTM plays.
- Opus 5 / Fable 5.1: forecast narratives, multi-source reconciliation, anything where a wrong answer costs more than the tokens. Earn the upgrade on real inputs.
Caching and batch: the two discounts GTM routines always qualify for
Almost every GTM routine repeats the same context: the ICP, the scoring rubric, the positioning, the output schema. Prompt caching lets you pay for that once and read it back at a fraction of the price. At current rates a cache write costs 1.25 times the base input price for the default five-minute window (2 times for a one-hour window), and a cache read costs a tenth of the base input price on most models. A 6,000-token rubric read 4,000 times in a night is the textbook case: one write, thousands of cheap reads. There is a minimum cacheable length per model, so short prompts simply run uncached; that is fine, they were cheap anyway.
The second discount is the Message Batches API: submit a set of requests, get results asynchronously, most batches finishing within an hour, at half the price. The question to ask of every routine is 'does anyone need this answer in the next hour?'. For the nightly score, the weekly digest, the monthly enrichment sweep, the re-tagging of the whole database, the answer is no, and the job goes through batch at 50% off. For the inbound reply that has to land while the lead is still on the pricing page, the answer is yes, and it does not.
The two stack. A nightly batch job with a cached rubric on Haiku 4.5 is the cheapest possible shape for GTM work, and it is the shape most of the work actually has. The routines that cannot take it, the real-time ones, are a minority, and they are the ones worth spending on.
- Cache: the rubric, the ICP, the schema, the few-shot examples. Anything identical across calls in a run.
- Batch: anything nobody is waiting for. Nightly, weekly, monthly jobs, and one-off sweeps over the database.
- Neither: the real-time inbound reply and the rep asking a question right now. Pay full price there and nowhere else.
The monthly ledger: cost per play, not cost of AI
The number that changed the conversation with finance was cost per play. 'We spent $2,100 on AI last month' is an invitation to a debate about whether AI is worth it. '$0.11 per lead scored, $0.40 per pre-call brief, $6 per Monday digest' is a set of unit prices that can be compared to the thing they replace, and the comparison is usually absurd in our favor. The ROI guide takes the other side of that ledger; this is the cost side.
The ledger is one sheet with a row per play. Columns: surface (seat, Code, API), model, runs this month, tokens in and out (from the API usage or the analytics CSV export), cost, and cost per run. Seat costs get allocated to plays by the share of runs, which is imperfect and good enough. The sheet takes about an hour a month once the exports are wired, and Claude Code can build the join for you from the CSVs. It is the same discipline as cost-per-lead in paid media, applied to the plays.
Publish it. Not to finance first, to the team. When a rep sees that the pre-call brief costs forty cents and saves them thirty minutes, they stop rationing it. When a builder sees their routine at $340 a month next to another at $9, they look at the model. The ledger does more cost control by being visible than any limit I have set, because it turns spend into a design question people can answer themselves.
TipAdd a 'replaces' column to the ledger: what the play replaced, and its rough cost in rep minutes or vendor fees. The row for the enrichment sweep next to the old per-credit enrichment bill is the most persuasive line on the sheet.
Setting it up: the first month
The first month is procurement and configuration, and it should happen before anyone builds a routine. Buy standard seats for the floor and premium for the named builders. Turn on the spend limits with a default, a builder group, and the request flow. Decide the model routing rule and write it on the library page next to the plays. Wire the exports: the analytics CSV for the seats and Code, and the API usage for routines, into one folder the ledger reads from.
The second month is the first ledger, and it will be wrong in ways that teach you things. Ours revealed that a 'weekly' competitive digest had been running daily since a cron typo, on Opus, for six weeks. It also revealed that the most-used play cost less than the coffee at the standup. Both facts were worth the hour.
Where it goes wrong
Everyone on premium. The seat line quintuples for a team where fourteen of sixteen people never approached a standard seat's limit. Premium is for builders; review it quarterly.
The strongest model 'to be safe'. It is the most expensive form of nervousness. Default to Sonnet 5, test Haiku 4.5 downward on real inputs, and promote only when the output is visibly worse.
Static context in the per-item call. The rubric re-read 4,000 times a night. Cache it, or move it out of the loop entirely.
No spend limits until the first spike. Then the limit reads as punishment and reps route around it. Set the defaults in month one.
Judging the total. '$2,100 on AI' is unanswerable. Cost per play, next to what it replaced, is a number a CFO can approve in one look.
The orphaned routine. A cron typo, a forgotten test job, a builder who left. Every API routine has an owner in the ledger, and the ledger is read monthly, so nothing runs unseen for six weeks again. (Ours did. Once.)
The GTM version
For a sales and marketing org, cost control is three habits. Right-size the seats, with premium for the builders and standard for the floor, and turn on the spend limits before anyone hits them. Route every routine to the cheapest model that passes on real inputs, cache the context that repeats, and batch everything nobody is waiting for. Then publish a cost per play every month, next to what the play replaced, so the team designs for cost without being told to.
Do that and the bill stops being a monthly surprise and becomes a set of unit prices you can defend in the same breath as cost per lead. Mine tripled once, for three good reasons made by three people who could not see each other's meter. The ledger is how they see it now. What is running on your account right now that nobody has looked at since it was built?
How to set it up
Split the bill into three lines and name an owner for each
Seats (fixed, per person), usage by people (Claude Code and heavy app use, capped by seat tier and spend limits), and API routines (tokens by model). Put all three on the same sheet as your CRM and data-provider costs, with an owner per line. This is the model everything else hangs on.
Buy the seats you need and turn on the limits
Standard seats for the floor, premium for the two to four named builders. In the admin settings, set an organization default spend limit, a higher builder group, and enable the extra-usage request flow so members ask rather than hit a wall. On Team, decide whether extra usage is on at all and who approves it.
TipWrite the limit and the reasoning on the library page. A limit with a rationale next to it is a design choice; an unexplained one is a grievance.
Route every routine to the cheapest model that passes
List the API routines. For each, run 100 to 200 real inputs on the model one step down and compare outputs side by side. Classification and tagging almost always pass on Haiku 4.5; briefs and drafts usually need Sonnet 5; keep Opus 5 or Fable 5.1 for the few jobs where a wrong answer costs more than the tokens.
Cache the repeating context and batch the patient jobs
Mark the rubric, ICP, schema, and examples for prompt caching so each run writes once and reads cheaply. Move every job nobody is waiting for (nightly scores, weekly digests, monthly sweeps) onto the Batch API for the 50% discount. Keep the real-time inbound reply on the standard path and pay full price there only.
Build the ledger and publish it monthly
Export the analytics CSV and the API usage into one folder. One row per play: surface, model, runs, tokens, cost, cost per run, what it replaced. Have Claude Code build the join. Share the sheet with the team first, finance second, and read it on the first working day of every month, with the routine owners in the room.
Frequently asked questions
How do you control AI costs for a sales and marketing team?
Split the bill into its three meters and cap each differently: seats by tier (standard for the floor, premium for a few builders), usage by people with organization, group, and per-user spend limits, and API routines by design (cheapest passing model, prompt caching, the Batch API). Then publish a monthly cost per play so the team designs for cost themselves.
Who should get a premium Claude seat?
The two to four people who build skills, run Claude Code daily, and operate routines. Reps running plays a few times a day live comfortably inside a standard seat. Review quarterly using the usage dashboard: standard seats that keep hitting the limit are doing builder work; premium seats at standard-level usage should be downgraded.
Can admins set spend limits on Claude?
Yes. On Enterprise, admins set spend limits at the organization, group, and user level, and members who hit a limit can request more, which admins approve or deny; a Spend Limits API automates the queue. On Team and seat-based Enterprise, admins control extra usage and usage credits centrally. Set them in month one, before the first spike.
Which Claude model should GTM routines use?
Haiku 4.5 for classification, tagging, dedupe, and short-answer jobs with a clear rubric; Sonnet 5 for briefs, drafts, and digests a human reads; Opus 5 or Fable 5.1 only where a wrong answer costs more than the tokens. Default to the middle and test downward on 100 to 200 real inputs before you decide.
How much does prompt caching save?
At current rates a cache read costs about a tenth of the base input price on most models, after a write at 1.25 times base for the default five-minute window (2 times for a one-hour window). For a routine that re-sends the same rubric or ICP thousands of times a night, that is most of the input bill gone. There is a per-model minimum length, so short prompts run uncached.
When should a routine use the Batch API?
Whenever nobody needs the answer within the hour. Nightly scoring, weekly digests, monthly enrichment sweeps, and one-off re-tagging all qualify, and they run at half price with most batches completing within an hour. Real-time plays like the inbound reply stay on the standard path.
What does a Claude routine cost per lead or per brief?
It depends on model and context, which is why you measure it. As a reference shape: a nightly scoring job on Haiku 4.5 with a cached rubric and batch pricing runs well under a dollar per 4,000 leads; a Sonnet 5 pre-call brief lands around tens of cents. The same scoring job on the strongest model, uncached and unbatched, can cost fifty times more for the same tiers.
How do we report AI spend to finance?
As cost per play next to what it replaced, not as a total. A sheet with one row per play (surface, model, runs, cost, cost per run, what it replaced) turns '$2,100 on AI' into unit prices a CFO can compare to rep minutes and vendor fees. Pair it with the three-ledger ROI model for the other side of the equation.
Sources & further reading
- Claude pricing and plans
- Prompt caching (Claude Platform docs)
- Batch processing (Claude Platform docs)
- Spend Limits API (Claude Platform docs)
- Extra usage for Team and seat-based Enterprise plans (Claude Help Center)
- View usage analytics for Team and Enterprise plans (Claude Help Center)
- Models and pricing (Anthropic docs)
Claude ships fast. This page was last reviewed Sep 4, 2026; verify time-sensitive details against the official docs above before relying on them.