Using Claude Opus 5.5 Smoothly in Claude Code via a Grok Bot Host

Want to write code with Claude Code locally and pick Opus as the model, only to run into a very "mysterious" problem: some models work, but Opus returns 403 right away. After some fiddling you'll find that this usually isn't "the key is wrong" — it's the wrong egress IP.

This post records a relatively reliable setup for use inside mainland China: use a gateway compatible with the Anthropic Messages API (Experiential Labs as the example) for models and authentication, send requests out from an overseas node through a local proxy, and use a standalone launcher to keep this configuration isolated from your original local gateway.

Note: What follows only covers a configuration for personal development with your own API key (BYOK). It has nothing to do with cracking or unauthorized access of any kind.

Recently Experiential Labs is running a marketing campaign that offers a certain amount of free usage of the Claude Opus 5.5 model. I'll take the opportunity to share how to use it from inside mainland China and enjoy Claude's formidable coding ability and top-tier taste.

After you link a bank card, you automatically receive a certain amount of credits, and once you've created an API Key you can use whichever model you like through the API.

At first I used cc-switch, but after switching the configuration you'll find it doesn't work. If you don't have a stable residential IP, Claude Code may show this error when you use it:

My approach: use the computer that comes with a Grok bot as the IP egress. The bot's computer is in the US, so it has a natural US IP — why not use it? All you need to do is tell your Grok bot to set things up on that machine, and then tell you how to operate and use it locally. So you need at least a Grok bot + 🪜 (a proxy tool). The prompt for the bot is at the end of the post!

The Symptom: Not Every Model Returns 403

The usual situation:

• Official Claude Code uses /login, which tends to fail or hit regional restrictions from inside mainland China

• After switching to a third-party compatible gateway, models like DeepSeek may work fine

• As soon as you switch to claude-opus-5.5 (or a similar Anthropic model), you get a geo / region 403 again

The key point: many upstreams look at the client's egress public IP. Even if your request goes to an overseas gateway domain, if the TLS handshake and HTTP request still leave from your local IP, Anthropic's side may still reject it outright. Non-Anthropic models often don't go through the same regional policy, which is why you see "same gateway, different models, one works and one doesn't".

In one sentence:

Make the requests Claude Code sends go out from an overseas egress IP, not from your local public IP inside mainland China.

The Overall Chain

