In this briefing
- OpenAI released GPT-6 Sol and GPT-6 Luna, creating a price gradient within one model family for complex Agent work and high-throughput tasks. Long context, processing tiers and interface choices will still alter the actual cost.
- Anthropic released Claude Opus 5.5, with list prices for input, output and cache reads below those of Opus 5, and reported a reduction in total cost for typical tasks. That reduction comes from vendor tests, while migration also brings compatibility changes to thinking modes and tool calls.
- Together's staged rollout mechanisms and vLLM 0.30.0's start-up and memory features show that production costs also include overlapping capacity during a switch, human intervention, cold starts and GPU or host-memory use. They cannot be inferred from the price per million Token alone.
Model prices first form a gradient for different tasks
On 22 September, OpenAI released GPT-6 Sol and GPT-6 Luna. Both are available through the Responses API and Chat Completions API, and their model pages list a 1,050,000 Token context window and 128,000 maximum output Tokens. For Standard requests with no more than 272K input Tokens, Sol costs US$2, US$0.20 and US$10 per million input, cached-input and output Tokens respectively; Luna costs US$0.10, US$0.01 and US$0.50 respectively. OpenAI positions the former for complex coding and Agent workflows and the latter for focused, high-throughput tasks. That positioning and price difference do not prove that they offer equivalent capability on the same task.
On the same day, Anthropic released Claude Opus 5.5. Standard pricing per million is: input Token 4 dollars, output Token 20 dollars, a 5-dollar 5-minute cache write and a 0.20-dollar cache read. Compared with Opus 5 list prices of 5 dollars for input, 25 dollars for output and 0.50 dollars for cache reads, these items fell by 20%, 20% and 60% respectively. Anthropic also says that, at default settings, total cost for typical workloads can be 40% lower and output can be more than 30% faster. These are vendor tests and early-user accounts, not independent measurements across enterprise production environments.
For enterprise adoption, the unit price per Token can be the first input to a budget, but it cannot replace records of success rates, total input and output, tool calls, retries, end-to-end time and human review on the same business task. The models address different levels of task difficulty, reasoning settings and service tiers, so the price list cannot be converted directly into a ranking of cost per completed task.
Migration boundaries change the work beyond the price list
OpenAI's model documentation states that neither Sol nor Luna supports fine-tuning, and EU data residency is available only with Standard processing. When input exceeds 272K Token, the input and cache rates for the whole request are multiplied by 2, while the output rate is multiplied by 1.5. Chat Completions supports function calls only when reasoning effort is set to none; built-in tools and ordinary function calls should use the Responses API. Task routing within the same provider must therefore still check context length, data geography, interface and tool-chain conditions together.
Anthropic's official migration documentation, checked on 23 September, lists several incompatible changes. Anthropic states that thinking cannot be disabled in Opus 5.5; forcing a specific tool returns an error, thinking blocks are bound to the model and conversation, and the old computer tool is no longer accepted on some platforms. The default effort also changes from high in Opus 5 to medium in the new model. Fast mode remains a research preview available only through the Claude API, priced per million at input Token 8 dollars and output Token 40 dollars. Migration is not only a model-name replacement: existing prompts, tool selection, conversation continuation and budget assumptions may all need regression testing.
For enterprise adoption, migration cost includes interface changes, renewed checks of permissions and data residency, rerunning benchmark sets and preparing failure fallbacks; it cannot be reduced to a comparison of old and new unit prices. The public documentation describes compatibility boundaries, but does not provide the person-hours or failure rate for completing a migration in a particular enterprise system.
Staged rollout puts overlapping capacity and human intervention on the bill
On 22 September, Together described a new rollout engine for Dedicated Inference, supporting canary, blue-green and rolling strategies. Canary can move traffic in stages and check error rates, latency and in-flight requests. Blue-green retains full capacity on both sides until the old version has drained, while rolling normally keeps one additional replica during each step. The three approaches differ in risk isolation and switching speed, as well as in the additional GPU capacity needed during the transition.
The mechanism's boundary is more specific than the page headline. When a metric gate triggers, the system enters SYSTEM_PAUSED and freezes the current traffic share; it does not execute an automatic rollback. The operator must cancel the current rollout, then exchange source and target and start a reverse rollout. In a vendor demonstration switching Qwen2.5-7B to Qwen3.5-9B with one H100 for each model at 5 requests per second, Together says the target p95 latency was 1,740 milliseconds versus 734 milliseconds for the source at the 10% traffic stage, exceeding a 25% regression budget and pausing the rollout. This was a single vendor demonstration and cannot be generalised into a performance conclusion for other models, hardware or loads.
For enterprise adoption, the cost of a model update also includes retaining old and new capacity in parallel, an observation window, human judgement during a fault and the time required for a reverse rollout. Staged gates can limit the affected scope, but they do not amount to automatic recovery and do not remove the need to define business-side rollback conditions and responsible roles.
Self-hosted runtimes make start-up and memory use visible
On 22 September, vLLM released 0.30.0, adding support for models including DeepSeek-V4.1-Flash and GLM-5.3-Flash and providing CUDA, ROCm, CPU and XPU builds. Fast Start uses a persistent weight-cache daemon for each GPU to retain quantised, tensor-parallel-sharded weights. When the engine restarts, it maps them through CUDA IPC rather than loading them again from disk. This mechanism comes at the cost of continuing to occupy the corresponding GPU memory.
HiSparse in the same version targets sparse-MLA decoding. It spills KV pages into pinned host memory while retaining a hot buffer for each request on the GPU. The Release also contains breaking changes, including a requirement to enable the scale-out endpoint explicitly and the removal of old environment variables. The project's published start-up and performance figures come from particular hardware and configurations. A model being loadable by the runtime does not mean that it has production validation, a service level or proven quality on the target data.
For enterprise adoption, self-hosting costs are affected by cold-start frequency, the balance between GPU and host memory, version upgrades and operational monitoring. A runtime optimisation may shorten a particular path, but it introduces applicability conditions and resource trade-offs that still need to be measured with the target model, quantisation, concurrency and context configuration.
What to watch next
- Whether completion rate, total Token use, tool calls, retries and end-to-end time can form a reproducible comparison for the same business task across models and service tiers.
- Whether suppliers will include overlapping GPU use, pause duration and human reverse-rollout time in exportable cost and audit records for staged switching.
- Whether independent production-load data emerges for the GPU and host-memory trade-off of Fast Start and HiSparse under different quantisation, context and concurrency conditions.
Sources and verification
Golden Data has edited this briefing from the public materials listed above. The original sources govern facts and figures. The enterprise relevance sections are Golden Data editorial analysis and do not constitute an endorsement of any third-party product.
← Back to AI Daily Briefing