Which model should triage and which should root-cause 5xx errors on an API?

Tares lets you pick a model per agent: use the cheapest model that calls tools reliably for the frequent triage agent, and a hosted or 30B-class-and-above model for the rare root-cause agent. Each agent has its own provider and model picker, so the two choices are independent. Triage runs on a schedule and reads a summary of your 5xx counts, and the root-cause agent runs only when triage flags a service.

How it works

The Watch, then escalate pattern splits the work into two agents with different jobs, so each gets its own model.

• Triage agent. A schedule trigger fires every interval and hands the agent a summary instead of raw lines. For each label you name, such as service and status_code, it shows the count per value in this window against the window before, largest change first. The agent ends every run with no_op or with a finding carrying the verdict investigate. At a 10 minute interval that is 144 runs a day, so a cheap model matters here.
• Root-cause agent. It has no trigger of its own. A handoff on the investigate verdict starts it on the same entity, for example service=checkout. It receives the triage finding, not the logs, and fetches its own evidence with read, stats and any MCP tools you give it over several rounds. With a cooldown of 30m it runs at most twice per hour per entity.

The agent form has a provider picker next to a model picker. Pick a provider and the agent is pinned to it. Leave the model empty and it runs on that provider’s default model.

Selection criteria follow each agent’s form:

• Triage: the cheapest model on your provider that calls tools reliably. A small model reading a summary costs well under a cent a run.
• Root cause: a hosted model or a 30B-class one and above for work on real data. An 8B-class model on a laptop (llama3.1:8b on Ollama) finds a simple incident in about twelve seconds, but on an empty result it invents events. Use that size to try things out.

Set it up

1. Add your providers under Settings → Model providers. Tares supports Anthropic, OpenAI, and any OpenAI-compatible endpoint such as LiteLLM, OpenRouter, Ollama or vLLM. Saving a provider reads the models it serves, so each agent form offers exactly what your key can use. If you serve both models through one router, one provider entry is enough. See Model providers.
2. Put both agents in one project. Label the fields you want counted, such as service and status_code, on your request log source, then add a schedule trigger:

triggers:
  - name: watch-web
    sources: [web_logs]
    key_field: service
    condition:
      every: 10m                          # at least 1m
      summary_by: [service, status_code]  # labels to count; default: the trigger's key field

3. Create the triage agent on watch-web and seed its prompt from the Triage (on a schedule) preset. In the form, pick the provider and the cheapest model that calls tools reliably. Set a budget. Raise the daily limit under Settings → Agents, because 144 runs a day is above the default of 50 runs per agent per day.
4. Create the root-cause agent in the same project from the Root cause after a handoff preset, set its trigger to No trigger: only a handoff starts it, and pick the stronger model in its form.
5. On the triage agent, under When it concludes, add a handoff for investigate to the root-cause agent with cooldown 30m. In the catalog, the provider and model fields pin each agent:

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 }
    handoffs:
      - { verdict: investigate, agent: rca, cooldown: 30m }
  - name: rca               # no trigger: it runs only when handed off
    provider: openai
    model: ...              # a hosted or 30B-class and above model
    concludes: true

6. Open the runs table and check that each run shows the provider and model it ran on. Triage runs should be mostly “no finding” rows with a one-line reason.

What you get

• A triage agent that runs often and costs little, because it reads a summary page of your 5xx counts rather than tens of thousands of lines.
• A root-cause agent that runs only when triage flags a service, on a model strong enough for multi-round tool use.
• Every run records its provider and model, so you can compare what each model did and swap one without touching the other.
• A spend meter on the Overview that prices each run from the model that answered, split by provider once more than one has run. A model with no price, such as a local Ollama model, records tokens with no dollar figure.
• One card under What the agents found for the whole chain: the tick, the triage finding and the root cause, in order.

If a small model writes a tool call as JSON text, Tares runs it. If a run ends with no conclusion and no tool call, Tares marks it with a note to check that the model supports tool calling. That note is your cue to move triage to a different cheap model.

When something else fits

• If you run one provider and want one model for everything, leave the agents on the default provider and skip the per-agent pick. Ask and the guided setup use that default too.
• If a rule already says what a 5xx problem looks like, an alert-driven agent fits better. See AI SRE.
• If you need a condition before escalating, such as several investigate findings in a window, wake the root-cause agent with a trigger over findings instead of a handoff. Use one link or the other, not both.

Related