What is LatentKit?
LatentKit is a route-based AI gateway for teams that want one integration surface and centrally managed provider selection.
LatentKit sits between your application and AI providers. Your code sends standard task payloads; your workspace configures which providers and models each API key uses through published routes.
What LatentKit does
| You want to… | LatentKit gives you | Where |
|---|---|---|
| Swap providers or models without redeploying | Route-based routing | Routes & policies |
| Survive a provider outage | Ordered failover plus health checks | Routes & policies |
| Send different kinds of work to different models | Purposes | Purposes |
| Trade speed against quality per request | Response profiles | Routes & policies |
| Use your own provider keys | BYOK connections | Providers |
| Handle images, audio, embeddings, video | Capability routing | REST API |
| Reproduce a result | Seeded deterministic routing | Determinism |
| Run work asynchronously | Queue endpoint | Queue |
| See spend per app, route, and model | Usage analytics | Console → Usage |
Route-based by design
Application requests do not choose a provider or model. Instead:
- You create an API key in the console.
- The key is assigned a published route (policy).
- Your app sends chat, embedding, or image payloads to
/v1/*. - LatentKit resolves the route and executes against eligible providers.
This keeps application code stable while your team tunes cost, latency, and fallback in the console.
BYOK and Platform Access
Routes can use bring-your-own-key (BYOK) provider connections or Platform Access managed credentials billed through LatentKit credits. The integration shape is identical — only billing and credential ownership differ.
First mental model
Think of LatentKit as three layers:
| Layer | Managed in | What it does |
|---|---|---|
| Application code | Your app | Sends task payloads like messages, input, or prompt |
| API key | Console | Authenticates the app and points to a published route |
| Route | Console | Chooses eligible provider/model attempts, failover, and response depth |
If the route changes, your application code usually does not.
A route usually holds several models. When some jobs want a particular one — extracting data versus drafting prose, say — a purpose lets your application ask for it by a name you chose, still without naming the model itself. Change which model that name means, and your application does not change.
Who this is for
- Product teams shipping AI features without hard-coding provider SDKs per model
- Platform teams that need centralized routing, usage tracking, and key management
- Developers using AI coding tools who want a secure backend integration pattern