Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AI bills can be difficult to interpret because token counts may not capture every cost driver, and agent workflows can keep generating usage beyond what a team expected. That is the problem behind You Can’t Trust Your AI Bill. And Neither Can I, a QCon AI Boston presentation scheduled for June 2, 2026. The event listing identifies Erik Peterson, CloudZero’s founder and CTO, as the speaker. Its description proposes treating cost as an engineering constraint—not merely a finance report—and asks whether each engineering decision was worth its cost.
What the QCon presentation is about
QCon’s event listing frames AI billing as different from cloud billing and names four sources of complexity: hidden reasoning tokens, tokenizer gaps, Model Context Protocol (MCP) overhead, and what it calls an “o1-vs-o3 pricing paradox.” These are announced themes, not findings independently demonstrated by the event page. The listing does not explain the specific mechanisms behind each example or compare vendors, models, or billing systems.
The scheduled date, June 2, 2026, has passed. The available event page establishes that the presentation was listed on the Boston program; it does not confirm that it was delivered or recorded. The description should therefore be read as the talk’s announced argument, not as a transcript or a verified account of its conclusions.
What the event listing claims about AI spending
The listing says that “tokens are 1,000x cheaper than they were three years ago” while aggregate AI spend is “up 320%.” It provides no dataset, definition of aggregate spend, population, or measurement method. Those numbers are claims made in QCon’s 2026 session description, not independently established industry statistics.
#1 Best Overall
The same description cites a “$47K eleven-day loop,” an “$82K stolen key,” a “five-figure eval bill,” and an engineering team that used its annual AI budget in weeks. It supplies no incident reports, organization names, or further context. The examples signal the kinds of spending failures the talk intends to examine, but they cannot establish how common such incidents are or what caused them.
Why an AI bill can be hard to interpret
Token counts may not tell the whole story
A team may compare prompts and visible outputs while missing other usage that affects a bill. The QCon description specifically calls out hidden reasoning tokens and tokenizer gaps, but it does not define either term or quantify their effect. A practical implication is to reconcile the provider’s usage records and pricing rules against what an application logs, rather than assuming that a count of text sent and received is a complete cost ledger.
Tool use can add costs outside the model call
The listing names MCP overhead as another theme. It does not specify which MCP components incur charges or how large those costs might be. When an AI workflow invokes tools or services, teams should measure those components separately where possible; otherwise, a model-only view may fail to explain the full workload cost.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Pricing comparisons need a consistent task
The “o1-vs-o3 pricing paradox” is mentioned but not explained in the event listing. The safe takeaway is not that one model is always cheaper or more expensive. A useful comparison must account for the same task, input and output volume, applicable model pricing, and the quality of the result. The lowest price per token does not by itself establish the lowest cost for a useful outcome.
How teams can put cost into the engineering design
QCon’s description recommends “economic constraints as first-class design” and names engineering-first metrics, circuit breakers for agents, and routing models by margin. It reports no measured outcomes for these ideas and gives no implementation details. The following are practical ways to operationalize those themes, not results attributed to the presentation.
Measure cost at the workload level
- Associate usage with a workload, feature, team, or customer so a total bill can be traced to the systems producing it.
- Record model and tool usage alongside an outcome, such as a completed task or accepted result, to make cost per useful outcome visible.
- Compare application-side records with provider usage and invoice data; investigate gaps rather than treating either view as automatically complete.
- Track both aggregate spend and unit costs. A falling unit price can coexist with a rising total if usage grows.
Set limits before an agent runs
A circuit breaker is a control that stops or pauses work when a defined condition is reached. For an agentic workflow, teams can set limits around the conditions they can observe—for example, maximum runtime, number of tool calls, or a workload budget—and define what happens at the limit: stop, request approval, or fall back to a bounded process. The event listing recommends circuit breakers but does not specify thresholds or report test results. Limits should be tested against normal and failure behavior so an unexpectedly long loop cannot run without a clear stopping condition.
Route by value, not price alone
Model routing by margin means considering economics when choosing which model handles a task. In practice, teams need to weigh the model’s cost against task quality and the value of a successful result. A cheaper route that fails more often may cost more after retries or human correction. Define the quality bar first, measure cost for comparable tasks, and route only when the lower-cost option meets that bar.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How to judge whether an AI workload is worth its cost
The central question in QCon’s description is whether an engineering decision was worth its cost. A defensible answer requires more than a monthly total: identify what the workload accomplishes, measure what it consumes, and decide what trade-off is acceptable.
Best Value
- Define the outcome. Specify what counts as a completed, useful result, rather than treating every model response as success.
- Attribute the full workload. Include relevant model and tool usage, and reconcile internal logs with provider billing records.
- Measure cost per successful outcome. Include retries, failed attempts, and any material human correction that the workflow requires.
- Set a quality and cost boundary. Decide the minimum acceptable result quality and the maximum spend or runtime for the task.
- Revisit the design as usage changes. A unit-cost reduction does not guarantee a lower total bill if workload volume or workflow behavior changes.
This approach turns “Was yours worth it?” into an engineering question that can be answered for a defined workload. The event listing supplies the framing and proposed controls, but leaves the metrics, thresholds, and measured impact to the teams applying them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
