Key facts
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Models | plugsky-embed, plugsky-embed-multilingual and plugsky-embed-nim in a 30+ model catalogue |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — read it before creating a collection |
| Use cases | RAG, semantic search, clustering and recommendations |
| Indexing | Batch embeddings for large corpora; re-embed when the model version changes |
| MVP path | Build chat on free models, add embeddings on a plan |
| Simplicity | One OpenAI-compatible API for chat and embeddings |
TL;DR
- OpenAI-compatible /v1/embeddings with the plugsky-embed family in a 30+ model catalogue.
- Dimension is published per model — read it before creating the collection.
- Ship retrieval on one API and keep the model behind configuration.
- Avoid dimension lock-in that makes a later model switch expensive.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Read the model's live vector dimension from the catalogue and create the collection with it.
- Chunk by document structure, embed in batches, and store metadata for citations.
- Validate retrieval on a labelled question set before moving to production traffic.
- Build chat on the free plan with plugsky-micro and plugsky-lite.
- Add a structure-aware embedding pipeline and log retrieval metadata.
- Re-evaluate the model once usage patterns are known.
Original data
Try it yourself
Open the RAG chunk size calculator →
Embeddings for startups: what changes
Startups use embeddings to make an MVP feel intelligent: search, related items, RAG answers. The fastest path is one OpenAI-compatible API for chat and embeddings, minimal infrastructure, and a model choice you can change later without rewriting the product.
Plugsky exposes an OpenAI-compatible /v1/embeddings endpoint with the plugsky-embed family inside a 30+ model catalogue: plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages such as Arabic and English, and plugsky-embed-nim for teams standardised on NVIDIA-style profiles. Inputs are 8K-class per request, and each model's vector dimension is published on the model catalogue — read it before you create the collection.
Architecture and controls
Start with the default English model, structure-aware chunking and a simple vector store, and keep model choice in configuration. Use scoped keys per environment and log enough metadata to evaluate retrieval quality.
Integration pattern and rollout
Build the free-tier integration with plugsky-micro or plugsky-lite for chat, then add embeddings when retrieval is on the roadmap and move to a plan for the workload. Read the live dimension from the catalogue before creating the collection.
Treat the dimension as a schema contract. When you change embedding models the vectors change, so plan a new collection and a backfill rather than an in-place swap. Chunk by document structure, store metadata alongside vectors, and combine vector similarity with keyword search and a reranker for production retrieval. Batch indexing jobs and re-embed only when the model version or chunking strategy changes.
Limits, evidence and cost
Do not over-invest before product-market fit: the store, chunking and model will all change. Avoid locking in a dimension or vendor-specific feature that makes a later model switch expensive.
Embeddings are available on platform plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card to build the application layer, then add the indexing workload when retrieval is on the roadmap. The 14-day full-access trial covers larger models.
Honest comparison
| Concern | Plugsky embeddings | Typical API provider | Self-hosted embedder |
|---|---|---|---|
| API shape | OpenAI-compatible /v1/embeddings | Usually compatible, varies | Custom serving stack |
| Model choice | plugsky-embed family inside a 30+ model catalogue | Provider catalogue only | You package each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Dimension changes | Read live dimension from /models; plan new collections | Varies by provider | You manage every migration |
| Operational load | Managed endpoint with batching | Managed endpoint | GPU capacity, patching and autoscaling |
| MVP path | Free chat models now, embeddings on a plan | Free tiers vary | Premature infrastructure spend |
Frequently asked questions
Do we need to re-embed when we change models?
Yes. Vectors depend on the model and dimensions can change. Plan a new collection, backfill, validate, then cut over — re-embedding is a data migration, not a config flip.
Are embeddings region-locked?
Yes, when the workload is pinned to a region-locked plane. Keep the vector store, backups and logs in the same jurisdiction as the source data.
Which embedding model should we start with?
plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages, and plugsky-embed-nim for NVIDIA-style profiles. Evaluate on your own content.
What is the fastest way to ship search?
Use one OpenAI-compatible API for chat and embeddings, start with the default model and structure-aware chunking, and keep model choice in configuration.
Can we start on the free plan?
Yes — the free plan includes plugsky-micro and plugsky-lite with no card. Add the embedding workload on a plan when retrieval is on the roadmap; check the live pricing page.
What should we avoid early?
Avoid binding to a specific dimension or vendor-only feature that makes a later model switch expensive.