Planverity speaks the OpenAI chat-completions shape. Integration is a base-URL change — streaming, tool calls and the response envelope are unchanged, so an existing client does not know the difference.
Point your existing SDK at the gateway and pass a Planverity key. Nothing about your request or response handling changes. That constraint shaped the whole surface: an integration that requires a rewrite does not get adopted, and a gateway nobody adopts governs nothing.
Only retryable failures walk the fallback chain — a rate limit or a 5xx. A malformed request or a rejected credential does not, because retrying those on another model reproduces the same error more expensively. Policy is revalidated immediately before each attempt, so a fallback can never reach somewhere the primary was refused.
Failover is only possible before the first byte. Once a delta reaches your client, switching models would splice two models' output into one answer — a silently corrupted response, worse than an error. A mid-stream failure therefore ends the stream with an explicit error event rather than quietly recovering.
const client = new OpenAI({
apiKey: process.env.PLANVERITY_API_KEY,
baseURL: "https://api.planverity.ai/v1",
});
// Unchanged from here down.
const response = await client.chat.completions.create({
model: "auto",
messages: [{ role: "user", content: prompt }],
});Streamed tool calls are not yet reassembled and are rejected with an explicit error rather than silently mishandled. Per-key and per-tenant rate limiting is not built, so a public deployment is protected by key entropy and spend caps alone.