← Back to projects

01 · CONDUCTOR

Conductor

OpenAI-compatible AI gateway

One endpoint, every model you pay for — routed, metered, and kept honest. Automatic failover, cost tracking, and persistent task orchestration across providers.

building · Go · OpenAI-compatible API · v2.5 agent runtime

02

What it is.

Conductor is a self-hosted OpenAI-compatible AI gateway. It merges multiple model provider subscriptions — OpenAI, Anthropic, Gemini, DeepSeek, Groq, and others — into a single endpoint with a unified API shape. Point your coding tools at one URL and access every model you own.

It handles routing, rate limiting, automatic failover, and response normalization. When a primary model fails, requests fall back through configured chains or dynamically into the full catalog, filtered to the request's category (vision→vision, planning→ reasoning+tools). A request only errors when no eligible model can serve it.

Beyond routing, Conductor also runs a persistent agent orchestration runtime (V2.5). It classifies intent, generates plans, routes across providers with tool calls (filesystem, shell, git), and verifies results — all behind the same gateway key.

api OpenAI-compatible
lang Go
providers 18+ supported
storage SQLite (usage/cost)
agent runtime V2.5 — bounded loops
deploy Docker, Fly.io

03

Why I built it.

I have subscriptions to multiple model providers. Each has its own API shape, rate limits, and failure modes. Managing them separately means juggling keys, handling provider-specific errors, and losing visibility into actual cost and usage across the stack.

Conductor solves that by sitting between my tools and every provider. One API key, one endpoint, one ledger. Providers stay isolated — their keys never leave my machine, their traffic never mixes upstream. And when one goes down, the gateway routes around it automatically.

04

How it works.

01

Request arrives

Client sends a standard OpenAI-format request with the gateway key. The gateway validates auth, resolves the model ID, and checks provider health.

02

Route and forward

The request is routed to the appropriate provider adapter. Provider-prefixed IDs route directly; bare IDs resolve through the config or virtual categories (auto, fast, coding, …).

03

Normalize and return

Provider responses are normalized to OpenAI format. Token counts, latency, and cost are recorded in SQLite. If the primary fails, the gateway retries through the fallback chain or selects from the full eligible catalog.

05

Current state.

Gateway routing Multi-provider, OpenAI-compatible, automatic failover
Model catalog 18+ providers, merged catalog with health probes
Usage and cost tracking Per-request tokens, latency, USD — stored in SQLite
Task orchestration (V2.5) Intent classification, plan generation, agent loops with tool calls
Dashboard API Models, status, usage, costs behind gateway key