GPT-6 Sol prices dropped this week — re-check your cost ceiling for agents
Cheaper tokens change which agent actions are worth running — not whether the controls stay on. Teams re-check the cost ceiling before re-routing reads to lower tiers.
Last updated
7 minute read · Written by the team that builds UtilitySpaces. More about UtilitySpaces.
This week Anthropic released Claude Opus 5.5 and OpenAI released GPT-6 Sol and GPT-6 Luna as cheaper successors to the GPT-5.6 line. Per-token prices fell across the board, and the practical question for teams is not which model ranks highest but which cheaper tier earns each business-app action.
The short answer for teams running agents on real business apps: lower token prices change which actions are financially worth automating, not whether the safety guards should stay on. GPT-6 Luna earns repeated read-heavy triage — listing overdue tasks, summarising a board, checking a CRM field — on an hourly schedule without hesitation. GPT-6 Sol earns the work a human will review before it reaches the target app: draft an email reply, suggest a task comment, prepare a status update. Claude Opus 5.5 earns multi-step reasoning over cached context where instruction-following matters more than raw token cost. The approval gate, scoped access and audit trail stay in place regardless of token price, because a cheaper model call never earns the right to skip human review on a write. What changes is not the guardrail but the math — cheaper reads make hourly schedules viable, and the cost ceiling set under old prices now buys more volume than it was sized for.
What shipped this week?
On 22 September, Anthropic released Claude Opus 5.5 and OpenAI released GPT-6 Sol and GPT-6 Luna. Prices came from Simon Willison’s 22 September report and OpenAI’s announcement, listed cheapest to most expensive: GPT-6 Luna at $0.10 and $0.50 per million input and output tokens; GPT-6 Sol at $2 and $10 per million; Claude Opus 5.5 at $4 and $20 per million, with a cache-read price that fell 60% per Anthropic.
| Tier | Best for | Input | Output | Cache read |
|---|---|---|---|---|
| GPT-6 Luna | Read-heavy triage, hourly schedules | $0.10/M | $0.50/M | $0.01/M |
| GPT-6 Sol | Draft writes for human approval | $2/M | $10/M | $0.20/M |
| Claude Opus 5.5 | Multi-step reasoning, cached context | $4/M | $20/M | $0.20/M |
The cache-read discount is the one that matters most for agents: prompts that carry conversation history across turns get the bulk of their tokens from the cheap cache hit, so the effective cost per run drops below the headline input rate.
Which tier should handle each action?
Not every action needs the same model. The question is whether a specific action earns its tier, not whether the new pricing is better in general.
| Business action | Model tier | Cost ceiling | Approval required |
|---|---|---|---|
| List overdue tasks, summarise a board | GPT-6 Luna | Low | No |
| Draft an email reply, suggest a comment | GPT-6 Sol | Medium | Yes, every write |
| Reasoning over CRM fields, cached context | Claude Opus 5.5 | Medium | Yes, every write |
| Generate a proposal draft from meeting notes | GPT-6 Sol | Medium | Yes, every write |
| Full-pipeline analysis from notes to draft | GPT-6 Sol + Luna | Medium | Yes, every write |
The cost ceiling is the guardrail that turns token cost into spend control. You set it per agent schedule on the cost ceiling page, and it halts billing when usage exceeds the ceiling — no matter which model tier is under the hood.
Why your cost ceiling is now out of date
A lower price does not lower your risk of runaway spend. It raises it. When tokens get cheaper, an agent that runs unchecked can do more work for the same budget — including more wrong work. The ceiling you set under the old pricing was calibrated to a different token cost, and at the new rates that same ceiling buys more volume than it was sized for, with more chance of an unbounded loop going unnoticed.
Re-check your ceiling against the new per-token cost, then decide deliberately how much cheaper compute is worth to a given action. The ceiling is not a fixed budget across tiers — it is a per-agent budget that should tighten when tokens drop, so the financial guard does not drift while the token price does.
We build UtilitySpaces as a managed platform for teams where AI agents run against real business apps — CRM, email, project tools, Shopify — behind workspace-scoped connectors, per-action approval gates, audit trails, and per-agent cost ceilings.
Why cheaper reads finally make hourly schedules worth it
Before the price drops, scheduling an agent to run hourly against your business apps was often uneconomical. A single read-heavy triage pass across Asana, your CRM, and your inbox consumed enough tokens to make an hourly cadence noticeable on the bill. Now that math has shifted.
At Luna’s new per-million-token rate, a cross-workspace pass costs a fraction of a cent — cheap enough to justify running the agent every hour, surfacing newly overdue tasks before the end of the business day rather than waiting for a daily batch.
UtilitySpaces lets you set scheduled agents on a cron of your choice — every hour, every day, or on demand. The scheduling itself does not get cheaper with a price drop, but the per-run token cost does, which is where the new tiers finally earn their place on the schedule.
Why the approval gate doesn’t get cheaper with tokens
A lower token price makes the model call cheaper. It does not make the approval gate cheaper. The gate — every write stops for a human — exists independently of token cost, because the cost of a wrong write is not measured in tokens, it is measured in the time and trust lost when a bad action reaches your business app.
The same controls that guarded an agent before the price drops still apply: scoped access to the specific tools a workspace admin allows, an approval gate on every write, per-session credentials that never reach the model as a raw string, a reviewable audit trail, and a cost ceiling. None of those controls scale with token price. A cheaper token does not buy a shorter review queue.
Should you pin tiers or auto-route the cheap reads?
Lower prices do not remove the need for deliberate routing. Two changes are worth making today:
- Pin the tier for irreversible actions. A proposal that creates a task in Asana, sends an email, or updates a CRM field should run on a pinned tier — GPT-6 Sol or Claude Opus 5.5, depending on complexity — so that cost and quality remain predictable. Auto-routing has no place where the outcome matters.
- Leave cheap read tasks on auto. Listing overdue tasks, summarising a board, and checking a CRM field are exactly the work that GPT-6 Luna earns on an hourly schedule. Auto-routing these reads to the cheapest tier is the default that pays for itself.
In UtilitySpaces, each agent carries a role, a set of tools, and a boundary. AI agents on real business apps that are autonomous on reads and gated on writes capture the savings without expanding the blast radius.
What are the trade-offs of cheaper tiers?
Lower tokens narrow the gap between what is affordable and what is worth doing — but they do not remove the fundamental limits. An agent that reads on GPT-6 Luna and proposes a write through GPT-6 Sol is still only as correct as the data it reads and the instructions it follows. Rule drift — the process changed but the role text did not — and data drift — a project was archived, a field was renamed — produce plausible-looking output that is wrong at any price.
The clearest trade-off sits at the bottom of the pricing table. Luna is the cheapest tier and the least capable of the three: it handles routine reads and triage where a miss costs little, but it is not as smart as Sol or Claude Opus 5.5. It misses nuance, follows instructions less reliably on multi-step prompts, and can return plausible-sounding but wrong answers on anything that requires connecting distant facts. Do not route complex analysis or correctness-critical writes through Luna just because it is cheap.
When not to trust the new pricing: do not let the lower cost become an excuse to widen scope. A cheaper call that reads every workspace is still a breach of scoped access. A cheaper proposal that writes to Asana directly is still a bypass of the approval gate. The price drops justify running more cheap reads, not removing the guards that keep writes controlled.
The price drops reset the math for every agent schedule. Re-check your cost ceiling before re-checking your routing table, and keep the approval gate on regardless of token price.
Why the approval gate still matters after a price drop explains why asking before acting stays the load-bearing property of an agentic system even when token prices fall.
Keep reading
- Asana qualified: the five gates an AI agent must pass before it touches your Asana tasks — scoped access, approval gate, per-session credentials, audit trail, and cost ceiling.
- Audit logs for AI agents — how a hash-chained log makes wrong writes detectable after the fact.
Ready to run an agent on your actual business apps? Start a demo workspace — no card, no sales call.