Core Concepts
Routes, API keys, capabilities, and how LatentKit resolves provider execution.
API keys
Each API key belongs to one workspace and one key identity. The key's assigned published route determines provider/model selection for every /v1/* request.
Routes and policies
Operators build routes (routing policies) in the console: ordered provider/model attempts, capability filters, budgets, and optional request overrides. Publishing a route makes it available for assignment to API keys.
Your application never references route IDs directly — assignment happens in the console.
Capabilities
Endpoints map to capabilities such as text, embeddings, image_generation, and vision. The route's model catalog and provider support must include an eligible model for the requested capability.
Common public endpoints:
| Endpoint | Capability |
|---|---|
POST /v1/chat | Text / chat |
POST /v1/embeddings | Embeddings |
POST /v1/image | Image generation |
POST /v1/vision | Vision |
Failover
When the first route attempt fails with a retryable provider error, LatentKit tries the next eligible route in the published policy. The client still receives one response.
Response profiles
response_profile (fast, balanced, deep) lets applications request a speed/depth tradeoff when the assigned route allows overrides. If overrides are disabled, the route default applies.
Credits and BYOK
- Platform Access routes consume LatentKit credits (or trial allowance on Free plans).
- BYOK routes use your provider credentials; LatentKit does not bill model usage for those requests.
Playground and console testing
Use AI Router or Playground in the console to validate key, route, provider, and billing state before debugging application code. Public docs show the contract; console tools know your workspace state.