GPT-5.6 has just been released and, just as we did with Fable 5 and Anthropic's models, we are going to evaluate its three variants: GPT-5.6 Luna, Terra and Sol.
To do that, we will put each model through two realistic tests within what would be the daily work of a programmer.
Table of contents
This is not about asking it to implement an isolated algorithm or solve a LeetCode exercise. The models have to navigate a real repository, understand the architecture, follow the existing patterns and modify different layers of the system without breaking anything.
In other words, real programming.
1 - Why Sol, Terra and Luna? What is the difference between them?
We have been using artificial intelligence models for several years now and we are used to companies offering different variants for different types of work. With GPT-5.6, OpenAI has turned that separation into three levels which, according to the company, will continue to evolve independently:
- Sol is the flagship model. It is designed for the most complicated problems, long tasks, deep reasoning and work where quality is more important than time or cost.
- Terra is the balanced model for day-to-day work. In theory, it is the one you should use for most professional tasks.
- Luna is the fastest and cheapest model. It is designed for simple, repetitive or high-volume actions.
In programming, we can translate that in a very simple way.
- You would give Luna tasks like changing a name, moving a file, modifying a validation or carrying out a fairly obvious transformation.
- Terra would be the model you would use to develop normal features in your daily work: adding an endpoint, modifying a screen, implementing a business rule or fixing a bug.
- Finally, Sol would be reserved for investigating complex problems, understanding large architectures, designing a solution or performing tasks that need quite a lot of autonomy and reasoning.
The difference is also clear in the API pricing. For every million tokens, Sol costs 5 dollars for input and 30 for output; Terra, 2.50 and 15 dollars; and Luna, 1 and 6 dollars respectively. Obviously, these prices do not translate directly to ChatGPT subscription limits, but they show how OpenAI positions each model.
Personally, I mainly work with Claude and my flow is usually the following: I use Fable to do the planning and research, define exactly what needs to be changed and discover potential problems. Then I use Sonnet 5 or Opus to implement the code.
Because in the real world, things do not work with a single magic prompt.
You have to investigate, understand the code, discover dependencies, make decisions and iterate several times. That is why it is important for the initial analysis to be good: the better the plan, the less likely the model is to end up implementing something that apparently works, but does not fit the system.
2 - GPT's new desktop application
One of the major criticisms during the first days of GPT-5.6 does not really have anything to do with the models.
It has to do with the application.
OpenAI has decided to bring ChatGPT Work and Codex much closer together, putting work with documents, integrations, browsing, development and programming agents inside the same experience.
My take is quite simple: Anthropic had already shown that an artificial intelligence application cannot be designed only for programmers.
Claude stopped being simply a chat window and became an application from which to work with code, documents, tools and company information. OpenAI is following exactly that direction.
And it makes all the sense in the world.
You may be a programmer, but inside a company there are also people working in finance, sales, administration, human resources, support, marketing or product.
These people do not need to open a terminal or use a programming agent. They need an application that can connect to Microsoft 365, Google Drive, Slack, GitHub, Linear, Figma and other internal tools to search for information, prepare documents, analyze data or automate tasks.
The goal of these companies is not to get all programmers to use their products. The goal is to get the whole company to use them. We programmers may be the ones who introduce these tools into many companies, but we are usually a minority inside the organization. The really big market is in turning artificial intelligence into a work tool for any department.
It is also worth clarifying something about subscriptions.
We do not know whether each personal subscription is profitable individually. What does seem obvious is that personal plans work as a distribution tool: you use the product, discover that it allows you to get more work done and end up recommending it inside your company.
From there, Business and Enterprise plans come in, which include centralized administration, security controls, company knowledge, integrations and per-user billing. In addition, companies can buy credits to expand access to the more expensive models.
That is why Work is so important.
Codex can win over programmers, but Work is what makes it possible to win over the rest of the company.
3 - Analysis of the GPT-5.6 models
This post is about evaluating the models, and that is what we are going to do, with two tests, which you can find in this GitHub link: test 2026.06, which consists of two tests, both using the code from Distribt, which is a simulation of a distributed system written in C#.
The current leader, with 182 points out of 200, is Fable 5 and honestly I expect Sol to score between 180 and 200 points as well. If it scored less, it would be quite surprising.
GPT-5.5 scored 110 out of 200, because it had some penalty, so in Terra's case I expect something between 130 and 150, which is what GLM 5.2 scored.
But let's get to the tests.
A - Code review
The first task consists of performing a code review.
We present the model with a pull request that implements a system to apply discounts to product prices.
The pull request contains multiple intentionally introduced problems: calculation errors, concurrency issues, idempotency errors, ignored exceptions, tests that do not validate correctly and different traps.
The goal is to check how many problems the model is able to find and, above all, whether it really understands the impact they would have in production.
B - Implementation of a feature
The second test consists of implementing a complete feature from beginning to end, following the existing examples and patterns in the repository.
In this case, the model must add the possibility of canceling orders.
The implementation must include the endpoint, domain logic, state control, the Result pattern, idempotency, the corresponding events and the tests.
So that this does not become a huge post, I am going to include summaries in each section, but everything will be detailed both on GitHub and in the YouTube video.
3.1 - Analysis of GPT 5.6 Luna as a development model
Luna is the smallest model. OpenAI says it is similar to GPT 5.5, which would be a pleasant surprise since the price is much lower.
A - What is GPT 5.6 Luna like for code reviews
Luna's review was pretty weak.
It correctly identified the most obvious and serious problem in the entire pull request: integer division causes the discount multiplier to be zero and, in practice, many products end up with a sale price of zero.
It also found several problems related to the static dictionary used as a cache, publishing the event before confirming that the operation has completed, and the lack of validation of the product identifier.
The problem is everything it missed.
It did not mention the lack of validations for the price and discount percentage, that the endpoint may end up always returning a successful result, that the cancellation token is not propagated, that there is a try/catch that swallows exceptions, that money is converted from decimal to double before rounding, or that one of the tests validates absolutely nothing.
It also did not correctly identify the full problem with the key used for the cache.
Result: 38/100.
There is not much more to say: as a model for reviewing code, it fell very short. Link to the results: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Luna/task1_code_review_evaluation.md
B - What is GPT 5.6 Luna like for programming complete features
Interestingly, Luna worked much better implementing code than reviewing it. The solution compiles, the tests pass and the model added tests for the code it wrote. It also created the endpoint to cancel orders, used the Result pattern without throwing exceptions, prevents an already canceled order from being canceled again, follows DDD principles, correctly propagates cancellation tokens and the logic checks are also correct.
The problem appears in the distributed part of the feature. Where it implemented nothing.
Result: 70/100.
It is exactly the same score that Sonnet got in this test.
Total for GPT-5.6 Luna: 108/200.
It ended up two points above GPT-5.5, so well, more or less what they said, similar performance.
3.2 - Analysis of GPT 5.6 Terra as a development model
Terra is positioned as the "most important" model a priori, since they sell it to you as the model to use day to day.
A - What is GPT 5.6 Terra like for code reviews
Terra performed a much more complete review than Luna.
It found the integer division error, the lack of validations, publishing the event before confirming the operation, the precision problem when converting money to double, the static dictionary without synchronization, the incorrect cache key and the lack of validation of the product identifier.
But it did not indicate that the endpoint may end up always returning a successful response, it did not mention the cancellation token, it did not find the try/catch that swallows exceptions and it also did not realize that one of the tests validates nothing.
Result: 62/100.
It is a mediocre review and far from what I would expect from a model meant to become the main option for daily work.
In fact, the result is slightly lower than the 64 that Sonnet 5 got.
Link: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Terra/task1_code_review_evaluation.md
B - What is GPT 5.6 Terra like for programming complete features
Here Terra made a mistake that is hard to justify.
The implementation compiles, the tests pass and the model wrote new tests. It also uses the Result pattern, prevents canceling the same order twice, follows DDD principles, propagates cancellation tokens and correctly handles shipped or delivered states.
But it did not create the endpoint correctly. While it is true that it works, it does not follow the structure or patterns of the rest of the endpoints, so it does not get that score.
In addition, like Luna, it does not generate the domain event, does not implement the event handler, does not return the stock and does not add any of the additional infrastructure pieces.
Result: 60/100.
The endpoint failure makes it lose ten points compared to Luna and leaves a pretty so-so feeling for a model that should be the day-to-day programming model.
Total for GPT-5.6 Terra: 122/200.
Terra clearly improves on Luna, but it is below Sonnet 5 and very far from GLM 5.2.
I expected a result between 130 and 150 points, so 122 is disappointing.
3.3 - Analysis of GPT 5.6 Sol as a development model
Finally we get to Sol.
Sol is OpenAI's flagship model and the one that should compete directly with Fable 5. It is also the most expensive model and, well, I expect between 180 and 200, just as I did with Fable 5.
An important clarification: this evaluation was performed using Codex with the reasoning level set to High. I normally use whatever comes by default, which in Sol's case is set to medium, but I preferred to set it to high since Fable uses high by default and it seems the fairest option.
A - What is GPT 5.6 Sol like for code reviews
Sol's review was, by far, the best of the three models. It found all the problems, but failed on two things, one minor, where it did not indicate that the static dictionary can grow indefinitely and that cost it half the points.
It found everything else.
But in this review there are TWO planted traps, and one is in a test, which validates a problem in the implementation.
It is exactly the same penalty that destroyed Opus 4.8's score.
And it may seem too harsh, but the rules are the same for all models. If we change the score depending on the name that appears at the top, the evaluation stops being useful.
Final result: 74/100.
The numerical result does not fully reflect the quality of the review, because Sol found almost all the real problems. However, it did not find the relationship between the bug and the test that protected the wrong behavior, which was precisely the main trap.
B - What is GPT 5.6 Sol like for programming complete features
Here comes the big disappointment.
Sol generated a correct implementation in the most basic aspects. The code compiles, the tests pass and it added new tests.
It also creates the endpoint, uses the Result pattern, checks that a canceled order cannot be canceled again, follows DDD, propagates cancellation tokens and returns an error when the order has already been shipped or delivered.
But then exactly the same thing happens as with Luna. It does not generate the domain event, does not implement idempotency based on that event, does not create the handler that should publish the integration event and does not return the stock.
It also does not add any of the bonus points such as RabbitMQ integration, a fake API to return the stock, or mention the outbox pattern.
Result: 70/100.
Yes, OpenAI's flagship model got exactly the same score as Luna, the cheapest model, in the feature implementation.
That does not mean both models are equally good at programming. This specific test has a limited rubric and does not measure aspects such as the aesthetic quality of the code, autonomy over several hours or the ability to coordinate different agents, in theory.
But in the task we gave it and with the criteria defined before running the models, Sol did not manage to stand out.
Link: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Sol/task2_feature_implementation.md
Total for GPT-5.6 Sol: 144/200.
It is a more than disappointing result. I expected Sol to be between 180 and 200 points. Although it is OpenAI's best model by quite a margin, the result is well below expectations and 38 points behind Fable 5.
4 - Conclusion: which GPT-5.6 model is best for programming?
The final results are as follows:
- GPT-5.6 Luna: 108/200
- GPT-5.6 Terra: 122/200
- GPT-5.6 Sol: 144/200
The best model in the family is clearly Sol, especially when it has to investigate code and find problems.
Its review was much better than the final 74 suggests. Before the penalty, it had obtained 94 points, which shows that it is a very competent model for analyzing pull requests.
But in the implementation of a complete feature, it did not manage to differentiate itself from Luna.
And that is pretty... disappointing, since I expected a model that would give us a result similar to Fable 5, and it has not been like that by a long shot.
