Models & Providers

Overview

ArchAgents is provider-neutral. The platform talks to multiple LLM providers natively and routes every model call through one consistent interface. You pick the right model for the job, and the platform handles the provider-specific differences underneath.

This matters in three concrete places:

• An agent's primary model: the model the agent uses when it reasons, replies, and calls tools.
• An LLMJudge field guard's model: the model that grades a structured response against a policy. See Field Guards.
• Cross-vendor verification: stack two judges using different vendors so a prompt injection that exploits one model's quirks still has to defeat the other. See Stacking judges across vendors.

The same model string format works in every place models are configured.

---

Supported providers

Provider	Prefix	What it gives you
Anthropic	anthropic/	Claude models called directly against Anthropic's API
OpenAI	openai/	GPT models called directly against OpenAI's API
Google Gemini	google/	Gemini models called directly against Google's API
OpenRouter	openrouter/	300+ models from many vendors through a single OpenRouter account, including Anthropic, OpenAI, Google, and others

Direct provider integrations are useful when you have a relationship with a specific vendor or want to use vendor-specific features. OpenRouter is useful when you want one billing relationship that covers many models, or when you want to try a model that doesn't have a direct integration.

---

Model strings

Every place that takes a model accepts a <provider>/<model> string.

# Direct provider format
model: anthropic/<model-name>
model: openai/<model-name>
model: google/<model-name>

# Through OpenRouter (always three segments)
model: openrouter/<vendor>/<model-name>

The format is the same regardless of where you configure it: the LLM judge, the agent's primary model, or any future surface that takes a model. Use the discovery flow below to fill in the exact <model-name> for the provider you want.

---

Finding the model string you need

The model catalogue changes frequently as providers ship new models and the platform adds direct integrations. Rather than copying a hand-maintained list out of the docs, use the CLI to discover currently valid model strings:

archagent create agent --help
archagent update agent --help

Both commands' --model flag help text points at the supported-models endpoint as the source of truth for the current catalogue. The strings the platform accepts always follow the <provider>/<model> shape: anthropic/..., openai/..., google/..., or openrouter/<vendor>/<model> for OpenRouter's broader catalogue.

Once you have a valid model string, drop it into a model: field anywhere it's accepted (LLMJudge field guards, agent creation, etc.).

---

Where you can set the model

On a field guard (LLMJudge)

Override the judge model on a per-guard basis:

field_guards:
 - kind: LLMJudge
 fields: ["summary"]
 model: anthropic/<model-name>
 prompt: >
 Does this text reveal internal infrastructure details?
 on_match: reject

Leave model unset to use the platform's default judge model. See Field Guards for the full guard model.

On an agent

Set the agent's primary model when you create or update the agent with the -m, --model flag:

# Create with a specific model
archagent create agent -n "Support Agent" -k support-agent \
 -i "You are a helpful support agent." \
 -m anthropic/<model-name>

# Update an existing agent's model
archagent update agent <agent_id> --model openai/<model-name>

Run archagent create agent --help or archagent update agent --help to see the full flag set and the source-of-truth pointer for currently valid model strings.

Platform default

If you don't set a model on either the agent or the judge, the platform uses a sensible default. You don't need to think about model selection until you have a reason to override. Start with the default and pick a specific model when capability, latency, or vendor diversity actually matter.

---

Cross-vendor verification

The strongest reason to care about which model runs where is the cross-vendor verification pattern: stack two LLMJudge field guards on the same field, with one using anthropic/... and the other using openai/... (or any two different vendors).

field_guards:
 - kind: LLMJudge
 fields: ["summary"]
 model: anthropic/<model-name>
 prompt: <your policy>
 on_match: reject

 - kind: LLMJudge
 fields: ["summary"]
 model: openai/<model-name>
 prompt: <your policy>
 on_match: reject

Both judges run. Both must pass. A prompt injection that exploits one model's quirks still has to defeat a model with completely different training data and different blind spots. This is the single most defensible field-guard pattern. See Stacking judges across vendors for the full explanation and the trade-offs.

---

Choosing a model

The right model depends on the work, not on which one is newest. A few practical guides:

• For conversational agent replies: pick a strong general-purpose model from any vendor. Latency matters because the user is waiting.
• For deterministic structured-output policies in an LLM judge: pick a fast model with strong instruction-following. The judge is asked one yes/no question; you don't need the largest model on the menu.
• For cross-vendor judge stacking: pick two models from different vendors regardless of relative capability. The diversity is the defense, not the individual capability of either model.
• For long-context work: context window varies a lot within a single vendor's lineup. Pick the model that gives you the headroom you need; the CLI's --model help text points at the supported-models endpoint when you want the current window for a specific string.
• For tools that depend on a vendor-specific capability: pick the vendor that supports it. Some models have native search; some have native thinking; some have native image output.

When in doubt, leave the platform default in place and override only the model where you have a concrete reason.

---

Where to go next

1. Field Guards: where the LLM judge model is configured.
2. Cross-Company Privacy: the broader defense-in-depth model that cross-vendor verification fits into.
3. Agents: the agent model that uses the primary model.