Open Source LLM Gateway with Claude Support: A Guide

If you're searching for an open source LLM gateway with Claude support, you're probably trying to unify Claude with other providers behind one API, add retries and fallback logic, or get usage tracking and rate limiting without building it from scratch. The short answer: several open source gateways (LiteLLM, Portkey's gateway, Helicone, and a few LangChain-adjacent proxies) support Claude's Messages API out of the box, but "supports Claude" means different things depending on which features you actually need — streaming, tool use, prompt caching, or team-level key management.

This article breaks down what open source gateways actually give you, what they leave you to build yourself, and when a managed option is the faster path.

What "Claude support" means in a gateway

Anthropic's Claude models are accessed through the Messages API, which has its own request/response shape, its own streaming event format (message_start, content_block_delta, etc.), and tool-use conventions that differ from OpenAI's function calling. A gateway that "supports Claude" should ideally handle:

• Message formatting — translating a unified request schema into Claude's expected payload
• Streaming — forwarding or normalizing Claude's SSE event stream
• Tool use — passing through tool_use and tool_result blocks correctly
• Rate limits and retries — respecting Anthropic's per-minute token limits
• Usage metadata — input/output token counts per request, ideally per user or per key

Most open source gateways cover the first point well and the rest unevenly. Streaming support is common; tool-use passthrough is less consistent, and usage metadata often needs extra instrumentation on your side.

Popular open source options

LiteLLM

LiteLLM is the most widely adopted open source LLM proxy. It maps dozens of providers, including Claude, to an OpenAI-compatible /chat/completions endpoint, which is convenient if your existing code already targets that shape.

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet-20241022",
    "messages": [{"role": "user", "content": "Summarize this ticket"}]
  }'

Tradeoffs: you run and patch the proxy yourself, configure a database for logging, and manage your own Anthropic API keys and billing. Claude-specific features like extended thinking or prompt caching sometimes lag behind Anthropic's SDK updates.

Helicone

Helicone started as an observability layer and added gateway-style routing. It's useful if logging and cost tracking are your primary need, with Claude support added via a proxy header rather than a full schema translation. It's lighter-weight than LiteLLM but less of a true multi-provider abstraction.

Portkey (open source gateway component)

Portkey's open source gateway handles request routing, fallbacks, and caching across providers including Claude. The hosted version adds a dashboard; the self-hosted gateway is closer to a routing layer than a full API product — you still need to handle authentication, per-team keys, and billing separately.

Common gaps across all of them

Running any of these yourself means you're responsible for:

• Hosting, scaling, and patching the proxy
• Storing and rotating the underlying Anthropic API key securely
• Building per-application or per-team API keys on top (most open source gateways don't give end users their own scoped keys out of the box)
• Monitoring uptime and handling provider-side outages or rate-limit errors

None of this is hard individually, but it adds up to a maintenance surface that's easy to underestimate when you just wanted "a gateway that supports Claude."

When a managed gateway makes more sense

If your actual goal is turning Claude access into a stable HTTPS API for your product — with application-scoped keys, streaming, tool use, and usage metadata already wired up — a managed gateway like SubToAPI skips the self-hosting step entirely. You get sub_live_... keys per application, team seats for managing who can issue and revoke them, and the same Messages-compatible request shape Claude already uses, so there's no schema translation layer to maintain.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet-20241022",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Draft a release note for v2.3"}]
  }'

Streaming and tool use work the same way as calling Claude directly — see /docs/streaming and /docs/tools — so if you've already built against the Messages API, migrating is mostly a base-URL and key change. Plans start at €9/month for solo use, with Team (€19/seat) and Scale (€49/seat) tiers for shared API keys and higher limits, and every plan starts with a free trial via /signup. Full pricing is on /pricing.

Choosing between self-hosted and managed

A rough decision rule:

• Pick an open source gateway if you need to route across multiple providers (Claude, GPT, open models) with full control over infrastructure, and you have the ops capacity to run and secure it.
• Pick a managed gateway if your core need is Claude specifically, exposed as a clean API with per-app keys and team access, without running a proxy yourself.
• Pick neither if you're calling Claude directly from a single backend service with no multi-tenant key requirements — Anthropic's SDK is enough.

The quickest way to evaluate fit is to try the request shape you'll actually use in production. Check /docs/quickstart and /docs/messages for the exact request and response format before committing to either approach.

questions

Is there a fully open source gateway that supports every Claude feature? Not consistently. LiteLLM and Portkey's open source gateway cover core chat and streaming well, but newer Claude features like prompt caching or extended thinking often arrive in Anthropic's SDKs before gateway maintainers add support.

Do open source gateways give end users their own API keys? Most don't by default — they proxy a single upstream key. Per-application or per-team scoped keys usually require you to build an authentication layer on top, which is where managed options differ.

Can I switch from an open source gateway to SubToAPI without rewriting my integration? If your code already targets Claude's Messages API shape, yes — you mainly change the base URL and the API key, since SubToAPI mirrors that request format rather than inventing a new one.