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

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.

Self-hosted and gateways
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.

  • 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