Model Backends
Model backends provide a common interface for routing large language model (LLM) calls across different providers. Each agent in a pipeline selects a model backend by model_backend_id.
Supported backends
A backend’s provider field selects the adapter. These are the shipped provider values.
Hosted providers
provider |
Notes |
|---|---|
anthropic |
Claude models through the Messages API |
openai |
OpenAI models, including the GPT-4o and o-series families |
azure_openai |
Azure OpenAI deployments; requires azure_endpoint and an optional api_version |
bedrock |
AWS Bedrock; requires aws_access_key_id, aws_secret_access_key, and an optional region (default us-east-1) |
vertexai |
Google Vertex AI; requires project and an optional location |
gemini |
Google Gemini API |
mistral |
Mistral |
cohere |
Cohere |
groq |
Groq |
deepseek |
DeepSeek |
grok |
xAI Grok |
qwen |
Alibaba Qwen (DashScope compatible mode) |
ai21 |
AI21 Studio |
fireworks |
Fireworks AI |
togetherai |
Together AI |
openrouter |
OpenRouter |
perplexity |
Perplexity |
opencode |
OpenCode Zen |
watsonx |
IBM watsonx; requires project_id and an optional url |
Self-hosted and gateways
These providers speak the OpenAI-compatible API, so any server that implements it works, including a gateway in front of another provider.
provider |
Default endpoint |
|---|---|
ollama |
http://localhost:11434/v1 |
vllm |
http://localhost:8000/v1 |
tgi |
http://localhost:8080/v1 |
lm_studio |
http://localhost:1234/v1 |
jan |
http://localhost:1337/v1 |
llamacpp |
http://localhost:8080/v1 |
localai |
http://localhost:8080/v1 |
Anthropic
Pipeline config
{
"name": "anthropic-sonnet",
"display_name": "Anthropic Sonnet",
"provider": "anthropic",
"model_id": "claude-sonnet-4-20250514",
"api_key": "sk-ant-...",
"tier": "native"
}
Supports all Claude models via the Messages API. Recommended for structured pipeline tasks and agent reasoning.
OpenAI
Pipeline config
{
"name": "openai-gpt-4o",
"display_name": "OpenAI GPT-4o",
"provider": "openai",
"model_id": "gpt-4o",
"api_key": "sk-proj-...",
"tier": "native"
}
Supports GPT-4o, GPT-4o-mini, o-series reasoning models. Good for code generation and classification tasks.
Local models
Connect to any OpenAI-compatible local endpoint:
Pipeline config
{
"name": "local-ollama",
"display_name": "Local Ollama",
"provider": "ollama",
"model_id": "llama3",
"api_key": "ollama",
"base_url": "http://localhost:11434/v1",
"tier": "native"
}
Works with Ollama, vLLM, TGI, LM Studio, Jan, llama.cpp, LocalAI, and any OpenAI-compatible server.
Endpoint overrides
Every provider in the tables above except azure_openai, bedrock, vertexai, and watsonx accepts a base_url override. The API rejects base_url for those four, because their endpoints are set through provider-specific settings instead. custom has no remote endpoint.
Tiers
tier labels a backend’s support level: native (the default), preview, or in_dev. The list endpoint omits in_dev backends unless the request sets include_in_dev=true.
Test backend (the custom provider)
A deterministic mock backend that returns configurable preset responses. Use it in unit tests and in continuous integration (CI) only, never in production.
There is no standalone stub provider. The test backend registers under the custom provider and is not listed in the UI’s provider dropdown; create it over the API with "provider": "custom" (see Getting Started).
Health checks
Farna Control runs a best-effort test-inference health check when you save a backend and records the result as last_health_check_at and last_health_check_error. The admin status view shows the last result per backend. A backend that has never been checked, or whose last check passed, stays eligible for routing.
Per-agent selection
Each agent stores a model_backend_id, so different agents in the same pipeline can route to different providers. A sandbox_agent node can also name a registry capability class through model_class, which Farna Control resolves to a concrete model when it mints the run snapshot.
Failover
When a model backend is unhealthy, Farna Control automatically fails over to a configured fallback backend. Set fallback_backend_ids on any backend to define the failover order. If the primary and all fallbacks are unhealthy, the run fails with a BackendUnavailableError.
Failover emits a model_failover audit event with the primary and fallback backend IDs for observability.
Related
- Agents: the atomic units that make up a pipeline
- Pipelines: the directed-graph execution model
- Configuration: environment variables and backend setup
- Secrets: how backend API keys are encrypted and handled