How to Compare AI Task Costs and Split Coding Work Across Models

In this July 2026 video, Matthew Berman argues that effective AI use requires more than comparing the price of a million tokens. Different models can use different numbers of tokens, take different amounts of time and achieve different results on a task. He proposes choosing models for each stage of a workflow instead of using the same model everywhere.

A token is a unit a model processes, not necessarily a whole word. Berman shows a tokenizer where a simple sentence splits roughly into words, while “programmatic” splits into smaller pieces. Autoregressive language models generate sequences by predicting successive tokens; tokenization depends on the model and text.

Berman compares the prices visible in the video: GPT-5.6 Sol at $5 per million input tokens and $30 per million output tokens, versus his quoted Kimi K3 prices of $3 and $15. Those are historical examples, not a current price quote; rates can differ by provider, context length, caching and service tier.

Benchmark scores can look competitive even when token prices differ. Berman’s point is to consider the total cost of a useful outcome, including how much each model generates. Similar scores on selected tests do not guarantee equal reliability or quality for a particular application.

The Artificial Analysis chart shown in the video labels its metric the weighted average cost per Intelligence Index task: about $0.95 for Kimi K3, $1.04 for GPT-5.6 Sol and $2.75 for Claude Fable 5 in the displayed configurations. These are costs per benchmark task, not necessarily costs per successfully solved task. The comparison is tied to that benchmark, model settings and pricing.

Berman interprets the similar task costs as an example of a cheaper token price being offset by greater token use. He illustrates it with one million output tokens at $30 versus two million at $15 per million, both costing $30. This is illustrative arithmetic, not a demonstrated universal two-to-one token ratio across tasks or a complete calculation of input, caching and retry costs.

He calls this “intelligence density” and offers his opinion that OpenAI’s models lead on it in his experience. That is his interpretation, not a standardized property of individual tokens. Measuring quality, success rate, total spending and latency on the actual workload provides a more useful comparison.

Berman argues that models have different strengths and suggests using one to review code produced by another. In a sponsored section, he cites Greptile’s comparison of Claude Opus 4.7 and GPT-5.5: in its displayed sample, each reviewer found a greater share of high-severity bugs in the other model’s pull requests than in its own. The vendor’s finding is limited to its study and does not guarantee independent review will catch every defect.

Speed matters too: a lower API bill can come at the cost of a longer wait. Berman uses a hypothetical 30-minute versus one-hour task to illustrate why a team should weigh latency and human time as well as model charges. Actual completion time depends on the provider, throughput, workload and retries.

For difficult coding tasks, Berman describes three stages: use a strong model to plan, a cheaper fast model to implement, and a different strong model to review. In his example Claude Fable produces a specification after examining the codebase, a cheaper model such as Grok 4.5 or Cursor Composer executes it, and GPT-5.6 reviews the result against the specification.

His rationale is that planning requires broad context and judgment, while implementation may generate a large volume of expensive output tokens. A reviewer then reads substantial material but produces a relatively short assessment. This is a useful division of labor to test; the assumption that implementation is always easy or needs only the plan will not hold for every codebase.

Berman presents a hypothetical budget: one million input and 100,000 output tokens for planning, 100,000 input and one million output for execution, then one million input and 100,000 output for review. His displayed estimates are $81 using Fable throughout, $46.50 using GPT-5.6 throughout and $25.55 using a mixture. These numbers depend on the assumed token volumes and rates, and they do not demonstrate equal quality, account for iteration or establish real savings for an untested project.

He also expects a faster execution model to reduce elapsed time. That can happen, but splitting work between models adds handoffs and may increase context transfer, review or rework. Teams need to compare complete workflows using tests and outcome quality, not only the hypothetical bill.

Berman then discusses the economics of open and closed models. He argues that downloadable, openly available models can be hosted and optimized by competing providers, potentially putting downward pressure on inference prices. He contrasts that with proprietary frontier models available from their owners or partners, and characterizes OpenAI and Anthropic as the leading providers in his account.

He predicts that as open-model serving becomes more competitive, revenue and profit opportunities will shift toward chips, cloud infrastructure and applications. He also expects lower prices to encourage more usage. These are market hypotheses, not guaranteed outcomes: margins, demand, licenses, infrastructure costs and the competitive landscape can all change.

Berman concludes that model pricing and openness matter across the AI stack. His proposed practical step is to assess total task economics and combine models where their strengths fit the workflow. The examples are a snapshot of his July 2026 view and should be checked against current rates and real-world results before making a buying decision.