Cost per token is the wrong way to measure AI spend
OpenAI published enterprise guidance on managing AI investment in the agentic era, built around one idea: stop measuring cost per token and start measuring cost per accepted outcome. Here's what the five practical steps say and which one is most underrated.
OpenAI published guidance this month on a problem every enterprise running AI at scale eventually hits: token prices keep falling, but the bill keeps rising, and nobody can say with confidence whether that's waste or value. Their framing is useful precisely because it's not about a new model or product. It's an admission that as AI moves from chat to long-running agentic workflows, the old proxy for AI performance — cost per token — stops meaning much.
The headline number in the post: price per million tokens dropped 97% from GPT-4 to GPT-5.4, and GPT-5.6 adds another jump, using 54% fewer output tokens and 57% less time per task on the Artificial Analysis Coding Agent Index. None of that tells a finance leader whether their AI spend is healthy. OpenAI's answer is to replace "cost per token" with "useful work per dollar" — tasks completed, time saved, decisions improved, workflows ready to scale — and they lay out five practical moves to get there.
The five moves, compressed
See the work behind the spend. A rising bill could be waste, healthy experimentation, or a workflow quietly becoming business-critical — and you can't tell which without visibility into who's using what, at which altitude (workspace, team, product/model). OpenAI's answer is admin-console analytics; the underlying point holds regardless of vendor.
Judge models by outcome, not token price. A cheaper model that retries three times and still needs human correction can cost more than a pricier model that nails it in one pass. The metric that matters is cost per accepted outcome — a resolved support ticket, a change that passes review — paired with the business value it created.
Govern before you scale. As agents get access to tools, connectors, and computer use, governance — what context an agent can see, what actions it can take, who approves the risky steps — becomes the layer that determines what's allowed to grow, not an afterthought bolted on later.
Fund like a portfolio. Broad access for everyday productivity, function-specific workflows for repeatable work, and a smaller number of strategic bets built on proprietary context — each stage-gated through exploration, validation, and production funding, with shared infrastructure (identity, evals, observability, routing) funded centrally so each new workflow doesn't rebuild the same plumbing.
Match capacity to proven demand. Once a workflow earns its keep, the commercial and infrastructure shape should follow the usage pattern — guaranteed capacity for latency-sensitive production agents, batch or flex processing for asynchronous work, prompt caching for repeated context — rather than treating every workflow the same.
Why this matches what I see building agentic systems
None of this is abstract to me. Every agentic pipeline I've put into production shares the same failure mode this post is aimed at: it's trivial to measure tokens spent and almost impossible, by default, to measure whether an agent's output was actually useful without deliberately building that measurement in from day one. Cost-per-accepted-outcome is the right unit because it forces you to define "accepted" — a merged PR, a resolved ticket, a decision that didn't get reversed — before you start optimizing, instead of discovering after the fact that you optimized for the wrong thing.
The governance point deserves more attention than it usually gets. Teams that grant an agent broad tool access to move fast almost never revisit that access once the workflow is running well, and that's exactly backwards — the moment a workflow proves valuable enough to run unattended is the moment its blast radius matters most. Treating governance as a gate the workflow has to earn its way through, rather than a checkbox at launch, is the difference between an agent you can trust to scale and one you're quietly hoping doesn't break something.
The portfolio framing is the most transferable idea here, and it applies whether you're running one agent or fifty: not every workflow deserves the same investment, and pretending otherwise is how budgets get spent on experiments that never had a path to production in the first place.