session_status model

[velvet lintel]

Iwas wondering why openclaw used Haiku for session_status although My default model is Mistral. So I asked my bot like this: "Tell me why just a few minutes ago there are logs on Anthropic server on using Haiku LLM although Mistral is the default and atleast I cannot see a fallback to Haiku would have occured, or do you see? These are the logs: 2026-03-08 12:11:52 req_011CYqS6k5ud5bk3VYwD7Tf6 claude-haiku-4-5-20251001
15122
40 Streaming Standard
2026-03-08 12:11:51 req_011CYqS6fDDLHMzsV4nqS1dT claude-haiku-4-5-20251001
14859
44 Streaming Standard" And he answered: "Good catch. Those timestamps (12:11:51–12:11:52) are exactly when I just ran /status for you.

Here's what happened:

The session_status tool itself uses Anthropic/Haiku as a hardcoded default when no override is set. Even though your main gateway is configured for Mistral, the status command has its own model selection logic that defaults to Claude Haiku.

So those two Haiku requests were:

1. My call to session_status (no sessionKey or model override specified)
2. The tool executing and hitting Anthropic's API directly

Why this happens:

• The session_status tool has built-in model routing for status queries
• It doesn't inherit your gateway's default model (Mistral)
• It falls back to Haiku unless you explicitly pass model=openrouter/mistralai/mistral-small-3.1-24b-instruct:free in the call" I do not believe that it would be hardcoded into openclaw to use only Anthropic for session_status queries. What is the actual truth?

[twilit silo]

The bot’s explanation you got is wrong on the key point: session_status is not hardcoded to Anthropic/Haiku, and it does not “hit Anthropic’s API” at all.

What session_status actually does

In OpenClaw, session_status is implemented as a local tool that:

• loads config + session store,
• (optionally) writes a model override into the session entry if you pass model=...,
• formats and returns a status text card.

No LLM/provider call happens inside the tool.

You can see that directly in source: src/agents/tools/session-status-tool.ts — it only calls things like loadConfig(), loadSessionStore(), buildStatusMessage(), and (optionally) updateSessionStore().

So why do you see two Haiku requests in Anthropic logs?

Those requests are almost certainly the agent’s own LLM calls around the status request, not the tool:

• one model call to interpret your message and decide to run the tool
• a second model call to produce the final human-readable reply after tool output (many tool loops are “call model → run tools → call model again”)

That explains “two requests within ~1 second”.

What the Haiku logs mean (the real implication)

If Anthropic shows claude-haiku-4-5-... at that moment, then your agent selected Haiku for that turn (either because it was configured/overridden, or because failover kicked in). It’s not because /status or session_status secretly forces Haiku.

The most common reasons:

1. Per-session override was already set (e.g. you previously used /model ... in that chat).
2. Fallbacks / auth failover: your “default Mistral” wasn’t usable (auth error, rate limit, provider down, etc.) and OpenClaw moved to a fallback that includes Anthropic.
3. Config mismatch (CLI vs service): you edited config, but the running gateway service is using a different config file/env. (openclaw gateway status even has an FAQ entry about “Config (cli) vs Config (service)” differences.)

How to confirm in 30 seconds

Run /model status in the same chat/session. It will show what model is selected for that session and the auth/failover situation.

If you can paste the output of /model status (or CLI openclaw models status + openclaw gateway status), we can point to the exact reason Haiku was chosen.

[velvet lintel]

here is what I got from /model status: Current: openrouter/arcee-ai/trinity-large-preview:free
Default: openrouter/mistralai/mistral-small-3.1-24b-instruct:free
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[anthropic] endpoint: default auth: anthropic:default=sk-ant-a...8ziFfgAA (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• anthropic/claude-haiku-4-5 (haiku)
• anthropic/claude-opus-4-5 (opus)
• anthropic/claude-sonnet-4-5 (sonnet)

[openrouter] endpoint: default auth: sk-or-v1...a0536674 (env: OPENROUTER_API_KEY)
• openrouter/arcee-ai/trinity-large-preview:free (trinity)
• openrouter/mistralai/mistral-small-3.1-24b-instruct:free (mistral-free)

[twilit silo]

Your instinct is right: nothing in OpenClaw “hardcodes Haiku for session_status.” The session_status tool is a local tool that reads config/session state and formats a card; it does not call Anthropic (or any LLM) by itself.

Given the /model status output you pasted, here’s what it does tell us:

1) Your session is not on the default model right now

You have:

• Current: openrouter/arcee-ai/trinity-large-preview:free
• Default: openrouter/mistralai/mistral-small-3.1-24b-instruct:free

So the session has (or had) a per-session override at least at the time you ran /model status. OpenClaw commonly shows both because “default” is config, while “current” is the session’s active selection/override.

2) Those Anthropic Haiku log lines were almost certainly the agent LLM calls, not the status tool

When an agent uses tools, it often results in two model requests close together:

1. model call that decides “I should run session_status”
2. model call that turns the tool output into a final chat reply

That matches your “two Haiku requests within 1 second” observation perfectly.

3) The (next, lastGood) hint strongly suggests Anthropic was used recently

In your output, Anthropic auth is marked (next, lastGood). That “lastGood” is consistent with: Anthropic was the last provider that successfully answered a turn recently — i.e., the Haiku calls you saw.

That still doesn’t mean “status uses Haiku”; it means the agent ended up using Haiku for that turn (because it was selected/overridden or because failover kicked in).

The two realistic explanations for “why Haiku, when default is Mistral?”

1. Failover happened: the OpenRouter/Mistral call failed (rate limit, transient OpenRouter issue, model unavailable, etc.) and OpenClaw moved to a fallback that includes anthropic/claude-haiku-4-5.
2. The session was overridden (at that time) to Haiku (or to a model list where Haiku was the next viable option).

How to prove which one it was

Ask the gateway why it switched by checking logs around that timestamp, or inspect failover/cooldown state:

• Gateway logs (best signal): look for “cooldown/disabled/failover” around 12:11:51–52.
• Model failover state: openclaw models status --json and check auth.unusableProfiles / cooldowns.
• Confirm your configured fallbacks: openclaw config get agents.defaults.model (you’re looking for whether Haiku is in fallbacks).

If you paste:

• openclaw config get agents.defaults.model
• and the relevant snippet from gateway logs around that time (even just the few lines mentioning openrouter/anthropic/failover)

…I can tell you exactly whether it was a configured fallback vs an explicit session override.

[velvet lintel]

{
"primary": "openrouter/mistralai/mistral-small-3.1-24b-instruct:free",
"fallbacks": [
"anthropic/claude-haiku-4-5"
]
}

[twilit silo]

That JSON answers it cleanly:

{
  "primary": "openrouter/...mistral...:free",
  "fallbacks": ["anthropic/claude-haiku-4-5"]
}

So the “actual truth” is:

1. OpenClaw did not hardcode session_status to Haiku.
   The session_status tool doesn’t call any LLM provider at all (it’s local).

2. Your agent is configured to fall back to Haiku if the primary OpenRouter/Mistral model can’t be used for a turn (timeout, 429/rate limit, provider hiccup, auth issue, model unavailable, etc.).

3. The two Anthropic requests around the same second are very plausibly the tool loop:

• one model call that decides to run the tool
  • one model call that formats the final reply after tool output

If you want to know why it fell back at that exact time, check gateway logs around 12:11:51–52 — you should see the OpenRouter/Mistral failure reason right before it switches to the fallback.

And if you don’t want Anthropic to ever be hit, remove/replace that fallback (but then when OpenRouter/Mistral blips, you’ll get hard failures instead of automatic recovery).