base_url on your existing OpenAI client.
What this buys you
- Every request your app already makes becomes an OpenTracy trace.
- The engine can fan out to 13 providers — keep calling
model="gpt-4o", or switch tomodel="anthropic/claude-sonnet-4-6"without touching your auth code. - Routing aliases become usable: later, point
model="smart"at a distilled student without the app knowing.
The change
Python (OpenAI SDK)
TypeScript (OpenAI SDK)
curl
Where do provider API keys live?
On the engine, not the client. Three ways:~/.opentracy/secrets.jsonon the host running the engine:- Environment variables (
OPENAI_API_KEY,ANTHROPIC_API_KEY, etc.) read by the engine process. - UI: Settings → Integrations in the self-hosted UI. Stored encrypted in ClickHouse.
Changing models across providers
Because the engine speaks all 13 provider APIs, switching models is a string change:provider/model format is the only convention to learn.
Using a routing alias
An alias is a logical name you define once in the engine, then call by name:"smart" at the student.
The app code doesn’t change — the model upgrade is a config change
on the engine side.
What you get in the response
Standard OpenAI fields plus OpenTracy extras:Streaming
Streaming works unmodified. The engine translates upstream streaming formats (Anthropic SSE, Bedrock event-stream, etc.) into OpenAI’s SSE shape, so your client code doesn’t need per-provider logic:Tool calls
Tool / function calls translate across providers. You pass OpenAI-shapedtools and tool_choice, and the engine adapts them to Anthropic’s
tools, Gemini’s function declarations, etc.:
Caveats
Next
Self-host
Run engine + ClickHouse + UI with Docker Compose.
Python SDK
If you’re starting fresh (not adapting an OpenAI app), use
opentracy directly.
