How do you migrate from OpenAI to Plugsky?

Key facts

Chat endpoint	POST https://api.plugsky.com/v1/chat/completions (same shape as OpenAI)
Migration step	Change base_url to https://api.plugsky.com/v1 and map model names
Auth	Authorization: Bearer sk-live-… replaces your OpenAI key
Embeddings	POST /v1/embeddings with plugsky-embed; dimensions differ, so re-index when switching
Live capabilities	Streaming, function calling, JSON mode, structured outputs, vision and embeddings
Coming soon	Responses API, audio, images, moderation, files, batch, fine-tuning and assistants
Models	30+ models; typical starting maps are gpt-4o to plugsky-pro, mini to plugsky-lite, reasoning to plugsky-reasoning
Rollback	The same one-line change in reverse; keep the switch configurable

TL;DR

• The migration is a base URL change plus a model-name map.
• Keep the OpenAI SDK, prompts, streaming code and tools.
• Validate on your evals before switching production traffic.
• Re-index embeddings — dimensions differ between providers.
• Roll back by restoring the old base URL.

How it works, step by step

1. Create a Plugsky account, generate an API key and run one test completion.
2. Copy your existing OpenAI client and point base_url at https://api.plugsky.com/v1.
3. Map each OpenAI model you use to a Plugsky model and record the mapping in config, not code.
4. Run your unit tests and eval set against Plugsky with identical prompts.
5. Check feature parity for the endpoints you depend on — Responses, audio, images, batch and fine-tuning are roadmap items.
6. Send a small share of production traffic and compare latency, quality and failure rates.
7. Complete the cutover and keep the base URL configurable for fast rollback.

Original data

Try it yourself

Open the OpenAI migration checker →

The one-line change

If your code uses the OpenAI SDK, the migration is a constructor change:

# before
from openai import OpenAI
client = OpenAI(api_key="sk-…")

# after
from openai import OpenAI
client = OpenAI(
    api_key="sk-live-…",
    base_url="https://api.plugsky.com/v1",
)

Every subsequent call — chat.completions.create, streaming, tools, response_format, embeddings.create — keeps the same signature. Put the base URL and model names behind environment variables so rollback needs no deploy.

Mapping models without breaking evals

Model ids are the only strings that must change. A practical starting map for common OpenAI models:

• Flagship chat (gpt-4o class): plugsky-pro or plugsky-plus.
• Small and fast (mini class): plugsky-lite or plugsky-micro.
• Reasoning (o-series class): plugsky-reasoning or plugsky-frontier.
• Coding: plugsky-coder or plugsky-coder-fast.
• Long documents: plugsky-longctx.
• Embeddings: plugsky-embed.

Treat these as hypotheses, not equivalences. Run your eval set, inspect failures and adjust the map per workload. Because model selection lives in config, you can route cheap classification to plugsky-micro while keeping complex synthesis on plugsky-pro without touching call sites.

Feature parity before you cut over

Check every endpoint you actually use, not just chat:

• Live today: chat completions, streaming, function calling, JSON mode, structured outputs, vision on supported models and embeddings.
• Coming soon: the responses endpoint, audio, images, moderation, files, batch, fine-tuning and assistants.

Two migration traps are worth calling out. First, embeddings from different providers live in different vector spaces — re-index your store, do not mix old and new vectors. Second, if you use OpenAI's Responses API, refactor to chat completions for now or keep that workload on OpenAI until the Plugsky endpoint ships. The same applies to batch and fine-tuning pipelines.

Rollout and rollback

Ship the migration in stages. Start with a shadow deployment: send a copy of production prompts to Plugsky, log both answers and compare offline. Then move one low-risk endpoint, watch error rates, p95 latency and usage analytics, and expand. Keep the OpenAI client wired behind a flag for at least one release cycle.

Operations are part of the migration, not an afterthought. Errors follow the OpenAI schema; 429 responses include Retry-After; POSTs accept an Idempotency-Key so retries do not duplicate work; request bodies are capped at 16 MB. If you pin a region with PLUGSKY_REGION, document which workloads use it so the residency story stays auditable.

Honest comparison

Capability	Plugsky	Staying on OpenAI	Internal routing gateway
Code change	base_url plus model id	None	Build and maintain routing
Pricing model	Flat monthly self-serve plans with fair use	Per-token	Pass-through per-token
Model choice	30+ models behind one API	OpenAI catalogue only	Whatever you integrate
Residency	Region pin plus VPC, on-prem and air-gapped	OpenAI regions and enterprise options	Depends on each backend
Endpoint parity	Chat, embeddings, vision and tools live; Responses coming soon	Responses, audio, images and batch available	Only what you wire up
Rollback	One-line reverse	Not applicable	Feature-flag routes

Frequently asked questions

How long does the migration take?

For chat-only apps using the OpenAI SDK, the code change is one constructor edit plus a model-name map. Validation on your evals is the part that takes real time.

Do I need to rewrite my prompts?

No. Prompts, streaming consumers, tool definitions and JSON-mode parsers are unchanged because Plugsky uses the same request and response schema.

Which Plugsky model replaces gpt-4o?

There is no exact one-to-one mapping. Teams commonly start with plugsky-pro or plugsky-plus for flagship chat and validate against their own evals before cutting over.

What about embeddings?

Use plugsky-embed on the same /v1/embeddings route. Embedding dimensions differ from OpenAI, so rebuild your vector index instead of mixing providers.

Is the Responses API supported?

Not yet — it is coming soon. Refactor those workloads to /v1/chat/completions or keep them on OpenAI until the endpoint ships.

Can I test before cutting over?

Yes. Use the migration checker and the free plan, which includes two free models and no credit card, then shadow production prompts and compare outputs.

How do rate limits and errors compare?

Errors use the OpenAI schema. Handle 401, 403, 429 with Retry-After, and 413 for bodies over 16 MB. The SDKs retry with exponential backoff.

Can I move back to OpenAI?

Yes. Keep the base URL in configuration and rollback is the same change in reverse.