New Reasoning Models: Price Cuts, Tiered Pricing, and Real Development Costs

Pricing: Lower List Prices and the Real Cost of Development

The standard API pricing for the new-generation reasoning model has been adjusted. Input and output token prices are now $8 and $40 per million tokens, respectively, each down 20% from the previous version. This change appears to reduce the cost of each call directly. A closer look shows, however, that a lower unit price does not mean total project spending falls by the same proportion. API billing is pay-as-you-go. It is neither a monthly subscription fee nor a fixed, bundled price for a complex project. In development work, especially complex tasks that involve many rounds of iteration and parallel processing across multiple modules, total cost depends on the number of tokens consumed per call, the number of calls, and the reasoning mode selected. It does not depend only on the list price of a single call. When estimating costs, developers should combine the price per token with the number of calls their task actually requires, rather than looking only at the list price change.

Reasoning Tiers and Coding Benchmark Scores

In coding evaluations, the new Fable-class model shows significant differences across reasoning tiers. Early test data showed that at the standard reasoning tier, the model scored about 45.3% on coding tasks. That is close to the 45.5% scored by the flagship model at its highest reasoning tier, and the per-task cost is roughly half that of the flagship model. However, when the reasoning tier is raised to a higher level, the model’s score reaches 49.1%. One easily overlooked point is that the highest score and the standard-tier score correspond to different reasoning resource allocations. When evaluating model capability or estimating project costs, do not pair the highest-tier score with the standard-tier price. Doing so would produce an overly optimistic view of cost-effectiveness. Many intelligent coding tools and platforms use the standard reasoning tier by default. This means the performance users see day to day reflects that tier’s score, not the upper limit of the highest tier. For tasks that require high-precision reasoning, developers need to adjust the tier manually and prepare for the corresponding increase in cost.

Real-World Performance and Time Efficiency in Large Parallel Tasks

In formal verification of mathematical proofs, a very demanding task, the new model’s parallel performance offers a useful reference point. In one test with roughly 1,000 agents running in parallel, the Fable-class model took 30 hours to complete the full formalization of a mathematical theorem proof, bringing the proof to a standard that machines can verify. By comparison, a flagship model at the same scale completed 26% of the overall task in 18 hours, which extrapolates to about 27% in 30 hours. Both models reported results from only one run. These results therefore reflect performance for this specific task type, this level of parallelism, and these configuration conditions. They cannot be mapped directly to success rates on general math problem solving, and the 30-hour duration should not be read as the time for a single low-cost call. This case shows the potential of parallel agent architectures for long-running, highly complex tasks. It also reminds developers that time and token consumption are two different cost dimensions. Parallel calls significantly increase total token usage, which raises API costs.

Choosing a Model Configuration Based on Cost and Performance

Selecting a model and configuration requires a multi-dimensional evaluation framework. First, define the task type. For short, straightforward tasks such as code generation and unit test writing, the standard tier is sufficient. There is no need to pay twice the price for a fast reasoning mode. Second, for complex business logic reasoning or long-chain code refactoring, the accuracy gains from a higher reasoning tier may justify the extra cost. Before committing, validate the score improvement against the cost increase on a small sample set to confirm that the two are proportionate. Third, for large tasks that can run in parallel, evaluate the distributed scheduling strategy. Increasing concurrency shortens wall-clock time, but it scales token consumption proportionally. Teams should set a reasonable concurrency ceiling based on their budget constraints. Finally, establish ongoing monitoring. Regularly review how tokens are consumed across different tasks in production, and use those findings to tune default tiers and mode selection. Avoid defaulting to the highest tier or maximum concurrency. The goal is the best balance of performance and cost.

Outlook and Conclusion

The new reasoning model offers finer-grained cost control through tiered pricing and multiple reasoning tiers. For budget-sensitive teams, the lower standard-tier price and sufficient baseline capability make it a practical default for everyday development. For teams where task quality matters most, the tier can be raised to gain accuracy. For time-sensitive parallel tasks, simulate costs in advance to estimate total token consumption. Understanding scoring benchmarks, tier boundaries, and billing logic is a prerequisite for using the model’s capabilities well. In practice, use observability tools to track metadata for each request, and record model output quality alongside the cost of each tier. Over time, this builds an internal cost-benefit knowledge base that supports continuous optimization and measured management of AI-assisted development.