Claudish Documentation

You can extend Claude Code's tool capabilities by routing its API traffic through a claudish monitor-mode proxy using the ANTHROPIC_BASE_URL environment variable. This technique allows you to intercept and modify the communication between the Claude Code client and the Anthropic API.

Key capabilities include:

• Replacing server tools: Swapping native server-side tools with regular tools that the executor can still call.
• Intercepting tool_result blocks: Rewriting tool results (including error messages) before they reach Claude Code.
• Injecting custom tools: Adding new tool definitions to the request's tools array that the client runtime doesn't natively implement.
• Modifying system prompts: Guiding tool invocation behavior via prompt injection.

Claude Code  ──ANTHROPIC_BASE_URL──▸  Claudish Monitor Proxy
                                          │
                                    ┌─────┴──────┐
                                    │ Transform:  │
                                    │ 1. Swap tool│
                                    │    type     │
                                    │ 2. Strip    │
                                    │    beta hdr │
                                    │ 3. Rewrite  │
                                    │    tool_    │
                                    │    result   │
                                    └─────┬──────┘
                                          │
                                          ▼
                                    Anthropic API
                                    (or OpenRouter)

You can extend Claude Code's capabilities by using a transparent proxy. Instead of injecting new MCP tools, a more effective pattern for replacing native features (like the advisor) is to intercept the tool loop via an API proxy.

The Tool Replacement Pattern

1. Tool Swap: Patch the proxy to intercept the native tool name (e.g., advisor_20260301) and map it to a regular tool. You should also strip the specific beta header (e.g., advisor-tool-2026-03-01) to prevent client-side conflicts.
2. Tool Result Rewrite: When the model calls the swapped tool, Claude Code will receive an error (e.g., No such tool available). The proxy should intercept this inbound tool_result, identify the tool_use ID, and rewrite the error content with your own stubbed advice or data.

This allows the model to receive injected advice as if it came from the native provider, and the model will treat the proxy-injected content identically to native responses.

Claudish uses a three-layer architecture to compose requests for different AI models and providers. This separation allows the system to handle the same model through different routes (e.g., via a direct API vs. an aggregator like OpenRouter) by mixing and matching layers.

The Three Layers

1. Layer 1: APIFormat (FormatConverter) - Handles wire format translation. It reshapes messages, converts tool schemas, and assembles the final request body (e.g., converting OpenAI Chat Completions to Anthropic Messages format).
2. Layer 2: ModelDialect (ModelTranslator) - Handles model parameter translation. It manages model-specific quirks like renamed parameters (e.g., thinking vs reasoning_effort), context window sizes, and vision support.
3. Layer 3: ProviderTransport (ProviderTransport) - Handles HTTP transport. It manages endpoints, authentication headers, and can override the stream parsing format.

Request Flow

When a request is made, it follows this sequence:

1. Normalize: Incoming OpenAI-format request is normalized to Claude's internal format.
2. L1 (APIFormat): Messages are reshaped, tools are converted, and the payload is built.
3. L2 (ModelDialect): Per-model parameter quirks are applied to the payload.
4. L3 (ProviderTransport): Auth headers and endpoints are added.
5. Execute: The HTTP request is sent.
6. Parse: The response stream is parsed based on a 3-tier priority (Transport override > Model dialect > APIFormat declaration).

ComposedHandler = APIFormat (explicit) + ModelDialect (auto-selected) + ProviderTransport

Claudish uses a specific syntax to route requests to different AI providers and models.

Preferred Syntax: provider@model[:concurrency]

The @ separator identifies the provider. You can optionally specify concurrency for local providers.

Examples:

• google@gemini-3-pro: Direct Google Gemini API.
• openrouter@deepseek/deepseek-r1: Explicit OpenRouter with vendor prefix.
• ollama@llama3.2:3: Local Ollama with up to 3 concurrent requests.
• ollama@llama3.2:0: Local Ollama with no concurrency limit (bypass queue).
• ll@my-model: LiteLLM proxy with auto catalog resolution.

Native Auto-Detection

If you omit the provider@ prefix, Claudish routes based on the model name pattern:

• google/* or gemini-* $\rightarrow$ Google Gemini
• openai/* or gpt-* $\rightarrow$ OpenAI
• moonshot/* or kimi-* $\rightarrow$ Kimi
• anthropic/* or claude-* $\rightarrow$ Native Anthropic
• bare name (no /) $\rightarrow$ Native Anthropic (treated as Claude model)

Custom URL Syntax

You can pass a full URL directly as a model spec to treat it as a local custom endpoint: http://localhost:11434/llama3.2