30 秒でわかる
Theo Browne reviews the GPT-5.6 family, comparing published evaluations with his experience using coding and computer-use agents. He praises Sol’s persistence and efficiency while warning about excessive output, mistakes and usage costs, and offers a provisional model-selection guide.
- 1Benchmark contextOpenAI’s agent evaluation and independent coding charts show strong results, but their scores and costs measure particular test setups.
- 2Computer useOperating real interfaces expands what agents can do and raises privacy and action risks.
- 3Too much outputSol can write excessive code or pursue questionable workarounds, making boundaries and review important.
- 4Reasoning costsIn the displayed DeepSWE snapshot, higher effort raises cost much faster than the score.
ポイント
- Sol is persistent and capable, but its output and actions still require review.
- Benchmark scores and costs depend on the evaluation and its settings.
- Terra may suit budget-conscious interactive coding; the reviewer had limited experience with it.
- Luna is suited to inexpensive delegated or bulk tasks in Theo’s workflow.
- Higher reasoning effort can sharply increase cost for a modest benchmark improvement.
チャプターごとに整えた全文を読む
First impressions
Theo introduces the model family and a striking coding benchmark. He distinguishes benchmark results from practical experience.
GPT-5.6 has arrived in three versions, and after using it I have a lot to say. The benchmark results are striking, but the reactions from developers have been mixed. I want to separate what the numbers say from what it actually feels like to work with the models.
On DeepSWE, Sol at max scores about 73% at $8.39 per task in the chart I show, while a competing Fable run costs roughly $22. That is a compelling result for this particular evaluation, not a promise that every task will cost the same or produce the same ranking.
Models and benchmarks
He examines the lineup, agent evaluations, costs and tool calling. He also compares front-end examples.
The lineup starts with Sol as the flagship, Terra as the balanced option and Luna as the inexpensive model. There are also changes around skills and orchestration, including an ultra mode intended for more involved agent work. The names matter less than choosing the right model and level of effort for the job.
OpenAI's Agents' Last Exam results put Sol at 53.6 on xhigh, around 13 points ahead of the Fable result shown. The chart is impressive, but it is an OpenAI-presented evaluation, and a benchmark score is a particular measurement rather than a complete account of how an agent behaves.

The cost chart also needs careful reading: the figures are for running the evaluation as a whole, not the cost of one prompt. The displayed totals are roughly $760 for Sol, $2,300 for Fable and $3,985 for Opus. I correct myself while discussing the comparison because it is easy to mix up the bars.
Artificial Analysis's coding agent index shows Sol max at 80 and Fable at 77.2. The gap is interesting, though different benchmarks use different tasks and harnesses. When the scores are close, look at the cost and methodology too rather than treating a tiny difference as a universal verdict.

The industry comparison is similarly close, and its dollar figures again describe the evaluation rather than every individual task. These charts are snapshots; settings, tools and benchmark design can change both the score and the amount spent.
One useful improvement is programmatic tool calling: the model can work with intermediate tool output without putting every detail into the final context. That helps with the noise that accumulates during longer agent runs. Higher reasoning settings can still consume substantially more, so efficiency is not the same as unlimited use.
The front-end results are better than GPT-5.5 in my experience, but I would not assume the default output is automatically beautiful. The examples on screen vary with the instructions and design skills provided. A good result still depends on the direction you give the agent and on your own judgment.
Some of the demos show genuinely ambitious visual work, including three-dimensional elements. They also illustrate why comparing a carefully guided demo with an unguided one can be misleading: the model is only one part of the workflow.
Computer use, safety and pricing
He discusses browsing, research usage, refusals and the API prices shown at the time. The figures have different scopes and should be read in context.
Computer use is a major strength. I have been testing it on Macs, and the ability to navigate actual interfaces opens up tasks that a coding agent alone cannot easily do. It also introduces privacy and destructive-action risks, so access and oversight matter as much as capability.

On the BrowseComp chart I show, Sol ultra reaches 92.18% at $12.17 per task. Other entries do not all show comparable cost information. It is a useful data point about that benchmark, not proof that every browsing task will be accurate or cost-effective.
The release also presents cybersecurity and scientific results. One internal chart says compute used for research rose roughly a hundredfold and agentic token use rose around 22-fold. Those numbers describe usage; they should not be mistaken for a direct measurement of scientific progress.

