The cheapest model can cost more: Nufar Gaspar's token-smart case for AI operations

AI teams are moving from a simple adoption question to a harder operating question: what did the intelligence actually produce? In The AI Daily Brief's Operator's Cut with Nufar Gaspar, the proposed answer is to stop treating token spend as a number to minimize and start measuring the total cost of a usable result. A cheap model that needs more retries, more context and more human correction can cost more than an expensive model that finishes the task in one pass. 1

Gaspar is an AI and agents consultant and trainer. Her official profile says she has worked in AI for 15 years and trained more than 20,000 professionals in 30 countries. That background matters here: she is not presenting token economics as an abstract pricing lecture, but as a problem she encounters while helping people build agentic systems. 2

Gaspar describes four phases of AI usage. The first was token-oblivious: flat subscriptions hid the meter. The second was token-maximizing: usage leaderboards made high consumption look like proof of maturity. The third is token-anxious, or token-minimizing, when employees self-censor because every ambitious prompt appears to require an ROI defense. The fourth is the target: token-smart usage, where teams spend enough to learn and build, then remove the consumption that produces no accepted work. 1

The distinction is important because expensive use and waste are not the same thing. A failed experiment can teach a team which model, prompt or workflow works. An idle agent can consume the same budget while producing nothing. Gaspar's sharpest warning is that the most expensive token may be the one a capable employee is afraid to spend. A company that saves on exploration may protect this month's bill while slowing the workflows that could have created much more value.

That does not rescue leaderboards as a management system. The episode treats gaming as predictable whenever a metric carries real stakes. Activity dashboards measure activity. They do not establish that the activity improved a product, shipped code or solved a customer problem. The better goal is to make usage visible without turning low consumption into the reward.

The practical reason token accounting is so slippery is that a token is a piece of text, usually smaller than a word, and each model provider tokenizes text differently. Gaspar says the same document can require 10% to 20% more tokens on one provider than another, with larger differences for code and non-English text. She gives Hindi, Thai and Greek as examples that can use two to five times more tokens for the same content than English. Those are operating variables for a multilingual team, not footnotes in a pricing comparison. 1

There is a second layer that many users cannot see. Input tokens cover prompts, history, files and tool definitions. Reasoning tokens are generated inside the model and priced closer to output rates. The visible answer may be 400 tokens while the model has spent thousands of hidden reasoning tokens to produce it. Higher effort settings can multiply consumption by roughly 10 to 12 times versus low or medium effort, and the episode argues that more thinking is not automatically better for simple questions. 1

The economic lesson is the same as with a changing package size: a stable price per million tokens does not guarantee a stable price for the same job. Gaspar cites the April change to the Opus 4.7 tokenizer as an example. The price sheet stayed the same, while independent analyses discussed in the episode found higher token counts for the same text and real-world bills rising by roughly 12% to 27%, partly offset by caching. The claim is not that every tokenizer update is a hidden price increase. It is that buyers need to track effective cost on a fixed workload instead of trusting the sticker price. 1

Agentic work magnifies all of these effects. The episode says agentic workflows can use five to 30 times as many tokens as a simple chat, with a typical task involving 10 to 20 model calls. Around 60% of the cost may sit in checking, refining and regenerating after the first answer. The expensive step is often the distance between an answer and an accepted result. 1

That is why the episode's Databricks comparison is more useful than a model leaderboard. Sonnet 5 was 1.7 times cheaper per token than Opus 4.8, but the reported cost per coding task was about $2.09 for Sonnet and $1.94 for Opus because Sonnet needed more iterations and reasoning. Running the same model through different agent harnesses also produced more than a twofold difference in task cost, mainly because one harness supplied about three times less context. The model is only one part of the bill. Context assembly, tool design, retries and the quality bar matter just as much. 1

Gaspar's proposed metric is cost per accepted task. To measure it, take five to ten representative workloads and hold the input and quality bar steady. Compare first-pass success, human correction, elapsed time, total tokens and total cost. The winner is not the model with the lowest rate; it is the stack that completes the real work reliably. This also forces teams to count review and rework, which are easy to hide when a dashboard reports only token volume.

Gaspar divides spend into three categories. Tokens that teach cover experiments, failed workflows, identity files, curated context and memory that help a person or an AI system learn what works. Tokens that produce create a proposal, research result, code or another usable deliverable. Tokens that spin are idle agents, bloated context, machine-to-machine loops, over-frequent jobs, irrelevant retrieval and rework that adds activity without value. 1

Her own example makes the category concrete. While traveling and not using her OpenClaw chief-of-staff agent, she discovered that it had spent about $1,500 in two weeks, consumed almost 400 million input tokens and produced almost no output. The input-to-output ratio was roughly 2,600 to 1, and a compaction job was running every 30 minutes on empty sessions. This was not a spectacular model failure. The system was doing what it had been configured to do, but the configuration no longer justified the cost. 1

The audit can start with a simple weekend test: if nobody does AI work and the bill still rises, find the background process. Then inspect extreme input-to-output ratios, list every scheduled job and ask what business value it created last week, and set caps and alerts for sudden usage jumps. Start a new session for a new task, right-size the context, choose the model for the workload, filter retrieval, and stop a job when it is clearly headed in the wrong direction. An automation that nobody has used for one or two weeks is a strong candidate for deletion, even if its original idea was sensible. 1

The organizational policy follows from the same accounting. Make usage visible, but budget by workload and role rather than applying one ceiling to everyone. A person building reusable skills and context for a team may deserve a larger budget than someone using an AI tool as a faster search box. The point is not to defend every token. It is to distinguish learning from output, and both from the loops that only make the meter move.