Skip to content

Docs / migration

Migrate from OpenAI to the BrokenGPT API

A practical migration guide for moving supported chat-completions workloads to BrokenGPT, including base URL changes, testing, streaming, and errors.

UPDATED 01 Aug 20269 MIN READTECHNICAL GUIDE
01

First confirm that your workload fits the supported subset.

A migration is usually smallest when your application uses text chat completions, server-sent event streaming, function tools, or structured JSON and the client allows a custom base URL. Compatibility describes request and response shapes, not identical model behavior.

Inventory the exact endpoints and fields your production traffic sends. Hosted assistants, embeddings, image or audio inputs, and unrelated vendor features are not implied by chat-completions compatibility.

  • Record the SDK and runtime versions you deploy.
  • Capture representative requests after client-side serialization.
  • List every status code, header, and stream event your application depends on.
  • Separate schema compatibility tests from model-quality evaluations.
02

Change the base URL, API key, and public model alias.

Keep API keys on the server. Do not expose a BrokenGPT secret in browser JavaScript, mobile bundles, logs, analytics, or source control. Start with a non-streamed request so response and error handling are easy to inspect.

JAVASCRIPT MIGRATION

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.BROKENGPT_API_KEY,
  baseURL: "https://brokengpt.com/v1",
});

const result = await client.chat.completions.create({
  model: "broken-one",
  messages: [{ role: "user", content: "Explain this plainly." }],
});

console.log(result.choices[0]?.message?.content);
03

Run a migration matrix before shifting traffic.

Migration verification matrix
SurfaceVerifyFailure to catch
MessagesRoles, Unicode, null assistant content, tool messagesSerialization or validation errors
StreamingSSE chunks, disconnects, finish reason, [DONE]Hung UI or duplicated text
ToolsSchema, tool choice, tool-call loop, argument parsingUnsafe or malformed execution
JSONSchema validation and non-streamed deliveryInvalid downstream objects
LimitsContext, request rate, key spend and token capsSurprise 400 or 429 responses
AccountingInput/output usage, credits, workspace attributionIncorrect budgets or reporting
04

Roll out with an observable fallback boundary.

  1. Route a small, non-critical workload to BrokenGPT and attach your own trace identifier.
  2. Compare correctness, refusal, latency, tool behavior, and cost on the same prompt set.
  3. Handle 400 errors without retry, 401 and 403 as credential problems, 429 with bounded backoff, and 5xx as temporary service failures.
  4. Increase traffic only after application metrics and human review meet your acceptance criteria.

STRAIGHT ANSWERS

Frequently asked questions

01Is migration only a base URL change?

Sometimes, but only for applications inside the supported subset. You still need to test fields, streaming, errors, limits, accounting, and model behavior.

02Can I keep using the OpenAI JavaScript or Python SDK?

Clients that allow a custom base URL can send the supported request shape. Pin and test your exact SDK version because client defaults can change.

03Should I send all production traffic immediately?

No. Start with a small representative slice and expand after compatibility, behavior, and operational checks pass.

BUILD WITH THE LIVE CONTRACT

Test one real request end to end.

Create a scoped key, send a representative prompt, and verify output, usage, limits, and error handling before expanding the integration.

Create an account