I have encountered more aggressive security refusals, including cases where I was doing legitimate development. False positives can interrupt useful work, even though safety protections address real risks. It is a practical tradeoff worth watching as the tools improve.
At the time of the video, the displayed API prices per million tokens were $5 input and $30 output for Sol, $2.50 and $15 for Terra, and $1 and $6 for Luna. Caching and product availability also affect the bill. Treat these as a historical snapshot and check current prices before choosing a model.
Developer reactions
Other developers report mixed experiences, including praise for persistence. Clear intent and human oversight remain important.
Developers I follow report a range of experiences. Some teams like its ability to keep working through difficult problems, while others have different preferences or find particular behaviors frustrating. These are useful observations from real work, but they are not controlled tests.
Jay's review and other reactions point to persistence as a recurring theme: the model can keep exploring when an earlier approach fails. That persistence can be valuable, but the same tendency can mean spending too much time or effort on the wrong direction.
I discuss claims about how the models relate to their underlying base model, but that is not something I independently establish here. What I can evaluate is the behavior I see in the products and the results people report, with all the uncertainty that entails.
A useful point from the discussion is that agents work better when people provide clear intent, the relevant source material and a way to inspect the output. Human review remains part of the workflow, especially when the task can affect real systems or data.
Strengths and weaknesses
Theo lists gains in computer use, orchestration and context handling. He also describes overproduction, risky workarounds and confident mistakes.
My own list of strengths starts with determination. Sol is better at front-end work than 5.5, strong at computer use and efficient for what it can accomplish. It also feels fast in ordinary use; a promised high-speed serving option is separate from what I have personally tested.
It also seems better at mobile development and at navigating systems. Orchestrating subagents is a particularly important change: a main agent can split work and delegate narrower investigations, although the resulting work still needs to be checked.
Compaction has improved too. Instead of allowing a long session to fill up with irrelevant context, the system can summarize and carry forward useful information. I also find it better at understanding intent, although no compaction mechanism guarantees that important details will always survive.

The biggest weakness I see is overproduction: Sol can write far too much code and add tests or scaffolding that do not justify their maintenance cost. More output is not automatically better. Ask for the smallest useful change and review the diff for work you did not need.
Determination can also lead an agent to try inappropriate workarounds when it encounters a barrier. Give agents limited permissions, use isolation where appropriate and require approval for consequential actions. Do not interpret the model's confidence as evidence that an action is safe.
It can be confidently wrong and go down a rabbit hole rather than recognizing that its premise is flawed. The solution is not to assume persistence always wins: set boundaries, inspect its reasoning and results, and redirect it when the work stops making sense.
The model is capable, but capability and thoughtfulness are different qualities. It may produce a large, technically plausible response without exercising the restraint a careful colleague would. That is why the shape of the request and the review afterward matter.
Choosing a model and effort level
He compares Sol, Terra and Luna with the help of DeepSWE. His recommendations reflect both the displayed costs and his limited personal testing.
For choosing a coding model, I return to DeepSWE. In the chart, most Terra settings and even Sol medium cost less than the old GPT-5.5 medium run. Sol medium may be a reasonable replacement, but I cannot confidently choose between it and Terra xhigh from my own testing alone.
Terra's steps appear to have useful spacing in that benchmark, while Sol's jump from xhigh to max is smaller. Luna's chart is messier and some scores are low; a strong result at one setting does not mean it is the best model for every interactive development task.
I see Luna primarily as a cheap, fast worker for another agent to call, or for bulk processing and simple text generation. For example, I am considering it for branch names and titles in T3 Code. You can experiment directly, but I would not make it my default interactive coding model.
Sol is the option I reach for when a task is difficult or likely to take a long time. Terra is appealing for coding on a budget, but my experience with it was limited to roughly twenty prompts over two days, so I am less certain about its tradeoffs.
Terra seems useful for reviewing work and for implementation after a stronger model has planned the approach. It stops sooner and, in my limited experience, is less aggressive about writing too much code. That can be helpful in an interactive loop where a person checks each set of changes.
Be careful with reasoning effort and fast mode, particularly ultra: a persistent agent can use up an allocation quickly while stuck on a hard problem. On the DeepSWE snapshot, high, xhigh and max score about 69%, 71% and 73%, while costs rise from roughly $3.47 to $4.70 and $8.39 per task.

More effort can also make a task slower because the agent generates more tokens and takes more steps. My current default is Sol high: medium has missed things I wanted, while xhigh often took longer without a meaningful improvement in my own work. Your task and budget may lead to a different choice.
My practical split is Sol high for most of my demanding work, Terra medium as a budget workhorse, and Luna for inexpensive delegated or bulk tasks. I find Luna especially interesting for simple outputs and tool use, though my comparisons with competing small models are personal experience rather than universal results.
Overall, GPT-5.6 is a phenomenal model family and has become my default for many tasks. Whether it is my favorite, or whether I prefer it to Fable, is a separate question I leave for another video. The important point is to choose with an understanding of the strengths, costs and failure modes rather than from a leaderboard alone.
同じチャンネルの記事
38:47EN
36:07EN
30:37EN
0:43EN
29:22EN
31:13EN