Terminal in the project directory
  → Standalone launcher (e.g. claude-explabs)
  → Forced through the local HTTP proxy (e.g. 127.0.0.1:10808)
  → The proxy sends the request out from an overseas node
  → Compatible gateway (e.g. https://api.experientiallabs.ai)
  → Opus is called via the Anthropic Messages API
  → The result comes back to the terminal

Three things, each handling one part:

1. Compatible gateway: Provides an OpenAI / Anthropic compatible interface, so Claude Code can use it as a backend with ANTHROPIC_API_KEY + Base URL. Note that some clients append /v1/messages themselves, so the Base URL usually shouldn't carry an extra /v1 suffix; follow the gateway's documentation.

2. Local proxy: Only responsible for changing the egress IP. The request's destination is still the gateway — it is not "getting past the firewall to log in to the official site".

3. Standalone launcher: A separate configuration directory that hard-codes the gateway, the model and how the key is read, and clears the old local-gateway variables from the environment, so it doesn't contaminate your original claude configuration.

Why You Need a "Standalone Launcher"

Many people already have a Claude Code setup on their machine:

• Configuration in ~/.claude

• It may point to a local forwarder (for example 127.0.0.1:5000)

• It may use ANTHROPIC_AUTH_TOKEN, model aliases, plugin hooks and so on

If you edit this configuration directly to connect to an Opus gateway, the common side effects are:

• A dual-authentication warning (a Token and an API Key present at once)

• It still tries to connect to a local port that has already died, which shows up as Connection refused

• The local model chain you normally use gets broken

A cleaner approach:

At a minimum, the launcher should:

• Set CLAUDE_CONFIG_DIR to the standalone directory

• Set the gateway Base URL and the target model (such as claude-opus-5.5)

• Inject ANTHROPIC_API_KEY from a file or helper (with permissions tightened so only you can read it)

• unset ANTHROPIC_AUTH_TOKEN, so OAuth / an old token doesn't take priority

• Check whether the local proxy port is listening; if it isn't, exit with an error instead of quietly returning 403

• Set HTTP_PROXY / HTTPS_PROXY / ALL_PROXY, and configure NO_PROXY for localhost

Mind the version too: newer Opus models have a minimum version requirement for Claude Code, and a CLI that is too old may not recognize the model at all. When "everything is configured correctly and it still doesn't work", first confirm that the CLI version is new enough.

Minimal Usage

Start the proxy client first and confirm that the local port (the example uses 10808) is listening, then:

cd /path/to/your-project
claude-explabs

You can self-check in this order:

1. Is the proxy port in LISTEN state?

2. Does the gateway's Opus endpoint return HTTP 200 through the proxy?

3. Then run a very short conversation as a smoke test with claude-explabs -p "…"

If any step fails, check the egress first, rather than suspecting "the model name is wrong".

Common Misconceptions

• Thinking an overseas domain is enough: The domain may be overseas while the egress IP is still inside mainland China.

• Mixing two sets of configuration: One side is local :5000, the other is a cloud gateway; the symptom is intermittent failure.

• Proxy on but wrong port: The system proxy shows as on, but the port Claude Code actually uses has nobody listening, which is the same as having no proxy.

• Assuming "the key expired" as soon as the proxy is off: Most of the time the egress has simply switched back to mainland China and the 403 is back.

• Blaming regional restrictions for every model: Non-Anthropic models may work the whole time; don't infer anything about Opus from whether they work.

What This Setup Solves and Doesn't Solve

Suitable for:

• Building, debugging and using Claude Code to modify repositories on your own machine

• You already have an API key for a compatible gateway

• You already have a working proxy client locally

Not suitable to treat as:

• A way to "get official Claude for free"

• A guarantee that you can turn off the proxy and still use Opus reliably

• The one standard for a team's production environment (teams are better served by a centralized gateway and a compliant egress)

Summary

When running Claude Code + Opus inside mainland China, what really blocks you is often the egress IP, not the editor itself. It becomes clear once you separate three things:

1. The gateway handles models and protocol compatibility

2. The proxy handles changing the egress

3. The standalone launcher handles configuration isolation and failing early

It's not that Claude Code suddenly became able to reach Anthropic directly, but that "a proxy to change the egress + a compatible gateway + a standalone launcher" are stacked together. Once you understand that, troubleshooting gets much faster: check the proxy port first, then whether the gateway returns 200, and only last the model name and the CLI version.

Prompt

Please set up "Claude Code + Opus (via a compatible gateway)" on this Mac. It must be reusable and must not break my existing claude configuration.

## Goal
Let me launch Claude Code from a project directory on this machine with a standalone command, with the model going to Opus (such as claude-opus-5.5) through a gateway compatible with the Anthropic Messages API. A direct connection from mainland China gets a 403, so it must be forced through the local proxy to change the egress IP.

## Hard constraints
1. Do not overwrite or break the existing `~/.claude` (it may already be connected to a local gateway such as 127.0.0.1:5000).
2. The Opus-specific configuration must be isolated: a standalone config directory (for example `~/.claude-explabs`) + a standalone launcher (for example `~/.local/bin/claude-explabs`).
3. The launcher must:
   - Set `CLAUDE_CONFIG_DIR` to the isolated directory
   - Set the gateway Base URL (no extra `/v1` suffix; follow the gateway's documentation) and the model name
   - Use `ANTHROPIC_API_KEY` (don't rely on `ANTHROPIC_AUTH_TOKEN`, which takes priority; unset the old token at startup)
   - Force `HTTP_PROXY`/`HTTPS_PROXY`/`ALL_PROXY` to point at the local proxy; `NO_PROXY` must include localhost
   - Check before launch whether the proxy port is listening, and if it isn't, exit with a clear error instead of quietly returning 403
4. Store the API Key in a local file (permissions 600) and read it with a helper; do not put it in the chat log and do not commit it to a repository.
5. The Claude Code CLI version must meet that Opus model's requirement; if it doesn't, upgrade to a version that does.
6. First probe my machine's existing Claude Code, proxy port and current settings, then act; if there are conflicts, explain them first and then isolate.

## Information I'm providing (I'll fill it in as appropriate)
- Gateway: Experiential Labs (or another Anthropic-compatible gateway)
- Base URL: https://api.experientiallabs.ai
- Model: claude-opus-5.5
- Local proxy: 127.0.0.1:____ (I'll fill in the port, commonly 10808 / 7890)
- API Key: please request it from me in a secure way (secret-request); don't make me paste it in plain text in the chat

## Acceptance criteria
1. With the proxy on: a request to the gateway's Opus endpoint through the proxy returns HTTP 200
2. From any project directory, running the launcher allows a normal conversation (a very short `-p` smoke test is fine)
3. Running the original `claude` directly is unaffected
4. With the proxy off: the launcher should clearly say "proxy is not on" instead of failing vaguely
5. At the end, tell me in English: how to use it, what to watch out for, and the list of related file paths

Do it directly on my computer, including the configuration and the self-check; don't just give me a tutorial to type in myself.