oc-cc-proxy

oc-cc-proxy runs a local LiteLLM Proxy that lets Claude Code send Anthropic Messages API requests to OpenCode Go's OpenAI-compatible endpoint.

The proxy listens on http://127.0.0.1:4000 by default and routes all Claude Code model names through LiteLLM wildcard passthrough to https://opencode.ai/zen/go/v1/chat/completions.

Quickstart (uvx)

uvx oc-cc-proxy --api-key your-key-here

You can still use OPENCODE_GO_API_KEY from the environment or a .env file instead. The proxy fails before accepting requests if neither --api-key nor OPENCODE_GO_API_KEY is provided.

uvx should run this package with Python 3.12 or 3.13. LiteLLM's current uvicorn and uvloop stack is not compatible with Python 3.14 yet.

Claude Code Settings

Add equivalent environment values to your Claude Code user-scope settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:4000",
    "ANTHROPIC_API_KEY": "dummy-key-for-claude-code",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-flash",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "qwen3.6-plus",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro"
  }
}

ANTHROPIC_API_KEY only needs to be non-empty for the local proxy path. OpenCode Go authentication uses the --api-key flag or OPENCODE_GO_API_KEY on the proxy process.

Configuration

• --api-key: optional CLI override for the OpenCode Go API key. Recommended for uvx usage.
• OPENCODE_GO_API_KEY: required if --api-key is not provided.
• OC_PROXY_HOST: optional host override, defaults to 127.0.0.1.
• OC_PROXY_PORT: optional port override, defaults to 4000.

Local Development Setup

1. Install dependencies:

   uv sync
   

2. Configure the OpenCode Go API key:

   cp .env.example .env
   

3. Edit .env and set OPENCODE_GO_API_KEY.

4. Start the proxy:

   uv run oc-cc-proxy
   

Validation

With the proxy running, validate non-streaming text, wildcard model passthrough, streaming terminal events, tool definitions, tool results, and streamed tool requests:

uvx oc-cc-proxy-validate --model deepseek-v4-pro

Expected successful output starts each check with ok:. Any dropped, malformed, or ignored tool-call behavior should be treated as a blocking compatibility issue before describing the proxy as Claude Code-ready.

Project-local checks:

uv run pytest
uv run ruff check .

Debugging

Enable LiteLLM verbose logging and local request-shape diagnostics:

uvx oc-cc-proxy --debug

If uvx selected Python 3.14, pin a supported runtime explicitly:

uvx --python 3.12 oc-cc-proxy --api-key your-key-here

Debug helpers redact sensitive headers such as Authorization, x-api-key, and api-key. Avoid pasting raw upstream logs publicly unless you have checked them for secrets.

To inspect the generated LiteLLM config path without starting the server:

uvx oc-cc-proxy --print-config --config /tmp/oc-cc-proxy-litellm.yaml

Validated Models

These models pass the full oc-cc-proxy-validate suite (non-streaming text, wildcard passthrough, streaming terminal events, tool definitions, streamed tool metadata, and tool-result follow-up):

• glm-5.1
• glm-5
• kimi-k2.5
• kimi-k2.6
• deepseek-v4-pro
• deepseek-v4-flash
• mimo-v2.5
• mimo-v2.5-pro
• minimax-m2.7
• minimax-m2.5
• qwen3.6-plus
• qwen3.5-plus

Current Limitations

• Tool-use compatibility must be validated against a live OpenCode Go account and target model before claiming a model is known-good for Claude Code.
• DeepSeek V4 and Kimi K2.x models require their returned reasoning metadata to be replayed on assistant tool-call history. The proxy installs a LiteLLM callback that converts Anthropic thinking blocks back into upstream reasoning_content before tool_result follow-up turns. Non-reasoning models (Qwen, GLM, MiMo, MiniMax) have thinking_blocks stripped unconditionally to avoid upstream rejection.
• MiniMax M2.7 emits empty choices chunks during streaming that LiteLLM's stream handler rejects. The proxy monkeypatches LiteLLM's Anthropic streaming adapter and repetition guard at import time to tolerate these chunks.
• Anthropic-specific features such as prompt caching, extended thinking, and any endpoints beyond /v1/messages are not claimed as supported unless separately validated.