Models
Lantern uses capability-based routing — your agent code asks for a capability (e.g. reasoning-large), and the model router maps it to the best concrete model from your configured providers at runtime. You never hardcode a vendor model name in agent code.
Supported providers
Lantern currently supports two LLM providers:
- Anthropic — Claude models (Opus, Sonnet, Haiku)
- OpenAI — GPT models (GPT-4o, GPT-4o-mini, etc.)
Both are supported equally in the model router and in LLM idempotency key derivation. Add a provider key under Settings > Models — the router only considers providers whose key you have configured.
Capability names
Use these capability strings in model fields or capability arguments:
| Capability | Description |
|---|---|
auto | Router picks the best model for each step (cost + quality) |
reasoning-frontier | Highest-capability reasoning (Opus, GPT-o1) |
reasoning-large | Large reasoning model (Sonnet, GPT-4o) |
reasoning-small | Fast, cheap reasoning (Haiku, GPT-4o-mini) |
chat-large | Conversational, large context |
chat-small | Lightweight chat, low latency |
chat-edge | Smallest footprint for edge/embedded use |
vision-large | Image understanding, large context |
vision-small | Lightweight vision |
code-large | Code generation and analysis, large |
code-small | Code generation, lightweight |
embed-large | High-dimensional text embeddings |
embed-small | Fast, lower-dimensional embeddings |
How auto works
With auto, the router scores every available model using a balanced formula (quality, speed, cost efficiency) and picks the winner at call time. It only considers models whose provider API key you have configured, and it respects your LANTERN_ROUTE_STRATEGY setting.
Routing strategies
# Default — best balance of quality, speed, and cost
LANTERN_ROUTE_STRATEGY=balanced
# Cheapest available (e.g., GPT-4o-mini, Haiku)
LANTERN_ROUTE_STRATEGY=cheap
# Highest quality regardless of cost
LANTERN_ROUTE_STRATEGY=quality
# Fastest response time
LANTERN_ROUTE_STRATEGY=fastFailover
The model router handles provider failures automatically:
- 5xx errors — immediate retry on the next provider in the failover chain
- Rate limits (429) — exponential backoff with automatic rotation to an alternative provider
- No mid-sentence swap — failover only happens before the first token; once streaming begins an error is a clean
message_error, never a splice
LLM idempotency
Every LLM provider call carries an idempotency key so that a rate-limit backoff retry or crash-replay does not double-bill. The key is derived from sha256("runID|stepID|attempt") and sent as the Idempotency-Key request header. Failover targets get a per-provider-suffixed variant so the same logical call to two different providers is always distinguishable.
Adding API keys
Add your provider API key from the dashboard under Settings > Models, or via the API:
POST /v1/settings/llm-providers
{ "provider": "anthropic", "apiKey": "sk-ant-..." }
POST /v1/settings/llm-providers
{ "provider": "openai", "apiKey": "sk-..." }Keys are AES-256-GCM encrypted at rest and never appear in logs, traces, or run state. They are resolved inside the microVM at execution time.