AI Gateway: Reliable Model Access
One OpenAI-compatible entrypoint for model access with visible capacity, route health, spend, launch checks, and failure behavior.
Reliable model access needs visible status, route choice, and recovery behavior.
Routing, capacity, spend, and recovery stay scattered across logs.
One model-access service shows account status, route choice, spend, and launch checks.
Route health, capacity, spend, smoke checks, and stream failures are visible.
Where It Was Risky
Teams building on frontier GPT routes quickly hit infrastructure problems around route status, capacity, spend, and recovery:
- Protocol Fragmentation: Each provider has a proprietary request/response format, streaming semantics (SSE), error handling, and authentication model.
- Provider Capacity Planning: Provider limits and service-level objectives require compliant routing, capacity monitoring, and graceful degradation before saturation.
- Unpredictable Latency: "Thinking" phases for frontier models can last up to 2-3 minutes, causing idle timeout disconnects at the load balancer level.
- Lack of Unified Observability: Usage volume, latency distribution, and error rates are fragmented without centralized control.
Businesses need model access that behaves like a service: one stable OpenAI-compatible entrypoint, visible account capacity, route choice, cost tracking, and a recovery path when the external model route becomes unreliable.
What Changed in the System
The architecture treats model access as a real service, not as a thin proxy. Requests, account pools, route eligibility, usage, cost data, failure behavior, and launch checks are separated so AI can keep the service working without guessing from logs.
┌─────────────────────────────────────────────────────────┐
│ CLIENTS │
│ (OpenAI SDK, curl, any HTTP client) │
└───────────────────────┬─────────────────────────────────┘
│ OpenAI-compatible API
▼
┌─────────────────────────────────────────────────────────┐
│ MODEL ACCESS SERVICE │
│ ┌──────────┐ ┌──────────────┐ ┌───────────────────┐ │
│ │ Protocol │ │ Session │ │ Load Balancer │ │
│ │ Adapter │ │ Affinity │ │ (least-loaded) │ │
│ │ (transl.)│ │ Manager │ │ │ │
│ └────┬─────┘ └──────┬───────┘ └────────┬──────────┘ │
│ │ │ │ │
│ ┌────▼───────────────▼───────────────────▼──────────┐ │
│ │ SHARED RECORDS │ │
│ │ ArcSwap (lock-free config) + CRDT/LWW sync │ │
│ │ PostgreSQL (Event Sourcing + streaming replica) │ │
│ └───────────────────────────────────────────────────┘ │
└───────────────────────┬─────────────────────────────────┘
│ Managed connection pool
▼
┌─────────────────────────────────────────────────────────┐
│ APPROVED GPT ROUTES │
│ OpenAI-compatible route │ account pool │ capacity │
└─────────────────────────────────────────────────────────┘What Has to Work
- Protocol Adapter: Bidirectional format translation around the OpenAI-compatible contract. Clients get one stable interface while route-specific details stay inside the service.
- Session Affinity Manager: Persistent binding of "client session → upstream provider", surviving service restarts. Improves cache locality and keeps long dialogs predictable.
- Load Balancer: Least-loaded routing with anti-thundering-herd protection during initial session assignment. Balances traffic across approved GPT routes and preserves service-level objectives.
- Shared Records: `ArcSwap` lets configuration change without stopping request processing. CRDT/LWW keeps route and session records aligned across nodes. PostgreSQL stores the durable event history and replicated service data.
- Managed Connection Pool: RAII-controlled connection pool with aggressive HTTP/2 keepalive to prevent idle timeout disconnects during extended generation phases.
What Keeps It Running
- Frontend: Private status view for accounts, capacity, cost analytics, and live checks.
- DevOps: Nix Flakes (reproducible builds) + systemd socket activation (zero-downtime service switch).
What Became Visible
The visible signals show whether model access is healthy, affordable, and recoverable: