[Bug] Advisor tool becomes unavailable mid-session with uninformative error message

Open 💬 0 comments Opened Jul 14, 2026 by bennyliaw

Bug Description
Advisor tool becomes terminally unavailable mid-session; error gives no reason

Summary: advisor() succeeds early in a session and then returns "The advisor tool is unavailable. Do not try to use it again." later in the same session, with no config change. The error is terminal and gives no cause, so there's no way to tell a size limit from a quota from an outage.

Environment: Claude Code CLI, Opus 4.8, macOS (Darwin 25.5.0). ~/.claude/settings.json has "advisorModel": "fable". Working dir ~/dev.

Timeline (single fresh, uncompacted session):

  1. advisor() call #1, near session start, small transcript → succeeded, returned a full review confirming it had received the whole conversation.
  2. Between calls, the claude-api skill loaded and injected a very large reference document into the transcript.
  3. advisor() call #2 → failed: "The advisor tool is unavailable. Do not try to use it again."

Second data point: a separate compacted/resumed session got the same terminal error on its first advisor call. Initially I suspected compaction was the trigger, but the timeline above rules that out — the failing session above was never compacted.

Hypothesis: the trigger is transcript size. The advisor forwards the entire conversation, so a large enough history fails to forward. This explains both cases with one mechanism (a compacted session is by definition one whose history grew large). A cumulative-token or per-session call budget would also fit and can't be distinguished from the client side.

What's wrong with the current behavior:

  • The error is uninformative. "Unavailable, do not try again" doesn't distinguish a size limit, a quota, or a backend failure — and each warrants a different user response. A specific error ("transcript too large to forward") would make this self-diagnosing.
  • The tool's guidance conflicts with the failure mode. The advisor's own instructions say to call it when you believe the task is complete — precisely when the transcript is longest and, on this evidence, when it's most likely to be refused. If size is the trigger, the documented usage pattern points straight at the failure.

Expected: either the advisor keeps working late in long sessions (truncating or summarizing the forwarded transcript if needed), or it fails with an error that names the reason and whether it's recoverable.

Workaround: a fork subagent inherits full context and doesn't go through the advisor backend.

Environment Info

  • Platform: darwin
  • Terminal: ghostty
  • Version: 2.1.209
  • Feedback ID: 8bea7c7c-f6a9-45a1-ad44-5d4484f1ed76

Errors

[]

View original on GitHub ↗