Which model should triage and which should root-cause error spikes?

Tares lets you pick a model per agent, so run the frequent triage agent on the cheapest model that calls tools reliably and the rare root-cause agent on a stronger hosted model. Each agent has its own provider and model pickers on its form. Triage reads a short summary of the window and usually says “normal”, so it needs little. The root-cause agent gathers its own evidence over several tool rounds, so give it your best model.

How it works

The Watch, then escalate pattern splits error-spike work into two agents linked by a handoff. Each one has a different job, so each gets a different model.

• Triage agent. A schedule trigger wakes it every interval, for example 10 minutes. It receives a summary of the window instead of raw lines. For each label you name, such as service and status_code, the summary shows the count per value against the window before, largest change first, plus a few recent lines. The agent ends every run with no_op or with a finding that carries the verdict investigate. This is a narrow, repetitive judgment, so a cheap model fits. The one requirement is reliable tool calling, because the run ends with the conclude tool.
• Root-cause agent. It has no trigger of its own. A handoff from triage on the same entity starts it. It is handed the triage finding, not the logs, so it fetches evidence with read, stats and any MCP tools you give it, then writes its note with conclude. That is a multi-round loop over real data, so use a stronger model.

The model-providers page describes why this matters at the small end. In the agent loop a small model sometimes writes a tool call as JSON text, mis-cases a tool name or answers with nothing. Tares runs a call written as text, matches a mis-cased name and flags a run that ends with no conclusion and no tool call. An 8B-class model on a laptop can produce a correct finding on a simple incident, but on an empty result it will invent events. For root-cause work on real data, use a hosted model or a 30B-class one and above.

An instance can hold several providers. You choose the provider and the model on each agent’s form, so the cheap model and the strong model can even come from different vendors.

Set it up

1. Open Settings → Model providers and add the providers you want: Anthropic, OpenAI, or an OpenAI-compatible endpoint such as LiteLLM, OpenRouter, Ollama or vLLM. Saving a provider asks the endpoint which models it serves, so the agent form offers exactly what your key can use. Details are on the Model providers page.
2. Create the triage agent on a schedule trigger over your error sources, and seed its prompt from the Triage (on a schedule) preset. In its form, pick the provider and the cheapest model that calls tools reliably. Set a budget so the cadence cannot run up a bill.
3. Create the root-cause agent in the same project with the trigger No trigger: only a handoff starts it, and seed its prompt from Root cause after a handoff. In its form, pick a stronger provider and model.
4. On the triage agent, under When it concludes, add a handoff for the verdict investigate to the root-cause agent with a cooldown of 30m.
5. Raise the daily run limit. At 10 minutes the triage agent runs 144 times a day, above the default of 50 runs per agent per day. Change it under Settings → Agents or with TARES_AGENT_DAILY_CAP.

In catalog YAML the per-agent fields are provider and model. The provider is the id from Settings, such as anthropic or openai, or the slug of an endpoint’s name:

agents:
  - name: triage
    trigger: watch-web
    concludes: true
    provider: openai
    model: <cheapest model your key lists>
    verdicts:
      - { verdict: investigate, when: one entity looks like a problem and needs a closer look }
    prompt: ...             # from the Triage (on a schedule) preset
    handoffs:
      - { verdict: investigate, agent: rca, cooldown: 30m }
  - name: rca               # no trigger: it runs only when handed off
    concludes: true
    provider: anthropic
    model: <your strongest model>
    verdicts:
      - { verdict: rca, when: you found what is failing and why }
      - { verdict: resolved, when: it was noise, or it is already over }
    prompt: ...             # from the Root cause after a handoff preset

If you leave the model empty, the agent runs on its provider’s default model. If you leave the provider on the cell default, it follows whatever default the instance holds.

What you get

• A low, predictable bill. A small model reading a summary costs well under a cent a run, and the strong model runs only when triage flags something, at most once per cooldown per entity.
• Better root causes where they count. The model that digs through evidence is the one you chose for that work.
• A readable history. Every run records the provider and model it ran on, on the agent page and in the runs table, so you can compare triage verdicts against root-cause notes per model.
• Visible spend. The Overview prices each run from the model that answered and splits spend by provider once more than one has run. A model with no price, such as a local Ollama model, records tokens and is counted as unpriced rather than shown as zero.
• One thread per spike. The tick, the triage finding and the root cause show together on the entity’s timeline.

When something else fits

• If one model is all you have, leave both agents on the default provider. The split is a cost choice, not a requirement.
• If your spikes are already caught by alert rules, an alert-driven agent from AI SRE may fit better than a scheduled triage agent.
• If you want to try things out on a laptop, a small local model is fine for triage experiments, but keep root-cause work on a hosted or 30B-class model.

Related