The upgrade isn’t a smarter model#

Most people trying to get more out of coding agents are still shopping for the one model that gets everything right. Theo’s new video is a useful correction. His biggest gains came from three markdown files, not a new model or framework, and he says nearly half his threads on T3 Code now use one of them.

The files are called Sol loop, full send and full stop. None of them is clever on its own. What matters is the shape: one model writes, a different model attacks, a hard budget ends the argument, and the human only hears about it when there’s a decision to make. I build agents for small businesses at Othermind, and that shape is worth more than whichever frontier model is on top this month.

Sol loop: a reviewer that doesn’t share your blind spots#

Sol loop is simple. Claude Opus 5.5 writes the code. OpenAI’s GPT-6.1 Sol reviews it. Opus fixes what’s right, pushes back on what’s wrong, and they go again. Theo calls Opus the better collaborator and Sol the more thorough reviewer, the one that “grabs onto the problem and doesn’t let go.”

The reason to use two vendors is not loyalty to either. Different labs train differently, so their models miss different things. Theo compares it to getting three people with different backgrounds to review one PR: the odds that someone spots something new go up. His own read is that OpenAI models are the most thorough, Claude finds strange and dangerous edge cases others miss, and Gemini hallucinates more than it finds. That last bit is one developer’s experience, not a benchmark, but it matches what I see. A model reviewing its own work tends to agree with itself.

The guardrails in the skill do more work than the loop:

  • Three rounds, total. Round one is a full review. Later rounds only look at changed code and open findings. It can stretch to five only for security, permissions or data-loss risk. Without a budget, two opinionated agents will review each other forever.
  • Smallest change that satisfies the reviewer. His rewritten version tells the agent to make “the most minimal possible changes,” watch for scope creep and not be scared to push back. Two models trading suggestions is how a ten-line fix becomes a 400-line refactor.
  • Stop on nits. If a round only returns style comments or doc tweaks, stop.
  • One reviewer at a time, and the reviewer can’t spawn its own sub-reviewers, or the thing nests out of control.
  • Show the verdict. Every PR gets a footer saying it was reviewed with Sol loop, how many rounds, which model, and what Sol concluded. Theo added that last line because Opus, in his words, “almost wants to hide” when Sol wasn’t happy.

That last rule is the one I’d copy first. The writer agent has every incentive to make its work look finished. Forcing it to print the reviewer’s verdict where a human will see it is cheap honesty.

The payoff he describes is a trade. The PR takes longer to open, but it reaches merge faster, comes back from review bots with fewer issues, and he isn’t throwing “a bunch of slop” at his team.

How the second model gets in#

You need a way for one harness to call the other vendor’s model. Theo’s older route was CLIProxyAPI, which puts your subscription logins behind one local API, so Claude Code can talk to OpenAI models. That one is officially OK on the OpenAI side: in July, Tibo, who works on Codex at OpenAI, posted the setup himself and promised a reset to anyone who got blocked for it. Theo’s warning about the other direction matters: Anthropic is much stricter about where Claude subscription tokens get used, so keep those inside Claude Code.

His current route is T3 Code’s Orchestrator V2, which lets a thread hand work to agents on other providers, each running in its own native harness. It first shipped in a nightly build on October 3, and it has been on the stable channel since v0.1.0 on October 15. In the video he says stable is “coming very soon,” so that part is already out of date. You can use it today.

You don’t need T3 Code to copy the idea. Any setup where agent A can send a diff to model B and read back findings will do. A script that pipes git diff to a second API works for a first pass.

Full send and full stop: the real productivity gain#

Sol loop makes the code better. The other two skills save the human, and I think that’s where most of the time goes.

Theo runs his agent sidebar like an inbox. A thread is either working or gone. Once he and the agent agree on what to build, he doesn’t want to be pulled back in to re-read context just to click merge.

Full send hands the agent the whole job, from its current state to a merged PR. The skill spells out the flow: finish the change, prove it, file the PR, babysit it through CI and review bots, merge, report. Two parts do the real work.

The first is proof. Proof has to be something the agent saw itself in that session: command output, a reproduction that failed before the fix and passes after, a screenshot of the running app. Green mocked tests don’t count for UI changes.

The second is an explicit merge gate. Proof covers every change, required checks are green, every review bot has finished and each finding is fixed or answered in writing, no human reviewer is still asking for changes, and GitHub says the branch can merge. He also grants merge permission in writing, because he found OpenAI models get nervous about merging without it.

His numbers: in a recent window he said full send 32 times, and 27 of those PRs merged without him looking again. He says none of them caused problems. What makes that sane is the safety net behind it. T3 Code ships nightlies several times a day, so a bad change surfaces before it reaches a stable release.

Full stop is the same skill with one change: never merge. The agent does everything else, including fixing CI, answering review bots and teammates, and cross-checking with other models, then pings him only when the PR is ready or something hard-blocks it. He admits the file is mostly Claude rewriting full send. It’s now his most used skill. That tells you something: he trusts the process for risky changes, he just wants to keep the merge button.

The important detail is how the agent asks for help. A question buried in a normal message looks like a finished thread, so the skill tells it to use the harness’s question tool, which puts the thread back in his inbox, with the PR link, the blocker and a recommended option. And only when it truly can’t continue, because once he added the section the agent started asking all the time.

Descriptions are triggers#

One small point that most skill files get wrong. Theo’s descriptions don’t explain the skill. They say when to load it: “use when the user says Sol loop.” The open Agent Skills spec says a description should cover what the skill does and when to use it. Theo leans hard on the “when,” so a skill only loads when he names it.

He also refuses to turn off model invocation and use slash commands. With descriptions as trigger phrases, he can say “takeover, full send” out loud and get two skills at once, which some harnesses won’t do with manual invocation. The broader lesson is his, and it’s the right one: these files are bug fixes for agent behavior. Every time an agent does something he doesn’t like, he asks why, then patches the skill.

What a small shop can copy this week#

You don’t need Theo’s fleet of machines or a ClickHouse database of every request. Here’s what I’d set up for a two-person team.

  1. A review skill with a different vendor than your writer. If Claude writes, have GPT review, or the reverse. Cap it at three rounds, tell the writer to make the smallest fix, and allow pushback.
  2. Make the verdict visible. Every agent PR ends with the reviewer model, rounds used and final verdict. If the reviewer wasn’t happy, you should see that before you merge.
  3. Define proof before you allow autonomy. Write down what counts as evidence for your repo: a reproduction, the CI checks, a screenshot for UI. No proof, no merge.
  4. Start with full stop, not full send. Let the agent take PRs all the way to ready, but keep the merge yourself for a few weeks. Track how often you would have merged without changes. That’s your data for when to let go.
  5. Only one way to interrupt you. Blockers go through the question tool with full context. Progress updates go nowhere.
  6. Have a rollback before you have autonomy. Theo can let PRs merge themselves because broken nightlies get caught in hours. If you can’t revert fast, keep the human on the merge button.

Expensive models won’t save much on their own. The gain is in the hours you spend babysitting threads and re-reading context. Three text files and a reviewer that doesn’t like your code get you most of it.