Key facts
| Code change | Base URL plus model-name mapping |
| SDK | Keep your existing OpenAI client library |
| Compatible now | Chat, streaming, JSON mode, function calling, embeddings |
| Coming soon | Files, batch, audio, images, assistants, responses |
| Free tier | 2 free AI models (plugsky-micro, plugsky-lite), no card |
| Trial | 14-day full-access trial available |
| Pricing model | Flat monthly self-serve with unlimited fair-use usage |
| Product status | Live |
TL;DR
- Change the base URL and model names — keep the rest of your code.
- Chat, streaming, JSON mode, tools and embeddings are live today.
- Plan around coming-soon endpoints before moving those workloads.
- Re-run evals: compatible APIs still produce different outputs.
- Roll out behind a flag so rollback is a configuration change.
How it works, step by step
- Create a Plugsky API key on the free plan — no card required.
- Introduce a provider switch in configuration rather than editing call sites.
- Point the OpenAI client at the Plugsky base URL and map each model name.
- Run your test suite and evaluation set on the same prompts and compare results.
- Shadow production traffic, then shift a percentage and monitor latency and errors.
- Complete the cutover and keep the old base URL available for one release cycle.
Try it yourself
Open the OpenAI migration checker →
The five-line migration
For chat-based applications the change is configuration. In a typical Python client you set base_url to the Plugsky endpoint and keep the same API-key pattern; in Node the same idea applies to the client constructor. Then map model names: replace an OpenAI model string with a Plugsky model such as plugsky-coder or a free-tier alias. Everything downstream — message arrays, streaming handlers, JSON mode, tool schemas — stays as written. Embeddings work the same way through /v1/embeddings. The quickstart shows the exact snippets per language.
Where migration takes real work
Configuration is easy; quality assurance is the actual project:
- Model mapping: decide which Plugsky model replaces each OpenAI model, including fallbacks.
- Prompt tuning: prompts are portable but not always optimal; small adjustments often recover quality.
- Tokenizer differences: context limits and token accounting vary, so check truncation logic.
- Endpoint gaps: files, batch, audio, images, assistants and responses are coming soon — keep a secondary provider for those until they land.
- Observability: make sure your logs, cost dashboards and alerts understand the new provider.
Run the same evaluation set you use today. That is the only reliable signal that parity holds.
What we do and what we do not do
What we do: keep the API OpenAI-compatible, document the capability matrix honestly, and price self-serve plans flat monthly with unlimited fair-use usage so post-migration costs stay predictable. What we do not do: promise byte-identical model output, provide OpenAI-specific endpoints before they are live, or hide migration effort behind a marketing claim — chat-shaped workloads move fast, assistant- and batch-shaped workloads wait for the roadmap. Read the terms and the docs before you commit a production timeline.
Honest comparison
| Step | Plugsky | Typical OpenAI-compatible provider | Rewrite to another API |
|---|---|---|---|
| Base URL change | Yes | Yes | Not applicable |
| SDK change | Keep the OpenAI SDK | Usually keep | New SDK |
| Model mapping | Name swap | Name swap | Full remap |
| Batch and files | Coming soon | Often available | Varies |
| Evaluation work | Re-run evals | Re-run evals | Build new evals |
| Rollback | One config value | One config value | Significant work |
Frequently asked questions
Do I need to rewrite my application?
No, for chat-based workloads. Change the base URL and model names; SDK calls, message arrays, streaming handlers and tool schemas stay the same.
Which OpenAI endpoints are compatible today?
Chat completions, streaming, JSON mode, function calling and embeddings are live. Files, batch, audio, images, assistants and responses are coming soon.
Will my prompts produce the same output?
Not identically — models differ. Expect to re-run evals and make small prompt adjustments. Compatibility is about the interface, not bit-identical generations.
Can I migrate gradually?
Yes, and you should: introduce a provider switch, shadow traffic, then shift a percentage before completing cutover. Rollback stays a configuration change.
How do I handle model names in code?
Keep model names in configuration, not scattered through the codebase. That makes both the migration and future model swaps trivial.
What does it cost to try?
The free plan includes two models with no card, and the 14-day full-access trial covers stronger models. Self-serve plans are flat monthly — see the live pricing page.
Who should not migrate yet?
Teams whose core workflow depends on batch, files, audio, images or the Assistants API should wait for those endpoints or run a split-provider setup.