Each agent in a Farna Control pipeline binds to a model backend - a provider configuration that routes the LLM call to the right provider. A backend wraps a provider (Anthropic, OpenAI, Ollama, or any OpenAI-compatible API) with its own credentials, model selection, and default parameters, so you can pick the right provider for each agent, bind it once, and let Farna Control route at runtime. Without model backends, a pipeline that classifies, drafts, and posts either runs every agent through one provider (paying premium prices for cheap tasks) or splits into separate stacks.

In short

What it does: model backends let you configure LLM providers once and bind agents to them, so each agent in a pipeline can use a different model.
When you would use it: when different tasks need different models - code review with Claude, customer text with GPT-4, classification with a local model.
When you would not: when every agent uses the same model and provider, or when you need a secrets manager. One backend per provider covers variants like Claude Opus and Claude Sonnet; bind agents to the model at the agent level. The backend stores credentials, but its purpose is provider routing, not credential lifecycle.

How it works

Provider configuration

Each backend is configured with a provider, model ID, and credentials. Farna Control supports Anthropic (Claude Opus, Sonnet, Haiku), OpenAI (GPT-4, GPT-4o, GPT-3.5-turbo), Ollama for local models (Llama, Mistral, Phi, and any compatible model), and any OpenAI-compatible API endpoint.

Credentials are encrypted at rest and never enter agent state, logs, or checkpoints. The setup flow generates a one-time URL where you enter the API key directly; the key never passes through the LLM or the Farna Control backend.

Agent binding

Each agent binds to a backend at configuration time:

{
  "name": "classify-ticket",
  "type": "llm",
  "model_backend": "fast-classifier",
  "prompt": "Classify this ticket by urgency..."
}

The model_backend field references a configured backend by name, so you can swap from Claude to GPT-4 by updating one field without changing the agent code.

Health checks and rotation

Farna Control runs periodic health checks against each backend. If a provider is down or rate-limited, the backend is marked unhealthy and a bound run routes to a fallback (if configured) or pauses with a clear error. Rotation distributes requests across multiple backends for the same provider, which helps high-throughput pipelines where a single API key hits rate limits.

Cost tracking

Each backend tracks token usage and cost per run. The analytics dashboard shows which providers consume the most budget, so you can optimize model selection; if a classification agent uses GPT-4 when GPT-3.5-turbo would suffice, the cost data makes that visible.

Journey example: before and after

Before

A team led by Jordan runs every agent through Claude Opus. The monthly bill is $4,000, most of it from classification and summarization agents that do not need the most capable model, but switching to a cheaper one means changing code in 8 pipeline configs.

After

Jordan configures two backends: Claude Opus for code review and drafting, and Claude Haiku for classification and summarization. Each agent binds to the appropriate backend, and the bill drops to $1,200 with no change in output quality: classification accuracy is identical and drafting quality is indistinguishable.

Where it fits in a pipeline

Model backends sit at the agent-configuration layer. For the tool-access layer that connectors provide, see Feature Spotlight: How connectors let you swap tools without changing pipelines. For the governance layer, see Feature Spotlight: How HITL gates stop bad agent output before it ships. For the broader context, see the principles of Farna Control.

Go deeper

Read the Model Backends docs for the full backend configuration, or the related docs on agents and secrets. Take the product tour to see model backends in action, or use the contact page to talk to us about configuring your model backends.