Tokenomicon Amsterdam: the AI cost frameworks I am keeping, and where they break
On 22 and 23 September, about 500 people met at the Muziekgebouw in Amsterdam for the first European edition of Tokenomicon, co-located with FinOps X. The Linux Foundation announced Tokenomicon in June as a conference on the economics of AI, run alongside the new Tokenomics Foundation, with the FinOps Foundation and the ITAM Forum. The timing matches the data: in the State of FinOps 2026 survey, 98% of FinOps teams say they now manage AI spend, against 31% two years earlier.
I came back with 5 ideas I intend to use with clients, and a few corrections to them. The speakers shared real numbers, which makes it possible to test their frameworks against what I see in the field.
1. Cheaper tokens do not make AI cheaper
Yuriy Prykhodko (AWS) opened with what he called the illusion of cheap AI. The price for a given level of intelligence keeps falling, so it looks as if AI overall is getting cheaper. It is not. Cheaper units invite more use cases and more volume, a textbook Jevons effect. Reasoning models bill their extended thinking as output tokens, and agent loops multiply the number of calls behind a single request. You pay for the hidden reasoning, not only for the answer.
I see this right now at a client. Switching the default model roughly doubled daily spend. The difference in list price explains less than a third of the increase. The rest comes from the number of tokens each request now consumes.
This is why I stopped using cost per million tokens as a comparison metric between models. A model that is 2x cheaper per token and needs 3x more tokens to finish the same task is the expensive option. The unit that survives a model switch is cost per completed task.
To measure this on my own agent runs, I built a small open-source tool, cost-per-task. It captures token usage per API call through a local proxy (or imports Langfuse and LiteLLM logs), prices it with dated rate tables, and computes cost per attempt and cost per solved task once you label each run as passed or failed. It is MIT-licensed: https://github.com/OptimNow/cost-per-task
2. The token invoice is the smallest part of the bill you can see
Before any KPI, Yuriy listed 3 foundations: cost allocation (who uses AI), cost visibility (how much we use) and cost governance (budgets, guardrails and alerts for runaway spend). His point on visibility: the token line is only part of the cost. Infrastructure, retries and orchestration sit underneath it.
Caitlin Johnson (AssemblyAI) showed what that looks like on self-hosted GPU capacity. Her talk on trustworthy unit economics split one instance-hour of compute into 3 classes. In her masked example, $0.72 of each dollar was in use by tasks, $0.19 was idle reserved capacity, and $0.09 was "dark": instance-hours with no linked task at all. Each class has a different cause and a different owner. Idle reserved capacity is a scheduling and sizing question for the platform team. Dark capacity is often an attribution gap that nobody owns until someone measures it. She then allocated shared services in a cascade, where each shared dollar follows whatever consumed it.
The Tokenomics Foundation has proposed the same idea, in draft, under the name total cost of AI: model consumption, harness infrastructure, platform tooling, licenses, labor, energy and process change.
In one enterprise audit the foundation cites, model consumption was about a quarter of total AI spend. That is a single source and I would treat the exact share as illustrative. The order of magnitude matches what I observe: a report built only on the token invoice understates the bill by a multiple.
My caveat on allocation is practical. Tagging a VM is a deployment setting. Tagging a token requires a point in the architecture where metadata can be attached to each request, usually a gateway or a proxy. Without one, allocation stops at the API key. In my experience, the first allocation project for AI is an architecture decision, not a tagging policy.
3. Adoption is the vanity metric, concentration is the FinOps metric
Robertas Vasaris (Lundbeck) gave the talk I found most useful, under the title "The cost of a molecule". Across AI productivity tools at Lundbeck, the top 1% of users drove 36% of AI spend, and the top 10% drove 74%.
His Codex case is the one I would copy tomorrow. Usage was doubling every month. The team found that 100% of usage ran on the Fast tier and 0% on Standard, with Fast priced at about 2.5x the Standard rate in credits per million tokens. Nobody had chosen Fast as a policy. It was the default. The fix was one setting in the managed configuration. Credits dropped by 60% for the same output, with no quality loss observed and responses about 1.5x slower.
The arithmetic checks out: moving all volume from a 2.5x rate to a 1x rate removes 60% of the cost. The lesson is about defaults. Speed tiers and premium modes now exist across AI coding tools, including Anthropic's Fast mode in Claude Code, and when they are on by default, they decide the bill before any FinOps process starts.
I would add one caution on concentration. It tells you where to look, not what you will find. The top 1% of users may be the heaviest consumers of a default nobody reviewed, or they may be the people producing the most value per dollar in the company. Before capping them, talk to them. At Lundbeck, the fix was a configuration change, not a restriction on users.
4. Three layers to measure AI efficiency, with one weak link
Yuriy's framework organizes AI metrics in 3 layers, built on the 3 foundations above.
Layer | Question | Examples | Data needed |
L1: Cost efficiency KPIs (%) | Are we optimized? | Prompt caching ratio, batch vs on-demand share, global vs geo routing, model right-sizing | Consumption data, easiest |
L2: Infrastructure unit cost | What does it cost per unit? | Cost per million tokens by application, user or model | Consumption data, easy |
L3: Business unit cost and value | Is it worth it? | Cost per closed ticket or order; time saved, ticket reduction, revenue per AI-assisted sale | Value data, hardest |
You read it upward to find the value and downward to diagnose. If unit cost rises, check Layer 1: did the caching ratio drop, did batch adoption fall, did teams move to a more expensive model? The Layer 1 levers are concrete: cached reads cost up to 90% less and batch processing 50% less. On his figures, global inference profiles are about 10% cheaper than geo profiles for traffic without residency constraints.
I will use this structure. My correction is on Layer 2. Cost per million tokens mixes 2 variables that move in opposite directions: the rate you pay and the volume each task consumes. Route traffic to a cheaper model and cost per million tokens falls, even if that model needs 3 attempts where the previous one needed 1. His own chart showed the agentic application's cost per million tokens rising from January to June. Without tokens per task next to it, you cannot tell whether that is a problem or a better model finishing tasks in fewer steps.
My proposal is to keep cost per million tokens as a Layer 1 rate diagnostic, and to make cost per request or per completed task the Layer 2 bridge metric. It is still consumption data, it is still easy to compute once a gateway logs requests, and it connects to Layer 3 without a change of unit.
On Layer 3, one more distinction matters for Finance. "Time saved per employee" is a real benefit, but it is not booked value until the hours go somewhere: a hiring plan reduced, a team resized, or output someone pays for. Reported as savings before that happens, it is the fastest way for an AI program to lose credibility with the CFO.
5. The "one more dollar" test, and the workloads it cannot score
Yuriy closed with a decision rule.
Does one more dollar of AI spend generate more than one dollar of outcome?
If yes, scale with confidence and raise the budget deliberately. If no, optimize Layer 1 or retire the workload.
As a marginal test, it is the right question, and most AI reporting does not ask it. Dashboards show average cost per unit. The marginal dollar behaves differently: it goes to the heaviest users, the longest agent loops and the highest reasoning settings. A workload can be profitable on average and lose money on its last 20% of spend.
The rule has 2 limits. The first came from the same event. One of Robertas's slides stated that AI breaks FinOps twice. It breaks the meter, because AI bills per token or per GPU-second. It breaks the value, because in drug research the output is a probability that a therapy reaches a patient. "Cost is metered by the second. Value is probabilistic and years away." For that kind of workload, nobody can answer the one-dollar question within a budget cycle. Stage-gated funding, with a budget released per milestone, is a better tool there than a marginal ROI test.
The second limit is in the "no" branch. Layer 1 levers change the rate. If a workload fails the test because each task produces little value, a 50% batch discount only closes the gap when the gap was already small. Before optimizing, check which variable fails: the rate, the volume per task, or the value per task.
Ferran Grau Horta (Adevinta) added the warning that applies to every metric above: Goodhart's law. Charles Goodhart, then an adviser at the Bank of England, described the effect in 1975 about monetary targets: a statistical regularity tends to collapse once pressure is placed on it for control purposes. The short version quoted on conference slides, "when a measure becomes a target, it ceases to be a good measure", is the anthropologist Marilyn Strathern's 1997 paraphrase. The cartoon on Ferran's slide uses the old story of a nail factory: measured on the number of nails, it produces thousands of tiny nails; measured on weight, a few giant ones.
In AI FinOps, the model right-sizing KPI is where I expect it first. Measure "percentage of requests sent through the auto-router" as a target, and the ratio improves every time a small model fails and the user retries. The KPI goes up while cost per completed task gets worse.
What I am taking back to clients
Next to every cost per million tokens in a report, add cost per completed task for the same workload.
Before any other optimization on AI coding tools, list the defaults: speed tiers, premium modes, maximum reasoning settings. Check who chose each one.
Report spend concentration by user, and talk to the top 1% before setting caps.
Use the "one more dollar" test on workloads whose value is measurable within a quarter. For research and long-horizon workloads, fund by stage gate.
Keep every efficiency KPI as a diagnostic for the team, not as a target in someone's objectives.
For a quick check this week, pull last month's usage of your AI coding tools and look at the share that ran on a premium speed tier. At Lundbeck, the answer was 100%, and one configuration change removed 60% of the credits.
To compare what the same task costs across models, the OptimNow AI Pricing Hub lists current token rates across providers, each with its as-of date: optimtoken.optimnow.io
Sources
Talks at Tokenomicon + FinOps X Amsterdam, 22 and 23 September 2026: Yuriy Prykhodko (AWS), Caitlin Johnson (AssemblyAI), "Building trustworthy unit economics for AI infrastructure"; Robertas Vasaris (Lundbeck), "The cost of a molecule: FinOps when AI is the science"; Ferran Grau Horta (Adevinta). Figures are as presented on the slides.
Goodhart, C. (1975), "Problems of Monetary Management: the U.K. Experience"; Strathern, M. (1997), "Improving ratings: audit in the British University system".
.png)