All AI briefings
OpenAI3 min read

GPT-6.1 Sol: measure the cost of a useful result

A worked, explicitly hypothetical cost ledger separates model charges from reviewer labor and uses accepted results as the denominator.

By araNET StudioUpdated
Model usage, repeated attempts and review effort contribute to the cost of an accepted result. No invented prices or savings are shown.

AI briefing. Announcement: Sep 29, 2026 · Reviewed: Nov 4, 2026.

In this article

What was announced

OpenAI's September 29, 2026 API changelog records GPT-6.1 Sol for complex coding and professional work at a lower cost than GPT-6 Astra. A system-card addendum accompanies the release. These are provider descriptions and evaluations; neither establishes what a particular business process costs to complete.

The release is a useful reason to reconsider an integration's economics. It is not evidence that switching models will reduce the cost of accepted work in that integration.

The araNET take: price the completed workflow

Separate the provider bill from the labor bill, then divide by work accepted under the same standard. Otherwise a low token price can conceal repeated attempts or a larger review burden.

Here is a hypothetical ledger for 20 project-summary tasks. Every figure below is invented to explain the arithmetic; these are not Sol prices, measured benchmarks or araNET operating costs. Both candidates are assumed to produce 18 accepted results. All attempts, including retries and rejected results, are counted.

  • Candidate A model charges: $0.60 across all 20 tasks and their retries.
  • Candidate A reviewer effort: 60 minutes. At an illustrative $30 per hour, reviewer cost is $30.00.
  • Candidate A combined cost: $30.60; divided by 18 accepted results, approximately $1.70 each.
  • Candidate B model charges: $1.20 across all attempts.
  • Candidate B reviewer effort: 30 minutes at the same assumed rate, costing $15.00.
  • Candidate B combined cost: $16.20; divided by 18 accepted results, $0.90 each.

The model-only comparison favors A. The assumed combined comparison favors B because the reviewer-time difference dominates the small API bill. Two tasks remain unaccepted in each case; their manual completion would add further cost to a full-service comparison.

A comparison you can actually run

Build one ledger row per task: source record, candidate and configuration, number of attempts, provider charges, active review minutes, correction minutes and final disposition. Keep waiting time in a separate column rather than charging it automatically as active labor.

Define an accepted project summary before running the exercise: it identifies the correct project, preserves missing information and traces commitments to approved records. Fluent wording alone does not qualify. Use the same permitted fixtures and criteria for both candidates, including incomplete notes and conflicting dates.

Then calculate model cost per accepted result, reviewer cost per accepted result and their combined total. Show those components separately. Include any additional tool, storage or integration charges when they occur, and allocate setup costs explicitly if they matter at the expected volume. Compare with the manual process at the same quality threshold.

Keep the model choice separate from permission

A lower cost per accepted summary would justify investigating that drafting task. It would not authorize sending a client message, changing the source record or expanding access. Keep the comparison at the preparation stage until the application's permissions and release checks support the next action.

Original sources

Read next

Explore the blog