
What we're seeing across dozens of teams: token prices dropped 75–99% this year. Monthly AI bills? Up 2–3×. The math doesn't add up — until you look under the hood.
We've been talking to engineering teams about their AI spend, and there's a pattern that keeps surfacing: cheaper tokens are leading to bigger bills. Not because anyone is being careless — but because the systems around API consumption haven't caught up to how people are actually using models now.
Bloomberg reported that Uber burned through its entire 2026 AI budget in four months. 5,000+ engineers, 95% using AI tools monthly, $500–$2,000 per person in tokens. The COO said hearing the overrun news was "having his head explode." They've now capped everyone at $1,500/month.
Bain looked at 951 enterprises with $100M+ revenue and found: after $1 trillion in cumulative AI spend, realized savings are way below projections. 44% of large companies are using "unrealized AI savings" to justify the next investment round. Bain calls it a "structurally flawed circular bet."
Here's the dynamic in plain terms:
| What happened | What teams did | Result |
|---|---|---|
| Token price dropped 75–99% | Opened AI access to entire company | Consumption exploded |
| Models got more capable | Shifted from code-complete to full feature generation | Per-task token use went up |
| Agent workflows became standard | Delegated multi-step tasks to AI | 7–8 API calls per "one task" |
One task, one result — that's what the user sees. But when you ask an agent to "analyze this data and build a dashboard," here's what happens behind the curtain:
| Step | Action | API Call? |
|---|---|---|
| 1 | Parse file structure | Yes |
| 2 | Model interprets intent | Yes |
| 3 | Generate analysis code | Yes |
| 4 | Execute code | — |
| 5 | Format mismatch → fix | Yes |
| 6 | Re-execute | — |
| 7 | Render output | Yes |
One task, seven API calls. All billed by the token. All on flagship models. And if something goes wrong? The agent retries — and you never see how many attempts it took.
Goldman Sachs projects monthly agent token consumption will grow 24× by 2030, even if inference costs fall 60–70% per year. The cost curve and the volume curve are moving in opposite directions.
This is the one that's genuinely hard:
A typical team's stack: dev on Claude and GPT, data science on DeepSeek and Qwen, product on Gemini, QA through a third-party proxy.
Five or six providers. Five or six dashboards. Five or six billing formats. Zero unified view.
The daily reality:
And then there's security. April 2026: LiteLLM (95M monthly installs) hit by PyPI supply-chain attack. Braintrust's AWS account compromised — Box, Stripe, Cloudflare keys exposed. The common thread isn't sophisticated attacks. It's keys scattered everywhere with no centralized management.
From building in this space, three things that make a real difference:
All model calls through one proxy. Claude, GPT, DeepSeek, Gemini — one bill, one dashboard. This isn't revolutionary engineering. It's a routing layer with normalized logging. But it changes everything about visibility.
"GPT: $3K this month" is useless. You need: "Project A spent $800, Team B spent $1,200, Session C went anomalous at 2am." That means injecting session IDs into the call chain and aggregating spend at the right level of granularity.
Burn rate spikes. Key called at 3am. Model failure rate looping. You should know when it happens — not when the monthly bill lands.
None of this is rocket science. It's the same pattern as cloud cost management — showbacks, budgets, anomaly alerts — applied to the AI API layer. The infrastructure exists. Most teams just haven't wired it up yet.
AI didn't get more expensive. You're finally seeing what it actually costs — and that's the first step toward controlling it.
If you're dealing with multi-provider billing chaos:
macOS / Linux:
curl -fsSL https://aikeylabs.com/zh/i/ih08 | sh
Windows (cmd):
curl.exe --ssl-no-revoke -fsSLo "%TEMP%\aikey-w.ps1" https://aikeylabs.com/zh/iw/ih08 && powershell -ExecutionPolicy Bypass -File "%TEMP%\aikey-w.ps1"
Windows (PowerShell):
$f="$env:TEMP\aikey-w.ps1"; curl.exe --ssl-no-revoke -fsSLo $f https://aikeylabs.com/zh/iw/ih08; & $f
Enterprise: aikeyfounder@gmail.com
The "one task, seven API calls" table is the whole story, and it's the part pricing pages never show you.
What makes it worse is that the multiplier isn't fixed. It's a distribution. Median run is cheap, p95 is single-digit dollars, p99 is $30+ because of a retry loop you never saw. So "cost per task" isn't a number you can put in a spreadsheet, it's a tail you're exposed to.
Which is why the visibility play (your points 1-3) and the pricing-unit play are complementary, not competing. You can watch every call and still be on a meter that punishes you for the one run that went sideways.
Disclosure: I'm the founder of Piramyd. We went the other direction and made the unit flat, $30/mo with unlimited tokens behind one OpenAI-compatible endpoint for Claude Code, Codex and Cursor (npx piramyd). Not because metering is wrong, but because for agent workloads the tail is the bill.
The Uber number is the one I'd frame for anyone budgeting: $500-$2,000 per person, and that was before agent workflows became the default.
This matches what I am seeing while building Tokens Forge. The dangerous metric is not just price per 1M tokens, it is token velocity per route/session.
The logs that have been most useful for us are: request owner, project, API key, model route, settlement bucket, fallback chain, and whether a retry loop happened. Once those are visible, a cost spike usually stops being a mysterious provider bill and becomes a specific route/session problem.
One thing I would add to your list: alert on token velocity, not only monthly spend. A cheap model in a loop can burn more than an expensive model with clean stop conditions. Curious if you have seen per-session alerts catch issues faster than provider-level budget caps.
Token velocity is the right lens. A cheap model with no stop condition will torch more budget than GPT-5 calling itself once and exiting. Most cost conversations fixate on per-token price because that's what the pricing page shows, but velocity is what actually burns the hole.
On per-session alerts vs. provider-level caps: we haven't benchmarked it directly, but the qualitative difference is that session-level alerts shrink the blast radius to one workflow instead of one billing cycle. The unsolved piece is false positives — legit batch jobs look indistinguishable from loops on a raw velocity chart unless you baseline expected token consumption per route.
Are you thinking of token velocity as an alerting surface, or as something you'd actually enforce against? The latter starts to look like rate limiting with cost semantics, and I'm curious which side of that line you're landing on.