Key facts
| Definition | Same routes and payload shapes as OpenAI's /v1 namespace |
| Drop-in change | Set base_url to https://api.plugsky.com/v1 and map the model name |
| Typical coverage | Chat completions, streaming, function calling, JSON mode, embeddings, errors |
| SDK support | OpenAI Python, Node, Go, Java, Rust and raw HTTP |
| Frameworks | LangChain, LlamaIndex, Vercel AI SDK, Haystack, Semantic Kernel, AutoGen |
| Beyond the spec | Plugsky extensions live under /v1/plugsky/* |
| What differs | Some endpoints (images, audio, batch, fine-tuning) are coming soon |
| Product status | Live |
TL;DR
- Compatibility means your SDK, prompts and evals survive a provider change.
- The migration is a base URL plus a model-name map, not a rewrite.
- Test the parameters you actually use — compatibility is not all-or-nothing.
- Vendor extensions belong in a separate namespace so the core stays portable.
- Keep a rollback path: reverting is the same one-line change.
How it works, step by step
- Inventory the endpoints, parameters and response fields your code depends on.
- Change base_url to https://api.plugsky.com/v1 and map model names.
- Run your existing test suite and evals unchanged to measure drift.
- Test the edge features you rely on: streaming, tools, JSON mode, embeddings.
- Check error handling against the shared OpenAI error schema.
- Run a shadow traffic comparison before cutting production over.
- Document the model map so rollback is a config change, not a code search.
Original data
Try it yourself
Open the OpenAI compatibility checker →
What "compatible" actually covers
Compatibility is a contract at the HTTP layer: same paths, same JSON field names, same response envelopes. Plugsky implements the OpenAI /v1 namespace for chat completions and embeddings, including streaming chunks, tool-call payloads, JSON mode and the shared error object. That is what makes the migration one line:
from openai import OpenAI
client = OpenAI(api_key="sk-live-…", base_url="https://api.plugsky.com/v1")Because the SDK never changed, retries, timeouts and typing keep working. Frameworks that accept a base URL — LangChain, LlamaIndex, Vercel AI SDK, Haystack, Semantic Kernel, AutoGen — inherit the same portability.
What compatibility does not promise
- Every optional parameter: model-specific options may be rejected rather than ignored. Test the parameters you actually send.
- Identical outputs: the same prompt can produce different text; compatibility is about the interface, not the weights.
- Feature parity everywhere: Plugsky's image, audio, batch, fine-tuning and Assistants endpoints are coming soon, and capability varies by model.
- Same rate limits and pricing model: Plugsky uses fair-use request rates on flat plans rather than per-token billing.
- Vendor extensions: Plugsky-specific features live under
/v1/plugsky/*, so core code stays portable.
How to test compatibility in an afternoon
Build a small compatibility matrix rather than trusting a marketing claim. Record the endpoints you call, then exercise each with a smoke test: a basic completion, a streamed completion, a function call, a JSON-mode extraction and an embedding batch. Assert on the fields you parse, not the text. Then replay a sample of production prompts through both providers with your eval harness and compare quality, latency and failure modes. Anything that fails becomes either a code change you plan or a reason to stay. Store the model map in configuration so future provider changes are a table edit.
Why it matters beyond convenience
A compatible interface is an exit option, and exit options change negotiation. Teams that can move a workload in an afternoon make decisions on data residency, pricing model and model quality rather than on migration cost. Compatibility also composes with residency: Plugsky serves the same contract from pinned regions and sovereign deployments, so regulated workloads keep the same application code when the data path moves inside a VPC or an air-gapped environment. The practical rule: keep the OpenAI core as the contract, isolate vendor extensions behind an adapter, and re-run your evals on every provider or model change.
Honest comparison
| Dimension | OpenAI-compatible API | Vendor-specific API | Adapter layer you build |
|---|---|---|---|
| Migration effort | Base URL and model map | Full client rewrite | Ongoing maintenance |
| SDK reuse | Existing OpenAI SDKs work | Vendor SDK required | Custom client |
| Framework support | Frameworks accept base URL | Framework plugin needed | You maintain adapters |
| Error contract | Shared OpenAI error schema | Vendor-specific | You translate |
| Rollback | Reverse the base URL change | Rewrite again | Config switch |
| Feature ceiling | Optional params and new endpoints vary | Vendor's full surface | Lowest common denominator |
Frequently asked questions
What does OpenAI-compatible mean in practice?
The endpoint paths, request bodies, streaming format and response envelopes match OpenAI's /v1 contract, so code written against the OpenAI SDK works after changing the base URL and model name.
Is it truly drop-in?
For the covered surface — chat completions, streaming, function calling, JSON mode, embeddings and errors — yes. Test the optional parameters and endpoints your application actually uses before cutting over.
Which SDKs work with Plugsky?
The OpenAI SDKs for Python, Node, Go, Java and Rust work as-is, and raw HTTP works via the OpenAPI spec. Framework integrations that accept a base URL are also supported.
Will outputs be identical after switching?
No. Compatibility guarantees the interface, not the model weights, so answers differ. Run your own evals to measure quality drift before production cutover.
How do I roll back?
Change the base URL and model name back. Because no application code changed, rollback is a configuration edit rather than a deployment.
What is not compatible on Plugsky yet?
Image generation, audio, moderation, files, batch, fine-tuning and Assistants-style endpoints are documented as coming soon. Chat, streaming, JSON mode, function calling, embeddings, RAG and agents are live.
Does compatibility mean the same pricing?
No. Plugsky self-serve plans are flat monthly with fair-use usage rather than per-token billing, which is often the reason teams evaluate compatibility in the first place.
How do vendor extensions affect portability?
Plugsky-specific features live under /v1/plugsky/*, so the OpenAI-compatible core stays portable. Isolate extension calls behind an adapter if you want a clean exit path.