harnesses · 9 min read · 2026-07-12

Claudex: how to run GPT-5.6 Sol in Claude Code

Claudex is Claude Code pointed at GPT models. You run a local proxy (CLIProxyAPI) that speaks Anthropic's API but answers with OpenAI's models, point Claude Code at it with ANTHROPIC_BASE_URL, and launch with --model gpt-5.6-sol. You keep Claude Code's harness, its tools, its subagents and its terminal, running a GPT engine underneath. Setup takes about five minutes.

The interesting part is not that it works. The interesting part is who told you to do it. Tibo posted the recipe for running GPT-5.6 Sol inside Anthropic's Claude Code and summed up the position in one line: we don't discriminate on the harness.

He was quoting Theo, who had worked out the setup and posted his own summary: install CLIProxyAPI, connect it with Claude and Codex auth, then wrap the whole thing in a shell alias. Two prompts of work, in his telling.

Tibo's reply to that thread was the part that made it spread: "Share the recipe. People want to know how to use GPT-5.6 Sol in CC. We don't discriminate on the harness."

That sentence is worth sitting with, because it quietly concedes something the industry has been circling for a year. The model and the harness are two different products, and users are allowed to mix them.

What a harness actually is

A model, on its own, is a text completion endpoint. It cannot read your repository, it cannot run your tests, and it has no memory of what it did ten minutes ago. Everything that turns that endpoint into something that can finish a real engineering task is the harness.

The harness is all of the following, none of which are weights:

• The agent loop, which decides when to think, when to call a tool, and when to stop.
• The tool schema: what read, edit, bash, and search actually look like to the model.
• Context management: what gets loaded, what gets compacted, what gets thrown away.
• Subagents and delegation, which decide how work is split and rejoined.
• Permissions and sandboxing, which decide what the model is allowed to do unattended.
• The system prompt, which is far longer and far more opinionated than anyone expects.

The cleanest way to think about it: the model is the engine, the harness is the car around it. Two cars with the same engine do not drive the same. Claude Code and Codex CLI have made genuinely different bets on the loop, on how aggressively to compact context, and on how much autonomy to hand the model by default. So when you run Sol inside Claude Code, you are not running "Sol". You are running Sol in a body built by a different team for a different model.

Which is exactly why people are curious enough to try it. It is also why the results are messier than the tweets suggest, and we will get to that.

The recipe

Claude Code has a documented environment variable, ANTHROPIC_BASE_URL, that points it at a different endpoint. Anything that speaks the Anthropic Messages API can sit at that address. CLIProxyAPI is a local server that logs into your ChatGPT or Codex account over OAuth and then exposes those GPT models behind exactly that API shape. Claude Code talks Anthropic, the proxy translates, GPT answers.

1. Install and authenticate

brew install cliproxyapi

# OAuth into your ChatGPT / Codex account
cliproxyapi -codex-login

# optional: add Claude auth too, so one proxy serves both families
cliproxyapi -claude-login

brew services start cliproxyapi

2. Give the proxy a key

The config ships with placeholder keys. Open it and replace them with one real secret. On Homebrew installs the file lives at /opt/homebrew/etc/cliproxyapi.conf:

port: 8317

api-keys:
  - "pick-a-long-random-string"

Restart, then confirm the proxy is actually serving models before you touch Claude Code:

brew services restart cliproxyapi

curl -s -H "Authorization: Bearer pick-a-long-random-string" \
  http://localhost:8317/v1/models | jq -r '.data[].id'

# gpt-5.6-sol
# gpt-5.6-terra
# gpt-5.6-luna
# gpt-5.5
# gpt-5.4
# gpt-5.3-codex-spark

3. The alias

This is the one from the thread, and it is doing more than it looks:

alias claudex='ANTHROPIC_BASE_URL=http://localhost:8317 \
ANTHROPIC_AUTH_TOKEN=pick-a-long-random-string \
CLAUDE_CODE_SUBAGENT_MODEL=gpt-5.6-sol \
CLAUDE_CODE_ALWAYS_ENABLE_EFFORT=1 \
CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=3 \
ENABLE_TOOL_SEARCH=false \
claude --model gpt-5.6-sol'

Those last two are the tell. They are compatibility shims. The harness is Claude-shaped, and you are filing down the edges so a GPT engine fits.

What we actually measured

We ran this end to end rather than trusting the thread, and three things came out that nobody in the replies mentions.

Sol is gated at the account level, not the proxy level

The proxy happily lists gpt-5.6-sol in /v1/models. Sending a real turn to it on a lower ChatGPT tier gives you this:

