ShadowSafin / Synapass

# Synapass
**An OpenAI-compatible gateway that decides, per request, which AI provider serves it — and proves it.**
Routing · failover · caching · policy · budgets · full request lineage
Quick start · Documentation · Troubleshooting
**Linux**
 [code] 
**macOS**
 [code] 
**Windows (PowerShell)**
 [code] 
One command per OS: clones, configures, and starts the full stack. Details in Quick start.
---
## What Synapass does
Synapass is an **inference gateway** and **control plane**. It sits between your
applications and your model providers, presents a single OpenAI-compatible
endpoint, and decides — per request, under policy — which provider serves it,
what happens when that provider fails, and what it cost.
It is also where providers, models, policies, tenants, keys, tools and caches are
managed. Changing which model answers production traffic is a dashboard edit
rather than a deployment.
Any client that speaks OpenAI works by changing its base URL. The extra response
fields are namespaced under `synapass`, so OpenAI SDKs ignore them.
## Why it exists
Inference stacks rarely get chosen. They accrete. By the time a few applications
are live you have:
- **A provider integration per service**, each with its own error handling, so a
 `429` means something slightly different everywhere.
- **No failover.** One upstream hiccup becomes an outage, because nothing knows a
 second provider exists.
- **Routing logic in application code** — a `if model == "gpt-4o"` here, a
 provider SDK there, copied into every service.
- **No cost control.** A runaway loop produces a bill nobody notices until it
 arrives.
- **No central answer** to "what did we spend, and which model produced the bad
 answers?"
Each is small. Together they are an operating burden that competes with the
product. Synapass moves all of it into one layer you can operate.
## Key features
| | |
| --- | --- |
| **OpenAI-compatible API** | `POST /v1/chat/completions`, streaming and buffered, plus `/v1/models`. An SDK swap, not a rewrite. |
| **Multi-provider routing** | Five strategies — `priority`, `weighted`, `lowest_cost`, `lowest_latency`, `highest_quality` — over a registry that knows each model's real context window, capabilities and price. |
| **Fallback chains** | Ordered failover with bounded retry and deterministic jitter. A started stream is never appended to; it is reported instead. |
| **Policy engine** | Match on model, tenant, key, task, size, region, sensitivity and endpoint. Resolved by specificity, so a specific rule always beats a broad one. |
| **Cost control** | Per-request ceilings checked against projected cost *before* the call, token and request rate limits, daily and monthly budgets. |
| **Provider & model management** | Add, test, probe, kill and revive providers. Discover remote models while preserving your local pricing, aliases and disables. |
| **Tool calling** | Client-executed by default. Optional bounded gateway-side execution with operator-owned limits and a durable st