Meta employees burned 73.7 trillion tokens in about a month. The number showed up on an internal leaderboard someone had named "Claudeonomics," and it was climbing fast enough that the company sent roughly 6,000 people a memo and started capping spend. The same reporting notes that Uber and ServiceNow reportedly spent their entire year's Anthropic budget in the first few months of 2026.

The leaderboard is the fun part of that story. It isn't the useful part.

If you're a business shipping your own AI feature, the useful part is this: token billing is now a running cost inside your own code, and the place it runs most quietly is a place nobody watches. Not production. Your test suite.

Where the meter actually leaks

Most teams wire up their first AI feature the obvious way. A controller takes some input, calls the model, does something with the answer. It works, it demos well, everyone moves on.

Then they write a test for it. And the natural test is the honest one: give it a real lead, let it summarize, assert the summary looks right. That test does three things, and all three are bad.

It costs money. Language models are priced per token, input and output, so every run of that test spends real dollars against your account.

It's slow. A model call is seconds, not the milliseconds a unit test should take. Multiply by a suite of them.

And it's flaky. Models don't say the same thing twice. Write an assertion strict enough to be worth anything and it'll fail on wording sooner or later. Write one loose enough to always pass and you're barely testing at all.

Now multiply all of that by continuous integration. The suite runs on every push, every pull request, and every time a developer runs it locally before lunch. A feature that costs a fraction of a cent per call in production can quietly cost more than that in CI, because CI exercises it hundreds of times a day and nobody ever sees a per-run bill. That's the leak Meta caught on a leaderboard. Your version of it is buried in a GitHub Actions log.

The fix is a seam, not a budget

The instinct after reading a story like Meta's is to reach for spending limits. Budgets and alerts are worth having. But for your own code the better move is upstream: build the feature so the model call sits behind something you can swap out.

In our own apps that "something" is an action class. We build every AI feature as an agent action on top of laravel-ai-action, a package we wrote and open-sourced for exactly this reason. The model call lives in one place: a class like EnrichLead that declares its instructions and its prompt and nothing else. The seam isn't a thing you bolt on at test time. It's how the feature was built in the first place. So faking it is one line that swaps the real runner for a fake in the container:

use App\Ai\Actions\EnrichLead;
use Pixelworxio\LaravelAiAction\Testing\FakeAgentAction;

FakeAgentAction::fakeResponse(EnrichLead::class, 'Warm lead. Enterprise. Wants a demo.');

// ... run the code that enriches a lead ...

FakeAgentAction::assertAgentCalled(EnrichLead::class);

That fakeResponse call binds the fake into the service container, so nothing anywhere in the suite reaches a provider. Your code runs exactly as it would in production, except the answer is the one you handed it. The test is instant, it's free, and it's deterministic, so your assertions can be as strict as you like.

And since the whole point here is the meter, the assertions that matter most are about tokens. The package lets you inspect a result down to assertInputTokens() and assertOutputTokens(), so you can pin a feature's token budget in a test that never spends a single one. You get to test the part you actually wrote, the prompt assembly and the response handling, instead of paying to test somebody else's servers.

What this looks like when we build it

Our own site enriches every inbound lead with a short AI pass, and it taught us the rule the hard way. The enrichment runs as a queued job, which means creating a lead anywhere in the app fires a job that calls the model. In our tests we fake that job, so creating a lead in a test never reaches a provider. The one run where we forgot, the suite went out to the live API and failed on an authentication error instead of quietly costing us money, which was the friendlier of the two outcomes.

That failure was the useful signal. If forgetting to mock something produces a real network call, the seam isn't there yet. The model call is still loose in your code somewhere, and the only reason you haven't been billed for a test run is that you got lucky with an error.

The design principle underneath all of this is old and boring, which is why it works. Your model call belongs in one place, behind a job or a service class, the same way your payment code lives behind one Stripe wrapper you also don't hit in tests. Put it there and faking it is a single line that covers the whole suite. Scatter raw client calls through five controllers and you'll be mocking in five places, missing one, and finding out on your invoice.

The 20% and the 80%

Getting an AI feature to work is the easy 20%. It's a weekend. Building it so the cost is predictable, the behavior is testable, and forgetting a mock throws an error instead of a charge, that's the 80% that decides whether the feature stays a durable part of the product or turns into a line item that creeps every quarter.

Metered pricing didn't create that discipline. It just made skipping it expensive in a way you can now measure. If you're standing up AI features in a real application and want them wired the way the rest of well-built software already is, that's the part worth getting right before the meter starts spinning. It's the same reasoning behind why we watched Copilot switch to a meter so carefully, and the same reason we're skeptical of automating a task without understanding what it was really worth. The bill always arrives. Better to have designed for it.