{"type":"error","error":{"type":"invalid_request_error",
 "message":"The 'gpt-5.6-sol' model is not supported when using Codex
            with a ChatGPT account."}}

The listing is aspirational, the entitlement is enforced server side. On the same account, gpt-5.6-terra and gpt-5.6-luna answered immediately. If Sol 400s on you, your setup is not broken and your plan is the reason. Verify with a one token request before you blame the proxy.

Prompt caching survives the trip

This was the thing most worth checking, because a broken cache would make the whole setup expensive and slow. It holds up. A proxied turn in our transcript:

model: gpt-5.6-terra
usage: { "input_tokens": 465,
         "cache_read_input_tokens": 216064,
         "output_tokens": 109 }

Cache reads in the hundreds of thousands, on a GPT model, inside Claude Code. Also note that the session still writes to ~/.claude/projects exactly as normal, which means every Claude Code telemetry tool you already use keeps working.

The context meter lies

Claude Code computes context percentage against the window it assumes the model has. Route a GPT model through the proxy and that assumption is wrong, so the meter can march to 100% context used on a session that is nowhere near full. Nothing breaks, but do not trust the number, and expect auto-compact to fire earlier than it should.

Answering the thread

The replies were better than the post. Taking them in turn.

"Is Anthropic going to give me detention?" and "I was worried I'd get banned"

The recipe came from Tibo himself, in public, about running GPT models in someone else's harness. Anthropic's side of it is quieter but not hostile: ANTHROPIC_BASE_URL is a documented, supported variable, and pointing Claude Code at a non-Anthropic endpoint is a first-class configuration (it is how Bedrock, Vertex, and every GLM-style integration already work). What you are not doing is spending Anthropic quota, because when the base URL points elsewhere, Anthropic never sees the request. The genuine risk is narrower and worth naming: a local proxy is holding your OAuth tokens, and automated abuse detection on the OpenAI side keys off usage patterns, not politeness. Weigh that yourself.

"So it's literally hardcoding 5.6 Sol?"

In alias form, yes. That is the weakness of the recipe. The alias pins one model at launch, and a shell alias cannot give you a picker. But /model still works inside the session, and the proxy is serving the whole catalog, so the model list is a property of your proxy rather than of the alias. The alias is just the laziest possible front end for it.

"I want Fable as my main model and GPT for subagents"

This is the best question in the thread and it does have an answer. It fails when the proxy only knows Codex, because every request from Claude Code (main model and subagents alike) leaves through the same base URL, so the proxy must be able to serve both families. Authenticate both:

cliproxyapi -claude-login
cliproxyapi -codex-login

# main model Claude, subagents GPT, both through one proxy
ANTHROPIC_BASE_URL=http://localhost:8317 \
ANTHROPIC_AUTH_TOKEN=your-key \
CLAUDE_CODE_SUBAGENT_MODEL=gpt-5.6-sol \
claude --model claude-fable-5

That is precisely why Theo's own tl;dr said "set up CLIProxyAPI with Claude and Codex auth" rather than Codex alone. The caveat, and this answers the reply asking for Sol Ultra orchestrating with Luna doing quick fixes: CLAUDE_CODE_SUBAGENT_MODEL is a single value. You get one subagent model, not a per-role routing table. Different models per subagent type is not expressible today.

"Only with API, right?"

No. The OAuth login against a ChatGPT or Codex subscription is the entire point of CLIProxyAPI. Just remember the gating above: subscription tier decides which models actually answer.

"Have you noticed weird behaviours? Bad tool calls, cache broken?"

Cache is fine, as shown above. Tool calls are the real friction, and the alias admits it: ENABLE_TOOL_SEARCH=false and a concurrency cap of 3 exist because Claude Code's tool-calling defaults are tuned for Claude. This is also the honest answer to the reply about GPT struggling with computer use inside Claude Code. It is not a bug in either product. It is a tool schema and an agent loop designed around one model's habits, being driven by another model's.

"Where are the benchmarks? Why is Claude Code better?"

There aren't any good ones, and you should be suspicious of anyone who says otherwise. Most comparisons floating around measure each model on its native harness, which tells you nothing about the same model across two harnesses. The honest position: run it, and if Sol in Claude Code feels better on your codebase, that is a real result for you and not a benchmark claim.

"Is this the same concept as the GLM integration?"

Exactly the same mechanism. Z.ai and every other Anthropic-compatible provider work by owning the other end of ANTHROPIC_BASE_URL. The only difference here is that the endpoint is running on your laptop and it is speaking to a subscription instead of an API key.

"Are you using this over Codex?"

Honestly: not exclusively, and neither should you. Codex CLI is a very good harness and Sol was built and tuned inside it. What claudex really buys you is optionality, the ability to put any engine in any body and keep the one that wins on your work. Which brings us to the actual problem with the recipe.

The alias is the wrong shape for this

Everything above is one shell alias. That means one hardcoded model, one set of env vars, and a fresh session every time you want to change anything. It also means you now have Claude sessions, Codex sessions, and claudex sessions, all of them just terminal tabs you have to remember the identity of. That is the thing that will actually stop you using it after a week.

A model choice is not a shell alias. It is a gear. It should have a physical position, a label you can read at a glance, and a session that persists behind it. That is why we shipped Claudex mode in Model Shift: it detects your CLIProxyAPI, reads the model catalog the proxy is actually serving, probes which of those models your plan will genuinely accept, and lays them out across the H-gate. Fifth is Sol, R backs you out to plain Anthropic Claude, and every gear is its own persistent tmux tab with the env vars already wired. The effort dial drives /effort, which the alias enables and then gives you no way to turn.

Further reading: Claude Code vs Codex: why the answer is both · The Claude Code /model command, completely explained · Why switching models mid-session breaks your prompt cache