Stop Making GPT-5.6 Sol Do Everything

The problem is the job, not Sol

I've seen people on X complain about Sol eating their usage. My experience has been anything but that.

The difference is not a secret setting. It is the job I give it.

If Sol plans the work, edits every file, runs every test, reads every log, fixes every typo, and then reviews itself, of course it spends. You hired the most expensive person in the room and made them carry boxes between meetings.

I use Sol as the control plane. It figures out what matters, breaks the work into pieces, decides what can be safely delegated, reviews the evidence, and steps back in when a worker hits something genuinely hard. The mechanical work happens somewhere else.

I do not have a clean percentage-saving benchmark yet, so I am not going to invent one. What I can say is that my useful Sol sessions do not feel usage-starved when its context is protected from execution churn.

OpenAI already gave the models different jobs

This is not a workaround for a bad model. It is how OpenAI currently describes the family.

Sol is positioned for complex, open-ended, high-value work that needs analysis and judgment. Terra is the everyday workhorse. Luna is for clear, repeatable, high-volume tasks. OpenAI's subagent guidance makes the split even more concrete: keep the main thread focused on requirements, decisions, and final outputs, then send exploration and noisy intermediate work to workers that return distilled results.

As of July 12, 2026, OpenAI estimates that a Plus user may get roughly 15 to 90 local Sol messages, 20 to 110 Terra messages, or 50 to 280 Luna messages in a five-hour window. Those are broad ranges, not promises. Context, reasoning effort, tools, retrieval, caching, and task complexity all change the result.

The point is not that cheap automatically means efficient. A cheap worker that fails three times is expensive. The point is that different jobs have different intelligence requirements.

Keep Sol on the control plane

The main Sol session should own the things that get more valuable when context accumulates: the goal, the architecture, the tradeoffs, the task graph, and the definition of done.

It should not own every intermediate artifact. Raw search results, test logs, file inventories, and repeated edits make the main thread look busy while burying the decisions that actually matter.

Inside WarpOS, my agentic operating-system project, I treat the main session as a coordinator with protected context. Workers get narrow assignments. They return a summary, the evidence, the files changed, the checks run, and anything that still feels uncertain. Sol decides whether that proof is enough.

This is the useful split: Sol protects intent, workers absorb churn, and review reconnects the output to the original decision.

A worker needs a dispatch brief, not a wish

Delegation fails before the worker starts. The planner says something vague like implement the feature, clean up the code, or investigate the problem. Then everyone acts surprised when the worker makes a product decision, rewrites an unrelated file, or returns a wall of confident prose.

A useful dispatch brief is boring. That is why it works. The worker knows what outcome it owns, where it can operate, how the result will be checked, and when it must stop.

If I cannot write these fields, I do not have a worker task yet. I still have a planning problem, which belongs with Sol.

Workers should return evidence, not context pollution

A worker is useful because it keeps intermediate noise out of the main session. That benefit disappears if it pastes every log line, every file it opened, and every discarded idea back into Sol's context.

I want the result in a shape Sol can judge quickly: what changed, why it satisfies the task, what was checked, what failed, and what remains uncertain. The raw details can stay in the worker thread or the repository unless review needs them.

This also makes cheap work safer. A worker cannot hide behind a long answer when the return contract asks for specific evidence. Either the test passed, the diff matches the boundary, and the open risk is named, or it did not finish the task.

Bring the work back when judgment becomes the task

The worker should not prove its value by refusing to stop. Persistence is useful until the task changes underneath it.

A bounded implementation can expose a bad assumption. A repository scan can find two competing architectures. A test can fail because the product requirement is internally inconsistent. At that point, more execution is not progress. Judgment has become the task.

My rule is one well-specified attempt. If the worker fails because the instructions were incomplete, the evidence conflicts, or the safe boundary no longer holds, it escalates. Sol updates the plan or takes the hard part directly, then dispatches the next bounded step.

Test accepted work, not how busy Sol looked

The launch complaints about usage should be taken seriously, but not lazily. Some people reported burning through a five-hour allowance quickly. Some of those reports involved Ultra, which OpenAI explicitly says uses subagents and more tokens. OpenAI product lead Tibo Sottiaux also said the team was changing Sol usage behavior during the rollout. That is market evidence, not a stable benchmark.

The honest test is to run the same task set twice. In the baseline, let Sol do everything. In the routed version, let Sol plan and review while Terra or Luna handles the bounded work. Keep the acceptance criteria the same.

Then count completed work that you would actually keep. Fewer Sol messages mean nothing if retries and review debt erase the saving. More subagents mean nothing if they create coordination work nobody measured.

Use Sol like a lead, not an intern

Sol should still write code. It should still use tools. It should still take over a task when the risk justifies it. The point is not to keep the strongest model clean by making it useless.

The point is to spend its judgment where judgment compounds.

Let Sol understand the messy request, turn it into a plan, route the work, protect the boundaries, review the proof, and resolve the exceptions. Let workers do the parts that became obvious because Sol did the hard thinking first.

That is how Sol stops eating the workflow and starts running it.