Price the Answer, Not the Token: AI Unit Economics
How we measure the cost of every resolved support ticket across Amazon Bedrock, SageMaker and our ticketing system, with one shared ID and Athena.
The question our token dashboard couldn't answer
In my previous article we gave every Amazon Bedrock token a name: a user, a team, a feature. We could finally tell who spent the AI budget.
Then leadership asked the next question, and none of our charts could answer it: is the support assistant worth what it costs?
That is not a question about tokens. It is a question about outcomes, and it is the question that decides whether an AI feature survives. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and that over 40% of agentic AI projects will be cancelled by the end of 2027. Escalating costs and unclear business value appear in both lists of reasons [1][2]. MIT's NANDA initiative went further: in its 2025 study, 95% of enterprise GenAI pilots showed no measurable impact on profit and loss [3].
FinOps practitioners feel the same pressure. In the FinOps Foundation's 2025 survey, "getting to unit economics" was one of the fastest-rising priorities, up five places [4]. In 2026, proving AI ROI ranks among the top three challenges of managing AI spend, right after visibility and allocation [5].
Why cost per token is the wrong unit
Unit economics means dividing what something costs by what it produces. A taxi company does not report the price of fuel per litre to its board; it reports the cost per ride. Fuel matters, but the ride is what the customer pays for.
Tokens are the fuel of AI. Customers don't buy tokens. They buy answers.
The difference is not academic. The chart below is a worked example with clearly stated assumptions, not measured data. A support assistant runs on two Bedrock models: a smaller, cheaper one and a larger one priced three times higher per token [6]. The larger model resolves more tickets on its own; every ticket it cannot resolve goes to a human agent.
A token report would tell us to pick the smaller model. The business result says the opposite, because the token bill is a rounding error next to the work the AI fails to take off a human's desk.
We pushed the same example further and asked which input actually moves the cost per ticket. We changed each assumption by a realistic amount and measured the effect.
This does not mean token optimisation is pointless. Prompt caching can make cached input tokens up to 90% cheaper, and batch inference roughly halves the price for work that can wait [8]. When AI does the entire job with no human fallback, for example classifying millions of documents overnight, those levers dominate. But wherever a person catches what the AI misses, quality is the cost lever, and only an outcome metric can show it.
The unit ladder
We now think about AI cost as a ladder with four rungs. Each rung answers a question for a different audience, and each one needs one more piece of data than the rung below it.
Most AI dashboards stop at the bottom two rungs, which only engineers can use. The top rung needs something the AWS bill will never contain: the business outcome.
A real-world use case
Our scenario is a customer support assistant in eu-west-1. Customers ask questions in a chat widget; the assistant answers with a Claude model on Amazon Bedrock and uses a small intent classifier on an Amazon SageMaker real-time endpoint to decide how to route the conversation. If it cannot help, the conversation becomes a ticket for a human agent.
Here is how one conversation travels from left to right. The support portal creates a conversationId the moment the customer starts typing and opens the ticket under the same ID. The assistant API, running on Amazon ECS on Fargate, passes the ID along: it calls Bedrock's Converse API with the ID in the request metadata, and calls the SageMaker endpoint with the same ID. Bedrock writes one invocation log entry per call with the token counts and the ID. The SageMaker endpoint is tagged with the feature it serves, so its instance hours appear in the CUR 2.0 export under that feature. When the ticket is resolved or escalated, the ticketing system sends an event with the same conversationId to Amazon EventBridge, and Amazon Data Firehose delivers it to Amazon S3. Amazon Athena joins usage, cost and outcomes, and Amazon Managed Grafana shows the product owner and finance the cost per resolved ticket.
The decision: the join key comes before the first prompt
The most important decision we made was not about models or dashboards. It was to agree on one ID before writing the first prompt, and to make every system carry it.
This sounds trivial. It is not. Bedrock only records what you send it: request metadata is optional, and calls without it are accepted [7]. Ticketing systems have their own IDs, chat widgets have session IDs, and agents create sub-requests. If the ID is added later, the historical data can never be joined again, and every month of AI usage before that day stays a cost without an outcome.
The second decision was about fixed costs. A SageMaker real-time endpoint is billed for every hour it runs, whether it classifies ten conversations or ten thousand. That cost needs a denominator too. We allocate endpoint hours to the feature by tag and divide them by the outcomes of the same day, which makes one uncomfortable truth visible immediately: at low traffic, a small always-on endpoint can cost more per resolved ticket than all the Bedrock tokens combined.
The third decision was about who defines the outcome. We let the support team, not engineering, decide what "resolved" means, for example whether a ticket reopened a few days later still counts. The number on the dashboard is only as honest as that definition.
The solution: Athena as our unit economics engine
All three data streams land in Amazon S3 and are described in the Glue Data Catalog, so the whole pipeline is serverless and costs almost nothing when nobody is looking. Everything is deployed with Terraform, including the tags, so a new AI feature gets its cost tag, its log configuration and its event rule from the same module.
Athena does the join every day. Variable cost comes from the token counts in the invocation logs, reconciled against CUR 2.0 so the estimate never drifts away from the invoice. Fixed cost comes from tagged endpoint hours. Outcomes come from the ticket events. Divide the first two by the third, and you have the number leadership asked for.
Amazon Managed Grafana shows that number next to the one it competes with: what the same ticket costs when a human handles it from the start. Customers don't buy tokens. They buy answers, and now we know what each answer costs.
The question for you
This metric changes conversations. A model upgrade that triples the token bill is no longer automatically a "no"; a cheaper model that resolves fewer tickets is no longer automatically a "yes".
So here is the question we keep asking other teams: would you approve a model that triples your token bill if it lowers your cost per resolved ticket? And if you had to name the unit of your own AI feature in one noun, what would it be?
Customers don't buy tokens. They buy answers.
Sources
- Gartner – Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025 (July 2024): https://www.intelligentcio.com/eu/2024/08/05/gartner-predicts-30-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025/
- Gartner – Over 40 percent of agentic AI projects could be cancelled by end of 2027 (June 2025): https://w.media/over-40-percent-of-agentic-ai-projects-could-face-the-axe-by-end-of-2027-gartner/
- Fortune – MIT report: 95% of generative AI pilots at companies are failing (August 2025): https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
- USU – Key takeaways from the State of FinOps 2025 report: https://www.usu.com/en/blog/state-of-finops-2025
- Virtasant – Key findings from the State of FinOps 2026 report: https://virtasant.com/blog/state-of-finops-2026
- Amazon Bedrock pricing: https://aws.amazon.com/bedrock/pricing/
- Amazon Bedrock User Guide – Cost attribution FAQ: https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-faq.html
- DoiT – The Engineering Guide to Amazon Bedrock Cost Optimization: https://www.doit.com/blog/the-engineering-guide-to-amazon-bedrock-cost-optimization
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article