SSC-STUDIO / Ai-Model-Gateway

OpenAI Anthropic Gateway

Run OpenAI Chat Completions, Anthropic Messages, and OpenAI Responses-compatible traffic through one self-hosted gateway with local routing policy, fallback, telemetry, config publishing, diagnostics, and rollback.

View on GitHub Anthropic Messages endpoint Evaluate in 15 minutes

If this fits your mixed OpenAI and Anthropic gateway workflow, star the repository after evaluation.

Protocol entry points

Keep mixed LLM clients behind one local operations layer.

AI Model Gateway is useful when some clients speak OpenAI-style APIs, some use Anthropic Messages, and operators still need one place to manage provider routing, failure behavior, telemetry, and config rollout.

OpenAI clients

Expose Chat Completions and Responses-compatible entry points for clients that already use OpenAI-shaped requests.

Anthropic clients

Use the Messages-compatible endpoint for Claude-oriented workflows while preserving local gateway policy.

Provider routing

Map public models to upstream providers and keep route, fallback, and health behavior inspectable.

Operational rollback

Preview, diff, publish, audit, and roll back protocol or provider config changes through the control plane.

Reality check

Compatibility should be evaluated by workflow, not assumed from the label.

The gateway focuses on Chat Completions, Anthropic Messages, and Responses-style workflows. It is not a full clone of every OpenAI or Anthropic product API. Start with the 15-minute path, then test the exact client features your application depends on.

./dist/gateway-cli test convert
Review supported data-plane routes
AI Model Gateway overview workspace showing runtime status and operations health

Fit check

Use it for operational control across client API shapes.

Good fit

  • Teams run a mix of OpenAI-compatible, Anthropic-compatible, and Responses-style clients.
  • Provider keys, routing policy, telemetry, and audit records should stay in local infrastructure.
  • Gateway config changes need preview, publish history, and rollback.
  • Operators need request logs, provider health, diagnostics, and fallback evidence.

Less ideal

  • You need a hosted model marketplace to own provider access and billing.
  • Your client requires unsupported OpenAI sub-APIs such as Assistants, Batch, image, or audio routes.
  • You only need a lightweight SDK wrapper without admin workflows.
  • You do not need telemetry, fallback, or config rollback.
OpenAI-compatible gateway page Self-hosted LLM gateway page Provider fallback gateway page LLM gateway comparison page Anthropic Messages endpoint Architecture notes

Review evidence

Check installability, quality, and security before adopting it.

Release archive install

Try the packaged v1.4.4 runtime with checksum verification, local config, runtime directories, and supervised startup commands.

Open release install path

Quality evidence

Review CI gates, local reproduction commands, runtime smoke checks, feature proof points, and current capability boundaries.

Open quality evidence

Security and trust model

Inspect admin auth, same-origin browser writes, provider-key handling, SSRF defenses, telemetry sensitivity, and update trust.

Open security model

Next step

Test your exact client workflow before promoting traffic.

Use the evaluation path and provider fallback demo first. If the project fits your mixed OpenAI and Anthropic gateway needs, starring the repository helps similar teams find it.

Star on GitHub Evaluate in 15 minutes