Which model should triage and which should root-cause crash loops?

Tares lets you run the frequent triage agent on the cheapest model that calls tools reliably and the rare root-cause agent on a stronger hosted or 30B-class model. Each agent has its own provider and model picker, so you choose on each agent’s form. Triage reads a short summary every few minutes, and the root-cause agent only wakes when triage flags an entity.

How it works

Crash loops are handled by two agents linked by a handoff, as described in Watch, then escalate. Their workloads differ, so their models should too.

• Triage is frequent. A schedule trigger wakes it on an interval, for example every 10 minutes, which is 144 runs a day. It reads a summary of the window, not raw lines: the count per label value against the window before, largest change first. If a crash loop shows up in a source you label by service, triage sees it as a value that moved. Most runs end with no finding. A small model reading a summary costs well under a cent a run, so pick the cheapest model on your provider that calls tools reliably.
• Root cause is rare. The main agent has no trigger of its own. It runs only when triage concludes with verdict investigate, at most once per cooldown per entity. It is handed the triage finding, not the logs, so it fetches its own evidence with read, stats and any MCP tools over several rounds. That is where a stronger model pays off.
• Each agent picks on its own form. The agent form has a provider picker next to the model picker. Leave the provider on the default and the agent follows it. Pick one and the agent is pinned to it. If you leave the model empty, the agent runs on that provider’s default model.

Small models are a risk for root-cause work. An 8B-class model on a laptop gives a correct finding on a simple incident, but on an empty result it invents events. For root-cause work on real data, use a hosted model or a 30B-class one and above. Tool calling matters for both agents. A small model can write a tool call as text or answer with nothing. Tares runs a call written as text and flags a run that ends with no conclusion.

Set it up

1. Add the providers you want under Settings → Model providers. An instance can hold several: Anthropic, OpenAI, or an OpenAI-compatible endpoint such as LiteLLM, OpenRouter, Ollama, vLLM or Azure. Saving a provider reads the models it serves, so the picker offers exactly what your key can use. See Model providers.
2. Label the fields you want counted, such as service, on the sources you watch. Put both agents in one project. Add a schedule trigger on those sources, for example watch-web.
3. Create the triage agent on that trigger and seed its prompt from the Triage (on a schedule) preset. Pick the cheap provider and model, and set a budget so the cadence cannot run up a bill.
4. Create the main agent in the same project from the Root cause after a handoff preset. Set its trigger to No trigger: only a handoff starts it, then pick the stronger provider and model.
5. On the triage agent, under When it concludes, add a handoff for investigate to the main agent with cooldown 30m.
6. Raise the daily run limit under Settings → Agents, or with TARES_AGENT_DAILY_CAP. The default is 50 runs per agent per day, and a 10 minute schedule needs 144.

In catalog YAML the fields are provider and model:

agents:
  - name: triage
    trigger: watch-web
    provider: anthropic
    model: ...              # the cheapest model that calls tools reliably
    concludes: true
    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
    provider: anthropic
    model: ...              # a stronger hosted or 30B-class model
    concludes: true
    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

The provider value is the id from Settings: anthropic, openai, or the slug of an endpoint’s name. This pattern sits in front of the alert-driven agent in Build an AI SRE.

What you get

• Most of your runs use the cheap model, because most triage ticks end with no finding and a one-line reason.
• The stronger model runs only after triage flags an entity, at most once per cooldown per entity. With a 30m cooldown that is at most two root-cause runs per hour per entity.
• Every run records the provider and model it ran on, on the agent page and in the runs table. You can compare the two agents’ cost and outcomes.
• The spend meter on the Overview prices each run from the model that answered. Spend is split by provider once more than one has run.
• You can change either model later on that agent’s form, without touching the other agent.

When something else fits

• If you want one model for everything, leave both agents on the cell default provider and an empty model. Tares uses that provider’s default model for each.
• If your triage model is a small local one, such as Ollama, treat it as a way to try things out. Its runs record tokens with no dollar figure, and it may mis-call tools.
• If you need a condition before escalating, such as several investigate findings in a window, wake the main agent with a trigger over findings instead of a handoff.

Related