---
title: "Comment by Ahmet Özel on \"Is the most expensive AI the smartest? 23 LLMs, capability vs API price (Oct 2026)\" | Hashnode"
description: "Your 1,500-input and 400-output request makes the comparison reproducible, and excluding caching and batch discounts keeps that baseline understandable. I would"
url: "https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08/comment/6ac293e183dc6fbbaabc26d3"
---

[Discussion](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08)

Comment [Is the most expensive AI the smartest? 23 LLMs, capability vs API price (Oct 2026)](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 4](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08/comment/6ac293e183dc6fbbaabc26d3)

Your 1,500-input and 400-output request makes the comparison reproducible, and excluding caching and batch discounts keeps that baseline understandable. I would add a sensitivity view that varies the input/output ratio while holding the capability score fixed. A frontier for short replies can differ from one for long generated reports, even before task-specific quality enters the picture.

For a deployment decision, cost per accepted result would be a useful companion metric: include repair attempts and discarded answers in the bill. That would preserve the broad comparison while showing why the cheapest nominal request is not always the cheapest completed extraction or classification.

[Jaehyun Cho](https://hashnode.com/@jonhisking)

[Oct 4](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08/comment/6ac293e183dc6fbbaabc26d3#reply-6ac2d717bc817f9d9dfd3dba)

Thanks Ahmet, both are fair points.

On the input/output ratio: agreed, the frontier moves. Models with cheap input but expensive output change places once replies get long, so a short-chat view and a long-report view would rank differently. For now the token counter on tokensave.app lets you paste your own prompt and set the expected output length, which gets close to that sensitivity check for one workload. A side-by-side ratio view is a good idea for a future update.

Cost per accepted result is the better number for real deployments. A cheap model that needs two retries is not cheap anymore. The hard part is that the acceptance rate depends on the task, so I'd rather expose it as a retry factor people set themselves than publish one figure per model.

Thanks for reading it this closely.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 5](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08/comment/6ac293e183dc6fbbaabc26d3#reply-6ac39d4d18d64fe8a2bed3c8)

A user-set retry factor makes sense as a scenario input rather than a published model property. I would label it as expected billed attempts per accepted result, since two retries means three attempts and can otherwise produce an off-by-one cost estimate.

Failed attempts can also be shorter than successful ones, so an optional failed-attempt output length would refine the calculation without claiming a universal acceptance rate. That would preserve the simple baseline while letting people explore whether their task's repair behavior changes the apparent cost frontier.

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[Oct 5](https://hashnode.com/posts/is-the-most-expensive-ai-the-smartest-23-llms-capability-vs-api-price-oct-2026/6ac24b6242884481ab590d08/comment/6ac293e183dc6fbbaabc26d3#reply-6ac39d71e3e7747046f6b185)

A user-set retry factor makes sense as a scenario input rather than a published model property. I would label it as expected billed attempts per accepted result, since two retries means three attempts and can otherwise produce an off-by-one cost estimate.

Failed attempts can also be shorter than successful ones, so an optional failed-attempt output length would refine the calculation without claiming a universal acceptance rate. That would preserve the simple baseline while letting people explore whether their task's repair behavior changes the apparent cost frontier.