Claude Opus 5.5 versus GPT-6.1 Sol in real projects: my personal impression

I wanted to build an application to talk to my agents from my phone. I put both models to work on the project. Claude Opus 5.5 started two hours after GPT-6.1 Sol and finished an hour earlier. I also thought Claude's prototype was better.

I do not present that result as a scientific test. A particular project depends on the brief, the context each system receives, its tools and the decisions made during the work. But the episode gave a name to a difference I had already seen in other projects.

GPT-6.1 Sol can do excellent work when I give it a specific task. Yet some projects I have started with Sol in charge of the overall coordination have ended up stuck. After reviewing what happened and handing the orchestration to Claude Opus 5.5, I have managed to get them moving again. When I start with Opus in that role, my impression is that I reach the result I was looking for sooner and with better results.

Being a good worker does not guarantee being a good coordinator

Executing a task and directing a project require different things. A worker can receive a defined objective, develop a solution and hand it over for review. The coordinator has to keep the whole picture in view: decide what comes first, distribute work, spot blockages, check that the pieces fit together and know when something is truly finished.

I have found that distinction more useful than asking, “Which is the best model?” For certain assignments, GPT-6.1 Sol is a very effective worker. For coordinating several fronts, auditing a stalled project and deciding on the next step, my recent experience favours Claude Opus 5.5.

“Boss” is a shorthand here for a function within the system. The final decision and responsibility remain mine.

Parallel comparisons teach more than choosing out of habit

My advice is not to tie yourself to any one model. If a project matters, it is worth giving two AI systems the same brief and comparing what they deliver. Looking only at which replied first or wrote more code is not enough. I want to know which produced a usable result sooner, what corrections were needed, how much time I had to spend reviewing and what problems arose when integrating the work.

For such a comparison to teach us anything, the models should start, as far as possible, with the same objective, the same materials and the same acceptance criteria. We also need to keep the briefs and versions. Otherwise it is easy to credit a model with an advantage that may have come from a better instruction or more context.

The mobile application gave me a clear signal for my own decisions, but it does not settle the debate. I would run more tests on other projects. And if Sol coordinates one of them better tomorrow, I will change my mind.

The project must be able to change engines

Working this way raises a practical problem. If everything a project knows is scattered across conversations on one platform, changing models may force me to reconstruct decisions, instructions and work already done. I then keep using the same system because leaving is costly, even when another might serve me better.

That is why, as I build Alonides on top of Hermes, my aim is to keep the context I need to continue outside any one model: objectives, files, instructions, decisions, pending tasks, results and reviews. I want to be able to speak to the agents on a project or address Alonides as coordinator of the whole; and I want to be able to change the model performing each function without losing the history of the work.

Today, for many projects, my preferred combination is Claude Opus 5.5 coordinating and GPT-6.1 Sol carrying out defined tasks. I do not need that combination to be permanent. I need an organisation that lets me check when it works, recognise when it stops working and change it without starting over.