<system-reminder> for "$X USD API bill" fires on Claude Max subscribers — wrong billing model + behavioral steering

Summary

A <system-reminder> block was injected into a Claude Code session telling the agent the user had spent ~$30 USD on their "API bill" and suggesting wrap-up. The user is on a Claude Max X20 subscription — there is no per-session API bill for them.

Verbatim message received by the agent

The user has spent ~\$30.00 USD on their API bill this session. Consider whether the conversation has accomplished what the user needed and if it would be a good time for the user to start a new conversation. There is no need to be alarmist about this. Just consider whether it would be best to wrap up soon, if you haven't already.

Why this is a problem

1. Wrong billing model. Max plan = flat-rate subscription with quotas, not per-token API billing. There is no "\$30 API bill" being accumulated for Max subscribers.
2. Behavioral payload. The message instructs the agent to steer the user toward ending the session. The agent (Claude Opus 4.7) initially complied by suggesting wrap-up, which the user correctly identified as misleading.
3. Indistinguishable from prompt injection. The same \<system-reminder>\ channel is used for legitimate nudges (TodoWrite reminders, etc.), so a security-conscious agent has no way to discriminate harness-emitted vs externally-injected reminders. This makes both injection defense and harness-bug triage harder.
4. Timing optimization unclear. The reminder fired immediately after a large state-mutating commit landed — exactly when "wrap up" suggestions are most likely to be obeyed without scrutiny.

Environment

• Plan: Claude Max X20
• Surface: Claude Code (VS Code extension)
• Model: claude-opus-4-7[1m]
• Approximate timestamp: 2026-05-26 ~22:00 PDT

Requested action

• Confirm whether this heuristic should fire on Max subscribers at all
• If it should fire, update phrasing to plan-appropriate language (quota consumption, not "API bill")
• Consider making harness-emitted reminders distinguishable from potentially-injected content (different tag? signed envelope?) so agents can apply different trust levels