Key facts
| Definition | Matching OpenAI API request and response shapes so existing clients work unchanged |
| Core endpoints | Chat completions, embeddings, streaming, JSON mode and function calling |
| Migration effort | Change the base URL and model name; keep the SDK |
| Why it matters | Tooling compatibility: SDKs, frameworks and gateways work without rewrites |
| Not covered | Some specialist endpoints such as image generation and fine-tuning are coming-soon on Plugsky |
| Per-model support | Parameter and capability support varies by model and is documented per model |
| Models | 30+ models behind one compatible endpoint |
| Status | Chat, streaming, JSON mode, function calling and embeddings are live |
TL;DR
- Compatibility is about wire format, not identical behavior.
- Changing the base URL is the whole migration for most code.
- Check per-model support for tools, JSON mode and streaming.
- Specialist endpoints differ — verify before assuming parity.
- Keep a rollback path: the change is one line in reverse.
How it works, step by step
- Inventory the OpenAI endpoints and parameters your application uses.
- Compare them with the provider's documented compatible surface.
- Change the base URL and API key in a staging environment.
- Map model names to the new catalogue and set per-model parameters.
- Run your test suite and evaluation prompts to catch behavior differences.
- Cut over production traffic and keep the old configuration for fast rollback.
Try it yourself
Open the OpenAI compatibility checker →
What compatibility covers
At minimum, compatibility means /v1/chat/completions accepts the same message format and returns the same response shape, including streaming chunks and tool calls. Embeddings, JSON mode and error formats complete the picture for most applications. When these match, an OpenAI SDK pointed at a different base URL works without code changes — that is the entire value proposition.
What compatibility does not guarantee
- Model parity: different models produce different outputs on the same prompt.
- Feature parity: not every OpenAI endpoint exists everywhere; some are provider-specific roadmap items.
- Parameter support: individual models may ignore or not support parameters such as specific tool formats.
- Behavioral quirks: temperature and tokenizer differences change output even with identical settings.
- Rate and limit semantics: throttling behavior is provider-specific.
Compatibility removes integration work, not evaluation work.
Common mistakes
- Assuming compatibility means identical answers and skipping evaluation entirely.
- Hard-coding model names instead of externalizing them for easy mapping.
- Using provider-specific extensions that break portability.
- Forgetting to test streaming and tool calls, not just simple completions.
- No rollback plan, even though reverting is a one-line configuration change.
How Plugsky implements it
Plugsky exposes an OpenAI-compatible chat completions endpoint plus embeddings, streaming, JSON mode and function calling, all live. Existing OpenAI SDK code runs after changing the base URL to api.plugsky.com and the model name. Because 30+ models sit behind the same interface, model changes are configuration, and the docs record per-model capability so you can verify tool support before routing traffic. Specialist endpoints are clearly labelled when they are coming soon, so you always know what parity you have.
Keep a compatibility checklist in your repository as the migration reference.
Honest comparison
| Concern | Compatible and verified | Compatible but untested | Proprietary API |
|---|---|---|---|
| Integration work | Base URL change | Base URL change | Custom client |
| SDK reuse | Yes | Yes | No |
| Behavior differences | Caught by evaluation | Discovered in production | Expected |
| Tooling ecosystem | Works with OpenAI-compatible tools | Usually works | Provider-specific |
| Rollback | One line | One line | Rewrite |
Frequently asked questions
What does OpenAI-compatible mean?
The provider implements the same request and response formats as OpenAI's API, so OpenAI SDKs and compatible tools work after changing the base URL and credentials.
Can I keep using the OpenAI SDK with Plugsky?
Yes. Point the SDK at Plugsky's base URL and use a Plugsky API key; your application code stays the same for the supported endpoints.
Does compatibility mean the same answers?
No. Outputs depend on the underlying model, so evaluate prompts on your workload. Compatibility removes integration work, not quality checks.
Which endpoints are covered?
Chat completions, embeddings, streaming, JSON mode and function calling are live. Some specialist endpoints are documented as coming soon.
How do I verify compatibility before migrating?
Run your existing test suite and evaluation set against a staging endpoint, covering streaming, tools and error handling, not just simple prompts.
Is migration reversible?
Yes. Because your code remains OpenAI-compatible, switching back is the same one-line configuration change in reverse.