Key facts
| API compatibility | OpenAI-shaped /v1/embeddings and /v1/chat/completions (live) |
| Embeddings | plugsky-embed and plugsky-embed-multilingual (live) |
| Answer features | Streaming, JSON mode and function calling (live) |
| Models | 30+ models behind one endpoint, route by article complexity |
| Migration | Base URL and model-name change; re-embed into a new collection |
| Pricing | Flat monthly plans with unlimited fair-use usage on self-serve |
| Residency | Region-locked planes, VPC, on-prem and air-gapped options |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- One compatible endpoint can serve both indexing and answering for your knowledge base.
- Re-embed the corpus when you switch providers — vector spaces do not mix.
- Return JSON with answer, sources and confidence so the UI can render citations.
- Keep filtering and ranking in your code where content rules live.
- Shadow-run against current search before switching employee-facing traffic.
How it works, step by step
- Wrap embedding and chat calls in a thin client so the provider is configuration.
- Create a scoped Plugsky key and set the base URL to https://api.plugsky.com/v1.
- Re-embed all articles with plugsky-embed (or plugsky-embed-multilingual) into a new vector collection.
- Update the answer call to request JSON with fields for answer, sources and confidence.
- Apply product, locale and permission filters before retrieval, exactly as your search does today.
- Run both stacks on real questions and compare citation accuracy and resolution rate.
- Switch traffic by configuration, and monitor usage and error rates for the first week.
Try it yourself
Open the embedding model comparison →
Compatibility for knowledge pipelines
A knowledge assistant has exactly two model-shaped calls: embed content for indexing and generate answers from retrieved passages. Both are OpenAI-shaped on Plugsky and both are live, which means the migration surface for an existing pipeline is a client base URL and a model name.
Adjacent operations remain in your code for now. Files, batch and assistants-style endpoints are coming soon, so keep bulk ingestion, scheduled re-indexing and conversation state in your application rather than waiting on managed equivalents.
Embeddings, retrieval and cited answers
Indexing is a backfill: walk the corpus, chunk by article and section, embed each chunk, and write vectors plus metadata. Answering is a read path: embed the question, filter by product and locale, retrieve top passages, and generate a response constrained to them.
- One model for both sides: always embed queries with the same model that embedded the documents.
- Structured output: JSON mode gives the UI an answer object plus a sources array with IDs and links.
- Refusals: instruct the model to say when the corpus lacks an answer, then surface the nearest articles.
- Freshness: store updated dates so stale articles can be demoted at ranking time.
Operations and rollout
Treat the assistant as a service: separate keys for indexing and answering, usage alerts on both, and logs that record retrieved chunk IDs per request. Because retrieval quality is visible in those logs, relevance complaints can be traced rather than guessed at.
Shadow-run new retrieval and prompts against live traffic and compare citation accuracy, resolution rate and zero-result queries before switching. Residency, if required, applies to the documents carried in prompts: pin the workspace to a region-locked plane or deploy to VPC, on-prem or air-gapped. Keeping provider selection in configuration makes future moves and rollbacks routine deploys.
Honest comparison
| Layer | Plugsky | Staying on OpenAI | Self-hosted models |
|---|---|---|---|
| Client code | Base URL and model names only | No change | New serving stack |
| Embeddings | plugsky-embed and plugsky-embed-multilingual (live) | Existing model | You operate the server |
| Answer format | JSON mode with sources and confidence | Available | Built by you |
| Pricing | Flat monthly with unlimited fair use on self-serve | Per-token | GPU and ops cost |
| Residency | Region choice, VPC, on-prem, air-gapped | Limited options | Wherever you deploy |
Frequently asked questions
Can the same endpoint handle indexing and answering?
Yes. /v1/embeddings handles indexing and /v1/chat/completions handles answers, both in OpenAI format, so one client and one key can serve the whole pipeline.
Why re-embed when switching providers?
Embedding vectors are model-specific. Similarity search only works when documents and queries share a vector space, so backfill a new collection before switching reads.
How do we return citations?
Use JSON mode to require an answer field and a sources array of chunk or article IDs. Your service maps those IDs to titles and canonical URLs.
Where do content rules live?
In your retrieval code: product, locale, permission and freshness filters are applied before passages reach the model. That keeps policy out of prompt wording.
Is streaming available?
Yes, streaming is live on chat completions, so answers render progressively while retrieval happens ahead of the call.
Can this run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment for content that cannot leave your environment.
How should we trial the migration?
Start on the free plan with plugsky-micro and plugsky-lite and no card, shadow-run against real questions, then move to a paid plan or the 14-day full-access trial.