Skip to content

Reasoning default silently flipped to on for Claude models — doubles Anthropic spend, leaks thinking blocks to chat #73182

@w3i-William

Description

@w3i-William

Summary

An OpenClaw update around April 2026 silently flipped the default reasoning level for Claude models from off to on. The change has two compounding effects, both expensive:

  1. Extended-thinking is requested from the Anthropic API on every turn, so users pay for thinking tokens with no behavioural change opt-in. Daily Anthropic spend can double or triple overnight.
  2. Reasoning blocks render in the assistant reply itself, so internal monologue is sent over the wire to messaging surfaces (Teams, Discord, Slack), where it burns output tokens and clutters conversations.

Users had no upgrade-time signal that the default flipped. The first symptom was the API bill.

Environment

  • OpenClaw: ~April 2026 release (default flip noticed around 2026-04-25)
  • Provider: Anthropic Claude (Opus, Sonnet)
  • Channels affected: any messaging surface — confirmed on Microsoft Teams

Symptoms

  • Runtime status line shows Reasoning: on (hidden unless on/stream) even though the user never opted in.
  • Long preamble paragraphs appear in chat replies — visible "thinking aloud" before the actual answer.
  • Daily Anthropic cost jumps with no other change in workload, model, or volume.
  • /status confirms Reasoning: on.

Reproduction

  1. Fresh OpenClaw install (or any install where agents.list[].reasoningDefault is unset).
  2. Configure an Anthropic Claude model (e.g. anthropic/claude-opus-4-7).
  3. Send any message in a normal chat session.
  4. Observe in runtime status that Reasoning: on despite no /reasoning toggle and no explicit config.
  5. Inspect the Anthropic API request payload (or daily cost report) — extended thinking tokens are being billed.

Root cause (suspected)

The default for reasoningDefault (per-agent) appears to be implicitly on for Claude models when the field is unset, rather than off. There is no agents.defaults.reasoningDefault field exposed in config, so users cannot set it globally — they must set it on every agent individually.

Workaround (current)

Persist reasoningDefault: "off" per agent in ~/.openclaw/openclaw.json:

{
  "agents": {
    "list": [
      { "id": "main", "reasoningDefault": "off" }
    ]
  }
}

For an active session without restart: type /reasoning off in chat.

This works but is footgun-y:

  • Requires a config change per agent (no global default).
  • The flag is not surfaced in the install / setup docs prominently enough to catch before the first billing cycle.
  • A user who runs multiple agents has to remember to set it on each one.

Suggested fix

  1. Default reasoningDefault to off for all models unless the user explicitly opts in. Reasoning is a power-user feature; it should be opt-in, not opt-out.
  2. Expose agents.defaults.reasoningDefault so users can flip it once for all agents.
  3. Add a one-line warning at gateway start if any agent has reasoning enabled (e.g. [gateway] note: agent "main" has reasoning=on; thinking tokens will be billed and rendered). This catches accidental enables and the default-flip case.
  4. Consider separating "request reasoning from API" from "render reasoning in reply" — they're orthogonal concerns. A user might want API-level extended thinking (better answers) without leaking the monologue into Teams/Discord.

Severity

Medium-High. No data loss, no service outage. But:

  • Real, ongoing cost impact (Anthropic spend doubled overnight in our case).
  • Information leak risk: internal monologue rendered in customer-facing channels can leak context, hypothetical tool calls, and reasoning the user didn't intend to expose.
  • Silent default change with no upgrade notes is a trust issue — users discover it via their bill.

Related

This is independent of the prose-narration issue (assistant text starting with "Let me ___", "Now ___", etc.), which is a behavioural / system-prompt concern rather than an API-level reasoning concern. The two compound when both are happening, but the fixes are distinct.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions