Updated 2 August 2026. GPT-5.6 Sol is not billed or consumed as a fixed number of identical Codex messages. The current OpenAI pricing documentation says that model, context, reasoning, tool use, retrieval, caching and speed all affect usage. OpenAI’s 30 July update also says that subscription prices and quota budgets did not change, while the lower API prices for GPT-5.6 Terra and Luna are reflected in how much paid ChatGPT Work and Codex usage those models consume.
This matters because two apparently similar Sol sessions can leave very different amounts on the meter. A short, well-scoped edit may be cheap; a long repository task with high reasoning, repeated tool calls, web retrieval, parallel workers and a large conversation can use much more. The practical answer is not to stop using Sol. It is to reserve Sol for the reasoning bottleneck, route routine work to Terra or Luna, and keep context and delegation intentional.
This article refreshes the earlier evidence-based guide with OpenAI’s current rate card, the July 2026 usage update, and a documented best-effort review of public posts from Tibo (@thsottiaux), who identifies publicly as working on Codex and ChatGPT at OpenAI. It keeps the distinction between verified product facts, a public employee’s update, and user anecdotes.
The short answer: why GPT-5.6 Sol can drain Codex limits quickly
Sol is the GPT-5.6 family’s quality-first model for difficult reasoning, ambiguous work, advanced coding and high-stakes decisions. Those workloads naturally create more processing than a short classification or a clearly specified edit. The main usage multipliers are:
- Active context: conversation history, files, instructions and tool results all give the model more material to process.
- Reasoning effort: deeper reasoning can improve difficult work but uses more tokens and time.
- Tool and retrieval work: web searches, shell commands, file inspection and repeated polling add context and turns.
- Parallelism: subagents can shorten elapsed time, but each worker still performs work and carries its own context.
- Fast mode: OpenAI’s current pricing page says speed configurations consume credits faster for supported models.
- Large or unstable prompts: pasted logs, oversized project instructions and repeated full-context handoffs reduce efficiency.
The strongest current rule of thumb is therefore: count completed, verified outcomes—not messages—as the unit of efficiency. A small, bounded Sol turn can be a better use of an allowance than a long, vague Sol session that produces several revisions.
What changed in July 2026—and what did not
On 30 July, OpenAI announced lower API prices for GPT-5.6 Terra and Luna. The announcement describes Luna as 80% cheaper and Terra as 20% cheaper, and says that the lower prices are also reflected in paid ChatGPT Work and Codex usage. The same announcement says that subscription prices and quota budgets remained unchanged. That is an accounting and routing change, not a promise that every plan receives a new fixed number of messages.
The current OpenAI price-performance announcement gives the API rates from 30 July:
| Model | API input per 1M tokens | API output per 1M tokens | Practical role |
|---|---|---|---|
| GPT-5.6 Sol | $5 | $30 | Deep reasoning, ambiguous or high-stakes work |
| GPT-5.6 Terra | $2 | $12 | Everyday production work and balanced judgment |
| GPT-5.6 Luna | $0.20 | $1.20 | Fast, cost-sensitive and high-volume work |
Those are API token prices. They should not be copied into a subscription meter as if one dollar equaled a fixed number of ChatGPT messages. For the separate pricing and credit implications of the API change, see the DMT GPT-5.6 Luna and Terra price-cut explainer.
The current official usage reference
OpenAI’s live Codex and ChatGPT Work pricing page says that ChatGPT Work and Codex share usage. It publishes approximate five-hour local-message ranges for each model and plan rather than one universal message price. For the Plus reference tier, the page currently lists:
| Model | Plus local messages per five-hour window* | API input/output price per 1M tokens | OpenAI’s positioning |
|---|---|---|---|
| GPT-5.6 Sol | 10–100 | $5 / $30 | Hardest reasoning and advanced coding |
| GPT-5.6 Terra | 25–200 | $2 / $12 | Everyday workhorse with balanced cost and capability |
| GPT-5.6 Luna | 250–2,000 | $0.20 / $1.20 | Lighter, faster and higher-volume workloads |
*These are the published Plus ranges shown on the live pricing page, not a guarantee for an individual account. The page says the five-hour local-message and cloud-chat windows share usage and that additional weekly limits may apply. Actual consumption varies with task size, complexity, model, reasoning, tools and context.
The same page describes the Pro tiers as offering 5x or 20x higher rate limits than Plus, and it says that Plus and Pro users can purchase additional credits after reaching a limit. It also points users to the usage dashboard and the Codex /status command for current remaining capacity. Treat the account dashboard as the operational source of truth for a specific user; the ranges above are planning guidance.
The credit rate card explains the model-routing economics
OpenAI now describes usage in credits per million input, cached-input and output tokens. Its current rate card lists:
| Model | Input credits / 1M | Cached input credits / 1M | Output credits / 1M |
|---|---|---|---|
| GPT-5.6 Sol | 125 | 12.5 | 750 |
| GPT-5.6 Terra | 50 | 5 | 300 |
| GPT-5.6 Luna | 5 | 0.5 | 30 |
The page adds that GPT-5.6 usage averages 5–40 credits per message, that Fast mode consumes credits at a higher rate, and that the average is not a guarantee. This is why replacing routine Sol work with Luna or Terra can extend a local allowance without turning the entire workflow into a lower-quality Luna-only process.
For API users, the GPT-5.6 Luna model page currently lists $0.20 input and $1.20 output per million tokens, a 1,050,000-token context window and 128,000-token maximum output. It also documents a special rule for requests above 272,000 input tokens: input is priced at 2x and output at 1.5x for the full request. That rule is explicitly an API pricing rule. Public ChatGPT-plan documentation does not establish that the same discrete multiplier is applied identically to every subscription meter.
What Tibo (@thsottiaux) said about the Sol usage update
Public X collection is best-effort: logged-out search and reply discovery can be incomplete, so the exact post URLs are recorded and the social evidence is treated as a signal rather than a substitute for product documentation.
In a 29 July 2026 X post, Tibo said OpenAI had reset usage limits for ChatGPT Work and Codex users and had been investigating reports that Sol used limits faster than expected. He said there had been no reduction to subscription-plan usage, that improvements were expected to make typical Sol usage last about 18% longer, and that a five-hour limit would be restored after a temporary pause.
His explanation was consistent with the official usage model: Sol can work longer, make additional tool calls and coordinate complex workflows across tools and subagents; code-mode and programmatic tool calling can create more parallel calls and cached input; and the effect is uneven because power users and long-running workflows create a different load from median use. Those are useful implementation clues, but the post is not a public plan-by-plan benchmark and should not be converted into a promise that every account will gain exactly 18%.
On 1 August, Tibo also replied “Too cheap to meter” to a user describing a strong Luna experience, and he posted that limits had been reset for a weekend of high-volume Luna use in this public update. These posts help explain the current conversation around Luna’s economics; they are not billing terms, a universal quota conversion, or evidence that a particular plan is unlimited.
Why Sol still drains quickly after the improvement
1. A message is a workload container, not a fixed unit
A Sol turn may include the user’s prompt, the active conversation, project instructions, repository files, tool results, retrieved pages, reasoning tokens and generated output. OpenAI’s pricing page explicitly warns that prompt length alone is not a reliable estimate. Two messages with the same visible word count can have very different hidden work.
2. Long sessions keep paying context costs
Long-running threads accumulate decisions, failed approaches, tool output and stale assumptions. The model may need to carry or re-evaluate more material on later turns. Start a clean phase when the work changes shape, write a compact handoff, and keep the new phase focused on the artifacts it actually needs.
3. High reasoning and Ultra are deliberate multipliers
Use high or maximum reasoning when ambiguity or stakes justify it. Do not select the deepest setting because it sounds safer. For a bounded content edit, file inventory, extraction job or routine test repair, Terra or Luna may be a better first pass. Move to Sol when the task reaches the hard reasoning edge.
4. Subagents multiply work even when they reduce waiting
Parallel workers are valuable when tasks are independent and their outputs are easy to validate. They are wasteful when several workers investigate the same vague question, inherit the entire repository, or return overlapping prose. Give each worker one narrow role, a bounded source set and a compact output contract.
5. Tools and retrieval add both value and context
Web research, shell commands, file reads and browser checks are often necessary. The expensive pattern is repeated broad collection: rereading the same large file, pasting full logs, polling a running job too often or asking multiple agents to search the same corpus. Extract the relevant evidence once and pass summaries or paths instead of duplicating raw output.
6. Fast mode trades credits for latency
Fast mode is appropriate when waiting is the bottleneck. It is not a free performance setting. The current pricing page says speed configurations consume credits faster for supported models, so leave it off for exploratory work where latency does not affect the outcome.
A practical Sol, Terra and Luna routing playbook
The following routing pattern works for marketers, analysts and developers because it maps the model to the work rather than to the prestige of the model name:
| Work type | Start with | Escalate to Sol when |
|---|---|---|
| Classify, extract, label or transform many small items | Luna | Inputs contain ambiguity that changes the business decision |
| Routine research synthesis, reporting, code maintenance or content structure | Terra | Sources conflict, requirements are unclear or the cost of a wrong decision is high |
| Architecture, security, complex debugging or original strategy | Sol at a bounded effort | Use deeper effort only for the unresolved reasoning bottleneck |
| Large corpus research | Luna/Terra workers with a strict evidence schema | Use Sol to adjudicate conflicts and write the final decision |
| Automation with predictable spend | API pricing with explicit budgets | Use Sol only for cases routed by an evaluation or confidence rule |
This is the same separation used in a durable agentic marketing workflow: one model does not have to perform discovery, extraction, judgment, writing, QA and orchestration for every item.
The 12-step checklist for making Sol limits last longer
- Define the finished outcome first. State the deliverable, audience, acceptance criteria and what is explicitly out of scope.
- Route by difficulty. Let Luna handle repetitive volume, Terra handle routine production and Sol handle ambiguity or high-stakes judgment.
- Start at the lowest useful reasoning setting. Increase effort only when a bounded test shows that the additional reasoning improves the result.
- Give the model only the relevant context. Prefer file paths, selected excerpts and a date-bounded source set to an entire repository or browser history.
- Split phases. Use a short research handoff, an implementation phase and a QA phase instead of one thread that grows without a boundary.
- Cap subagents. Set a worker count and give each worker a non-overlapping job; do not fan out because the interface makes it easy.
- Use structured worker outputs. Ask for findings, evidence, confidence, risks and file paths—not several paragraphs of duplicate narrative.
- Control retrieval and tool loops. Search once, keep the useful URLs, and avoid repeated full-page or full-log reads.
- Keep stable instructions stable. Reusing a stable prefix can support cache reuse; constantly changing the beginning of a prompt can reduce that benefit.
- Leave Fast mode off unless latency is worth the extra credits. Measure the end-to-end outcome, not just the first response time.
- Measure completed work. Record the model, effort, tools, worker count, context size, start and end allowance, rework and whether the result passed QA.
- Use API billing where a hard budget matters. For CI or shared automation, token-based API pricing can be easier to attribute and cap than a shared interactive allowance.
How to diagnose a sudden Codex usage spike
- Capture the workload: model, effort, Fast mode, task duration, repository size, active thread length and number of tools.
- Check delegation: identify whether Ultra or another workflow created child agents, and count overlapping workers.
- Estimate context pressure: look for pasted logs, large instructions, repeated file reads, broad retrieval and long tool results.
- Repeat a bounded comparison: run the same small task with Terra or Luna, then with Sol at a lower effort, keeping the source set fixed.
- Check the live dashboard or
/status: do not infer a current limit from an old screenshot or a different plan. - Update the client and preserve evidence: record timestamps, versions, settings, screenshots and the smallest reproducible workload before reporting a suspected bug.
A good incident record distinguishes a product-wide change, a plan-specific limit, a client issue, a context-heavy workflow and an anecdotal report. The public X conversation can point to a hypothesis; only current product documentation and a controlled reproduction can confirm the mechanism for a specific account.
Common mistakes that waste GPT-5.6 Sol allowance
- Using Sol Ultra for every task because it sounds like the safest choice.
- Giving every worker the complete repository, conversation and source corpus.
- Running several agents on one vague instruction.
- Requesting exhaustive prose from every exploratory worker.
- Pasting full logs instead of extracting the relevant failure and a few lines of context.
- Keeping one thread alive across unrelated project phases.
- Turning a single X, Reddit or GitHub report into a universal billing claim.
- Confusing lower Luna/Terra API prices with a promise of unlimited ChatGPT or Codex usage.
For a broader model-selection view, read the DMT GPT-5.6 Sol, Terra and Luna decision guide. For practical integrations, the Codex workflow guide for marketers covers plugins, Sites and repeatable production flows. Teams building AI-led search and content systems can also use the agent-harness and context-compaction analysis to design cleaner handoffs.
Frequently asked questions
Does GPT-5.6 Sol have a fixed number of Codex messages?
No. OpenAI publishes approximate ranges by plan and model, but the live documentation says actual usage depends on the model, task size and complexity, context, reasoning, tools, retrieval and caching. A five-hour window and additional weekly limits can also apply.
Did OpenAI reduce subscription usage in July 2026?
The 29 July public update from Tibo said there had been no reduction to subscription-plan usage. OpenAI’s 30 July announcement says subscription prices and quota budgets remained unchanged, while lower Terra and Luna prices are reflected in paid ChatGPT Work and Codex usage. Those statements describe the current update; they do not guarantee that every user will see the same meter behavior.
Did the GPT-5.6 price cut make ChatGPT Plus cheaper?
No. The current Codex pricing page still lists Plus at $20 per month. The July change lowered API rates for Terra and Luna and changed their usage economics in paid ChatGPT Work and Codex. It is not a universal subscription-price reduction.
Does crossing 272K input tokens definitely double ChatGPT Codex usage?
No public document supports that universal conclusion. OpenAI’s API model documentation explicitly applies 2x input and 1.5x output pricing to a request above 272,000 input tokens. The public ChatGPT-plan documentation explains that context affects usage but does not say that every subscription meter applies the identical discrete multiplier.
Should I stop using subagents?
No. Use them when the work can be separated cleanly and parallelism materially improves the result. Bound each worker’s context, model, output format and scope, then have one main workflow validate and combine the outputs.
Can I use Luna for everything?
Luna is a strong choice for fast, cost-sensitive and high-volume work. It is not a universal replacement for Sol. If the task depends on ambiguous requirements, deep debugging, security judgment or a difficult strategic decision, use Terra or Sol where the quality gain justifies the additional usage.
What does “Too cheap to meter” mean?
It is a short public reply from Tibo to a user describing a strong Luna experience. Read it as conversational context, not a billing policy. The official pricing page and your usage dashboard remain the right sources for actual rates, credits and remaining allowance.
Are Reddit and X reports enough to diagnose a limit problem?
They can reveal patterns worth testing, but they are uncontrolled observations. Plans, client versions, effort settings, context, tools and task difficulty differ. Use community reports to form a hypothesis, then validate it with current OpenAI documentation and a small reproducible comparison.
Bottom line
The best way to use GPT-5.6 Sol without hitting limits is disciplined routing. Keep Sol for the hard reasoning bottleneck, use Terra for everyday production work, use Luna for high-volume or lighter tasks, keep context bounded, control delegation and measure the outcome that actually shipped.
The July 2026 update makes that strategy more attractive: OpenAI lowered Luna and Terra API prices and says their lower economics are reflected in paid ChatGPT Work and Codex usage, while subscription prices and quota budgets stayed unchanged. Tibo’s public usage update adds useful implementation context, including the expectation of longer typical Sol usage after internal improvements. Neither source turns a complex agentic workload into a fixed universal message count. Your own dashboard, workload log and controlled comparisons are still the reliable way to manage the meter.
Editorial methodology: official OpenAI product, pricing and model documentation was checked on 2 August 2026. Public X collection was best-effort and exact post URLs are linked; X posts are labelled as social evidence where they are not formal product documentation. API prices and published plan ranges are current snapshots and should be rechecked before making a budget or purchasing decision.
Sources checked
- OpenAI: Advancing the price-performance frontier with GPT-5.6
- OpenAI: Codex and ChatGPT Work pricing and usage
- OpenAI API: GPT-5.6 Luna model documentation
- OpenAI Help: GPT-5.6 in ChatGPT
- Tibo (@thsottiaux), 29 July 2026 usage-limit update on X
- Tibo (@thsottiaux), 1 August 2026 reset and Luna usage post on X
- Tibo (@thsottiaux), 1 August 2026 reply on X
