The Token Tax

Every prompt is a purchase order.

Most enterprises don’t realize they’re burning half a million dollars in tokens because they treat LLMs like SaaS—something you subscribe to, not something you operate. They see the $20/seat/month line item and miss the consumption curve hiding in the API logs. But tokens aren’t licenses. They’re fuel. And if you’re not measuring the burn rate, you’re not managing infrastructure—you’re just hoping the invoice stays under the CFO’s radar.

I learned this the hard way in the NOC. Back when I was provisioning dark fiber for Alcatel-Lucent, we didn’t pay for “bandwidth” as an abstract concept. We paid for light—photons moving through glass at roughly one foot per nanosecond. Every connector loss, every splice, every kilometer of attenuation was a calculable cost against the physics of the link budget. You couldn’t negotiate with the speed of light, and you couldn’t hide signal degradation in a monthly subscription fee.

Tokens are the same physics, different substrate.

The Latency Budget

Here’s what actually happens when a 300-person company “adopts AI”:

Marketing spins up a Claude Enterprise seat. Finance builds a prompt to parse invoices. Customer service creates a workflow that summarizes tickets. Each use case looks cheap in isolation—a few thousand tokens here, a complex reasoning chain there. But then the retry loops start. The context windows grow. The agents start calling other agents to verify their work.

Suddenly you’re not paying for seats. You’re paying for decision latency—the time between intent and execution, multiplied by the cost of every token it takes to bridge that gap.

A single “simple” customer service agent that classifies tickets, routes them, drafts responses, and then double-checks its own work can burn 15,000 tokens per interaction. Multiply that by 500 tickets a day, 22 days a month, and you’re looking at 165 million tokens monthly. At current API rates, that’s not a software license. That’s a capital expense disguised as operational overhead.

The Physics of Spend

In hardware, we talk about thermal design power (TDP)—the maximum heat a system can dissipate before it throttles. Enterprise AI has an equivalent: Token Design Power. How many tokens can your workflow consume before the cost exceeds the value of the human time it replaces?

Most companies have no idea. They deploy agents like they’re free, because the marginal cost of one more prompt feels negligible. It’s the same psychology that makes people leave lights on in empty rooms—until they get the electricity bill.

The fix isn’t to stop using tokens. It’s to architect for them.

At DesLabs, we build local-first inference stacks not because we’re allergic to the cloud, but because we respect the physics. If you’re running 10,000 identical classification prompts a day against the same model, you’re not doing “AI strategy”—you’re running a manufacturing process. And manufacturing processes belong on dedicated hardware where the marginal cost of the 10,001st unit approaches the cost of electricity, not the cost of a GPU-hours API call.

The CPNI Constraint

There’s another reason telecom and infrastructure companies can’t treat LLMs like generic SaaS: the data doesn’t belong to you.

When I was monitoring fiber networks for AT&T and Verizon, we operated under CPNI rules—Customer Proprietary Network Information. Every call detail record, every network diagnostic, every piece of metadata about how traffic moved through the system was regulated. You couldn’t just pipe that into an external API because the API happened to have good reasoning capabilities.

If you’re a fiber ISP burning half a million in tokens, you’re either: 1. Sending CPNI to third-party clouds (compliance risk), or 2. Not using AI for your most valuable operational data (competitive risk).

The third option is local-first inference. Air-gapped or VPC-contained models that keep the photons—and the tokens—inside your governance perimeter. The upfront cost is higher. The marginal cost is near zero. The compliance posture is defensible.

The Library

This brings me to the prompt library problem.

If tokens are fuel, prompts are the engine design. A poorly architected prompt is a gas-guzzler—too much context, unclear instructions, retry loops because the output wasn’t structured. A good prompt library is a fleet of efficient engines, tuned for specific terrain.

But you can’t just download a prompt library from the internet. It has to be forward deployed—built inside your security perimeter, tested against your data, versioned like code, and audited like financial controls.

That’s the work. Not “AI transformation” as a slide deck, but the gritty operational work of building prompt templates that respect token budgets, agent architectures that respect compliance boundaries, and training programs that teach department heads to think in terms of cost per decision, not “seats.”

The companies that figure this out will treat AI like infrastructure—measured, optimized, and owned. The ones that don’t will keep paying the tax, wondering why their “AI initiative” has a burn rate but no ROI.

The speed of light is one foot per nanosecond. The speed of business is how fast you can make a decision without going broke on tokens.

Measure twice. Prompt once.