Key facts
| Base URL | Change to https://plugsky.com/v1 |
| Env variable | OPENAI_API_BASE and OPENAI_API_KEY work |
| Code changes | None beyond base URL and model name for chat, tools and embeddings |
| Models | 30+ Plugsky models; choose by workload, not brand mapping |
| Testing | Run existing evals before cutover |
| Rollback | Revert the base URL — the wire format stays compatible |
| Free plan | plugsky-micro and plugsky-lite, no card required |
| Product status | Live |
TL;DR
- Keep the OpenAI SDK — the migration is a one-line base URL change.
- Map models by workload tier and confirm names on the live catalogue.
- Run your prompt evals unchanged to validate parity.
- Roll back by restoring the old base URL.
- Test on the free plan before moving production traffic.
How it works, step by step
- Create a Plugsky API key in the dashboard.
- Set the base URL to https://plugsky.com/v1 in your client or environment.
- Map model names to Plugsky models by capability tier.
- Run your existing eval suite against the new endpoint.
- Compare latency, quality and behaviour on streaming and tools.
- Cut over traffic gradually and keep the old base URL for rollback.
Try it yourself
Open the OpenAI migration checker →
The one-line change
Because Plugsky exposes an OpenAI-compatible endpoint, the core migration is configuration, not code. Point base_url at https://plugsky.com/v1 and supply a Plugsky key. The SDKs for Python, Node, Go, Java and .NET all accept a custom endpoint, and setting OPENAI_API_BASE plus OPENAI_API_KEY handles tools that only read environment variables. Streaming, tool calling, JSON mode and embeddings keep their OpenAI shapes.
Mapping endpoints and models
Endpoint mapping is trivial for chat completions, embeddings and function calling because the paths and payloads are identical. Model mapping needs care: use your workload tier rather than a brand-to-brand guess. GPT-4o-class traffic is a reasonable starting point for plugsky-pro or plugsky-frontier; lighter traffic starts at plugsky-lite or plugsky-micro on the free plan. Confirm current names and capabilities on the live model catalogue, then validate with your own prompts.
One caveat to plan around: legacy /v1/completions and the stateful /v1/responses endpoint are listed as coming soon. Chat completions is the supported production path.
Testing before cutover
Run the eval suite you already trust before changing any production traffic. Score the same prompts on both providers, check JSON validity where you rely on structured output, and measure p50 and p95 latency for your real request mix. Tool-calling flows deserve their own tests: verify argument schemas are respected and that parallel calls behave as your application expects.
Shadow traffic is the lowest-risk cutover. Mirror a percentage of live requests to Plugsky, compare outputs and errors, then shift the share up as confidence grows.
Rolling back and avoiding lock-in
If quality or latency regresses, restore the previous base URL — nothing else changes. That reversibility is the point of choosing an OpenAI-compatible provider: you gain pricing and deployment options without betting the roadmap on a single vendor. Keep your prompts and tool schemas provider-neutral, avoid features that exist on only one platform, and document which model each workload uses so future switches stay mechanical.
Honest comparison
| Step | Plugsky migration | Typical proprietary alternative | Staying on OpenAI |
|---|---|---|---|
| Code change | Base URL and model name | New SDK and request shapes | None |
| Streaming and tools | Unchanged shapes | Often reimplemented | Unchanged |
| Model choice | 30+ models, one endpoint | Vendor catalogue | Vendor catalogue |
| Testing | Run existing evals | Rewrite tests | No change |
| Rollback | Revert base URL | Substantial rework | Not applicable |
| Cost control | Flat self-serve plans with unlimited fair use | Often per-token | Per-token |
Frequently asked questions
Do I need to rewrite my code?
No. For chat completions, embeddings and function calling you change the base URL and model name; the request and response shapes are OpenAI-compatible.
Can I use environment variables instead of editing code?
Yes. Set OPENAI_API_BASE to the Plugsky endpoint and OPENAI_API_KEY to a Plugsky key for tools that read those variables.
How should I map OpenAI models to Plugsky models?
Map by workload tier — start with plugsky-pro or plugsky-frontier for GPT-4o-class traffic and plugsky-lite or plugsky-micro for lightweight traffic — then validate on your own evals.
Can I migrate embeddings too?
Yes. The embeddings endpoint is OpenAI-compatible, and the RAG API can manage chunking and retrieval if you prefer not to run your own vector store.
How do I test without committing?
Use the free plan to run evals and a shadow-traffic cutover before moving production. Every account also starts with a 14-day full-access trial.
What is not available yet?
Legacy /v1/completions, stateful /v1/responses and the specialist audio, image and fine-tuning endpoints are labelled coming soon in the docs; check before migrating those workloads.
How do I roll back?
Restore your original base URL and model names. The compatibility layer means there is no data migration to reverse.
Plugsky (2026). “OpenAI Migration — Switch to Plugsky in One Line”. Plugsky. Available at: https://plugsky.com/articles/openai-migration (last updated 2026-09-25).