LLM costs explode after launch when production traffic changes how many tokens each request carries, and the keys, ceilings, and model limits that would contain it are still set up for a pilot. The rate card rarely moves. This guide prices one realistic post-launch spike, then walks through five control gaps with the symptom you will see, the fix, and a five-day plan to close them.
A post-launch LLM cost spike, worked out
A support bot answers questions with retrieval-augmented generation on claude-sonnet-4-6, ATP list rate $3 input and $15 output per million tokens as of October 2026. It handles 40,000 requests a day and writes about 400 output tokens per answer.
In the pilot, the average request carries 2,000 input tokens. After launch, users paste contracts and email threads into the chat, and retrieval adds more chunks to answer longer questions. Average input rises to 9,000 tokens.
The monthly delta is $25,200, a 2.75× bill. The model, its price, and the request count did not change. Nothing in a pricing table would have warned you. The only signal is average input tokens per request, which you see only if you record tokens per call.
Gap 1: shared keys leave spend without an owner
Symptom: The Usage page shows one key responsible for most of the month's tokens. Three services, a cron job, and a contractor's notebook all use it. When the contractor leaves, revoking the key would break production the same afternoon, so nobody does.
Why launch makes it worse: At pilot volume, sharing costs little. After launch, any one of those consumers can spike, and the only lever is turning the key off for everyone.
Fix: Make the project the unit of ownership, with one project per production system and its own key. A key belongs to exactly one project and inherits that project's allowed models and balance, and the API keys page lists every key across workspaces and projects (managing API keys). Revoking a key stops it immediately and keeps it in the roster for audit.
Gap 2: no ceilings, so the invoice is the alert
Symptom: The staging job that ran all weekend. A retry loop sends 2 requests a second for 48 hours: 345,600 requests at 3,000 input and 300 output tokens on claude-sonnet-4-6. Each costs $0.009 + $0.0045 = $0.0135, so the weekend costs $4,665.60, found on Monday.
Why launch makes it worse: Batch jobs, agents, and retries run unattended. Without a ceiling per workload, one hot path draws on the whole organisation's balance.
Fix: Allocate credits down the tree (organisation, workspace, project) and treat each project's allocation as its cap. A project can only spend what it was given; when the balance runs out, requests return 402. With a 50,000-credit ($500) allocation on staging, the same loop stops after about 37,000 requests, roughly 5 hours in. Steps: team with budget caps. Allocated versus Consumed for every level is on the Usage page (how credits work).
Gap 3: no per-request records, so the month cannot explain itself
Symptom: Finance sees the bot go from $14,400 to $39,600. Engineering says nothing changed: same model, same price. The meeting ends without a cause.
Why launch makes it worse: Launch brings many changes at once: longer prompts, new retrieval settings, retry policy, more users. A monthly total cannot separate them.
Fix: Record project, key, model, status, and input/output tokens for every call. ATP Request logs show exactly these per request, filterable by time range, scope, model, status, and request ID (usage and logs). In the example above, filtering Request logs to the bot's project shows rows carrying about 9,000 input tokens each. Set against the 2,000 recorded during the pilot, that answers the question in minutes, provided someone wrote the pilot number down. Track average input tokens per request per project as a weekly number.
Gap 4: no model allowlist, so the expensive path becomes the default
Symptom: Policy says a mid-tier model by default. Then a developer switches the bot to a stronger model to fix a tone complaint, and it ships.
Why launch makes it worse: Volume multiplies the price gap between models. The same post-launch traffic (40,000 requests a day, 9,000 input and 400 output tokens) costs very different amounts:
Fix: Keep an allowed-model list on each project. A request for a model outside it is rejected with 403 before it reaches any provider (how it works). GET /v1/models shows what a key may call. Changing the bot's model then becomes a change to the project, made by an admin, instead of a one-line code edit.
Gap 5: no review cadence, so problems wait for the invoice
Symptom: Nobody opens the Usage page between invoices. A cap raised for a one-off migration stays raised, and an unused key from a finished pilot stays active.
Why launch makes it worse: Controls checked once before launch drift afterwards: new keys, wider allowlists, larger allocations.
Fix: A light, fixed cadence:
The Activity log records sign-ins, invites, quota changes, and resource updates, which covers most of the quarterly check.
Close the five gaps in five working days
Day 1 (Monday): inventory
Open the API keys page, which lists every key across workspaces and projects. For each key, write down which systems use it and who owns it. Mark every key used by more than one system.
Day 2 (Tuesday): split
Create one project per production system and issue new keys. Move the highest-spend service first. Set a revocation date for each shared key.
Day 3 (Wednesday): allocate ceilings
Take each project's consumption for the last 30 days, add headroom for planned growth, and allocate that as the monthly ceiling. For the support bot after launch, that is at least 3,960,000 credits. Give staging and experiments small allocations.
Day 4 (Thursday): narrow allowlists
Enable only the models each project needs. Call a disallowed model once from each project to confirm the 403.
Day 5 (Friday): instrument and schedule
Log the x-request-id header from every response next to your own feature or tenant ID. Put the weekly review on the calendar, and rehearse one key revocation end to end: revoke, check the logs, reissue.
For the per-step version of the same problem, see what is the agent tax. To set up the first project and key, follow the quickstart.
