Key facts
| Model class | Default general-purpose embedding model in the Plugsky catalogue |
| Best for | RAG, semantic search, clustering and recommendations |
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — set it in your index schema |
| Pricing tier | Available on platform plans; see the live pricing page |
| Capabilities | Batch embeddings, similarity search, clustering — no chat completions |
| Product status | Live |
TL;DR
- The default embedding model for English-dominant RAG and semantic search.
- OpenAI-compatible endpoint means existing embedder code needs one line changed.
- Read the live dimension from /models before creating the vector collection.
- Chunk by structure, store metadata, and pair with keyword search for hybrid retrieval.
- Same-profile fallbacks in the embed family protect long indexing jobs.
How it works, step by step
- Read the live model card at /models for dimension, input limit and status.
- Create the vector collection with that exact dimension.
- Chunk documents into meaningful passages that fit the 8K-class window.
- Embed a sample and test known queries to verify nearest-neighbour quality.
- Benchmark against your current embedding model on the same query set.
- Switch the embeddings call to plugsky-embed and re-index the corpus.
- Record the model name and dimension with the collection, and monitor retrieval quality.
Try it yourself
Open the LLM token calculator →
What plugsky-embed is
plugsky-embed is the default embedding model in the Plugsky catalogue. It turns text into numeric vectors so that passages with similar meaning cluster together, which is the foundation of semantic search, retrieval-augmented generation, deduplication and recommendations. It is served on the OpenAI-compatible /v1/embeddings endpoint, so a RAG stack that already speaks that API changes only the model name.
The vector dimension, input limit and current capability flags live on the catalogue at /models. Treat that page as authoritative — the dimension defines your index schema and cannot be guessed.
When to choose it
Choose plugsky-embed when your content is mostly English or when you are building your first retrieval layer and want a sensible default. It covers the common cases: document Q&A, support knowledge bases, product search, clustering large text sets and finding near-duplicates.
If your users query in one language and your documents are in another, or your corpus is genuinely mixed, use plugsky-embed-multilingual. If your pipeline standardises on NIM-style naming, plugsky-embed-nim serves the same role. Pick one model per collection and keep it fixed.
Dimensions, RAG design and trade-offs
Most retrieval failures come from pipeline choices, not the embedding model. Fix these before tuning anything else.
- Match the collection dimension to the live model card exactly.
- Chunk by structure: headings, paragraphs and code blocks, not arbitrary character counts.
- Store source metadata with every vector so answers can cite documents.
- Add keyword search for identifiers, error codes and rare terms.
- Plan re-indexing as a background job for whenever the embedding model changes.
How to switch to plugsky-embed
The call is a single model name, for example {"model": "plugsky-embed", "input": ["first passage", "second passage"]} posted to https://api.plugsky.com/v1/embeddings.
Index into a new collection, validate with a labelled query set, then cut the application over. Keep the previous collection until the new one matches or beats it, and document the model and dimension in your schema so the next migration is routine.
Honest comparison
| Dimension | plugsky-embed | plugsky-embed-multilingual | Self-hosted embeddings |
|---|---|---|---|
| Best fit | English-dominant RAG and semantic search | Mixed-language and Arabic plus English | Offline or fully controlled indexing |
| Endpoint | OpenAI-compatible /v1/embeddings | OpenAI-compatible /v1/embeddings | You run the inference server |
| Dimension | Read the live value at /models | Read the live value at /models | Chosen from the weights |
| Input limit | 8K-class text | 8K-class text | Depends on the weights |
| Ops overhead | None | None | GPU capacity, scaling, upgrades |
| Failover | Automatic peer fallback in the embed family | Automatic peer fallback | You design it |
Frequently asked questions
Is plugsky-embed free?
Embeddings are part of platform plans. The free plan includes two free chat models, plugsky-micro and plugsky-lite. See the live pricing page for plan and trial details.
What is the output dimension?
The live dimension is published per model at /models. Read it there and use the exact value when creating the vector collection.
Can I use it for a chatbot?
Yes, as the retrieval half. Embed documents, search for relevant passages, then pass them to a chat model such as plugsky-pro to generate the answer.
What input size does it accept?
An 8K-class window of text per request. Check /models for the current limit and chunk documents so each passage fits with context.
Do embeddings cost extra per token?
Self-serve plans are flat monthly with fair-use usage rather than per-token billing. See the live pricing page for current plan details.
Should I switch embedding models often?
No. Switch only for a reason — better quality, a language need or a dimension change — and re-index the whole corpus when you do.
Does it work with pgvector and other vector stores?
Yes. It returns plain numeric vectors, so any vector store works; just set the collection dimension to match.
What happens if the embedding endpoint has an incident?
Requests fall back to same-profile peers in the embed family automatically. Live health is shown on the status page.