4.0 KiB
Model economics
Read for cost-sensitive routing or when revising defaults. Checked 2026-10-06; recheck official prices before a later price-dependent decision. This is an API reference snapshot, not a Codex subscription quota or billing estimate.
Verified price basis
USD per million tokens, Standard processing, prompts up to 272K input tokens:
| Exact model ID | Input | Cached input | Cache write | Output |
|---|---|---|---|---|
| gpt-6-luna | 0.10 | 0.01 | 0.125 | 0.50 |
| gpt-6.1-sol | 2.00 | 0.10 | 2.50 | 10.00 |
| gpt-6-astra | 10.00 | 1.00 | 12.50 | 50.00 |
Source: OpenAI pricing. At equal token volumes, Luna is 1/20 of GPT-6.1 Sol for input, cache writes and output, and 1/10 for cached input. GPT-6.1 Sol is 1/5 of Astra for input, cache writes and output, and 1/10 for cached input. Luna is 1/100 of Astra in all four categories. These are arithmetic price ratios, not observed savings, speed or success rates.
Long prompts above 272K input tokens charge 2x input/cache rates and 1.5x output for the full request. Processing tier, tools and regional processing can change the bill. Do not multiply Codex subscription usage by API prices or assume a Desktop service tier follows the Standard table.
Compared with GPT-6 Sol, GPT-6.1 Sol keeps input/output rates at 2.00/10.00 and halves cached input from 0.20 to 0.10. This improves the cached-input rate, not necessarily the total cost of a task; token use, retries and cache hits still matter. Older Sol remains a compatibility choice, not an alias.
Design implications
Official positioning: Luna targets focused, high-volume work; GPT-6.1 Sol offers near-Astra performance for complex coding, computer use and professional work at a lower price; GPT-6 guidance places Astra at the highest capability level. This is official positioning, not a benchmark performed by this project. GPT-6.1 Sol documents API efforts low/medium/high/xhigh/max, not none/minimal; GPT-6 Luna and older GPT-6 Sol support none. Actual child models, efforts and role bindings must still come from the host schema.
The engineering policy is three routes: Luna for bounded, settled, cheaply verifiable work; Sol for implementation and investigation requiring judgment; Astra for the hardest independent synthesis. Retire Terra from recommendations and automatic fallbacks: Sol absorbs its former workload and avoids maintaining another routing boundary. This is a routing design choice, not a measured claim that Sol dominates every Terra workload. Price alone does not establish that Luna can perform open-ended development reliably.
Measure accepted work
Compare the same task shape and acceptance standard. Include parent context/reasoning, every child's usage, tools, retries, parent review and reintegration. For API estimates apply the actual rate to each billed category, including billed reasoning/output tokens without double-counting; keep wall time separate. With unknown usage or billing tier, report unknown cost and observable proxies instead of fabricated savings.
A cheaper child helps only if its savings exceed added orchestration and correction. One avoided parent investigation may matter more than many cheap child tokens. Do not turn a token-rate ratio into a retry allowance, a fan-out quota or permission to duplicate reviews. Keep concurrency tied to useful independent work and actual host capacity.
Broaden Luna assignments after comparable accepted results demonstrate stable quality and lower total effort. Move a task shape directly to Sol when ambiguity, repeated correction or parent rework dominates. For a new generation, use the first authorized useful bounded task as evidence; synthetic parser tests and static scenario reviews cannot establish model quality or latency.