The token economy runs on decisions, not volume.
Every token your systems produce was bought — and most were bought without anyone deciding they were worth it. The teams who win this economy won't be the ones who spend the least. They'll be the ones who always know what they're paying for.
A new line on every budget
For a few years the cost of running a model was small enough to ignore — a figure buried in a cloud invoice that interested no one outside the platform team. That era is over. Companies now forecast model spend by the quarter, break it out by product, and answer to finance for it. Using a model has become a metered service, billed by the token, and the meter never stops.
The trouble is what the meter measures. It counts volume — tokens in, tokens out — and volume is almost useless as a management signal. Two teams can use the exact same number of tokens while one turns a healthy profit and the other quietly loses money on every request. A bill that grows with usage tells you that you are busy. It says nothing about whether you are getting anything back.
Value lives in the decision, not the token.
Some answers carry far higher stakes
Worth doesn't live in the token; it lives in the decision the token helps make. The model that tags a support ticket and the model that drafts the number in a report to the board may run on the same hardware and bill to the same line, but the cost of being wrong is not remotely the same. Getting one wrong means redoing a small task. Getting the other wrong can steer a major decision off course.
Good engineering organizations already act on this instinct everywhere else. You don't put your most expensive reviewer on a typo, and you don't let a brand-new hire sign off on a database migration. Work gets matched to the level of care it deserves. AI spend is one of the last places that still treats every request as if it carried the same stakes — best model, full context, maximum effort, for a job that needed none of it.
The steady load and the spikes
Look at the shape of real demand and it splits cleanly. The overwhelming majority is steady, routine work — pulling out fields, sorting items into categories, routing, summarizing, cleanup. It runs constantly and tolerates a smaller, plainer model without anyone noticing. A thin slice is the opposite: high-stakes reasoning that flares up now and then, where being right compounds into real money and paying for the best model is obviously worth it.
Running everything at the top tier is like running a full power station to light a single bulb. It works, and the bill is absurd. The systems that age well work the way an electricity grid does: cheap, always-on supply carries the steady load, while expensive capacity is held in reserve for the spikes — instead of one oversized generator wired to every outlet in the building.
Don't run a power station to light one bulb.
The dispatcher is the architecture
Once you accept that work arrives in tiers, the most important component in the system becomes the one that decides which tier each job goes to. Call it a router, a dispatcher, a load balancer — it is where economics turns into engineering. Get it right and the cheap tier quietly absorbs most of the volume while the expensive tier pays for itself. Get it wrong in either direction and you either overpay for everything or ship answers that aren't good enough.
Most teams don't have this as a deliberate layer. The routing lives in a tangle of if-statements someone wrote under deadline, or it doesn't exist at all and every request gets the most powerful model. Designing that decision layer on purpose — what goes where, on what evidence, with what fallback — is exactly the kind of durable, portable skill that outlives any single model or vendor.
The dispatcher is the architecture.
Cheaper thinking gets used more
There's a reflex that says falling token prices will solve the cost problem on their own. They won't. Every time using a model gets cheaper, demand expands to fill the room it opens up: workloads that were too expensive to run suddenly make financial sense, and teams switch them on. Cheaper thinking doesn't shrink the bill. It widens the appetite.
Flat-priced products feel this first and worst — a fixed fee against open-ended usage means every improvement that makes the product better also makes it cost more to serve, and the heaviest users quietly turn unprofitable. The discipline that answers this is unglamorous and arriving fast: real budgets, real attribution, a way to tie spend back to the outcomes it produced. The industry is going to need an accounting layer over how it spends on models the way every other kind of operation eventually grew one. That shift is coming regardless, and learning to operate ahead of it is the point.
Cheap cognition doesn't shrink the bill — it grows the appetite.
Own the steady load
Here is where ownership changes the arithmetic. Once an open model runs the routine tier well enough — and for pulling out fields, sorting into categories, and light reasoning, it already does — that work stops being something you rent by the token and becomes capacity you own outright. Open weights on hardware you control turn a meter that runs forever into a fixed cost you have already paid. The everyday work comes home.
The spikes can stay rented; there is no prize for self-hosting the hardest five percent before it is worth it. The goal isn't loyalty to open or closed, owned or hosted — it's a mix you assemble on purpose: owned capacity carrying the steady load, and the strongest models bought only for the moments that justify them. Open weights make that ownership possible; your own hardware makes it real.
Own the steady load; rent the spikes.
Learn to read the bill
None of this is a pricing trick or a vendor you haven't tried yet. It is an architecture discipline: choosing which model does which work, building the layer that routes it, grounding it in data you control, measuring whether the answer was worth its cost, and deploying the whole thing where you decide. That discipline is the thread running through everything taught here.
The accounting layer is coming because the economics demand it, not because any one company decrees it — and when it arrives, the people who already think this way will be the ones running it. The teams who win the token economy won't be the ones who spent the least. They'll be the ones who always knew what they were buying. You can become the person who decides.
Become the person who decides.
Choosing the right model for the right work — selecting, routing, grounding, evaluating, deploying — is an architecture skill, and it's the whole curriculum. Start where the token economy is already going.