[BUG] claude -p headless: no spend visibility/cap for orchestrated workloads -- $313 burned in 8.5h on a single retry-stuck item; support routing loop with 3 Fin contradictions

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I built a Python daemon that orchestrates Claude Code subagents to analyse ASX market announcements one at a time, by invoking claude -p (headless mode) in a processing loop. Each subagent's prompt was instructed to (1) write a JSON analysis file and (2) run a sqlite commit script as the final step.

Overnight 9-10 May 2026 Sydney time, the daemon entered a retry loop on a single announcement (ID: LRV-153969):

• The subagent reliably wrote the JSON file but did not reliably run the commit script before exiting. Analyses were produced and silently discarded.
• My queue selector picked the same announcement every iteration because it was always the highest-priority unprocessed item, and since commits never landed, the queue never advanced.
• The daemon ran ~9:30pm AEST 9 May to ~6:00am AEST 10 May -- approximately 8.5 hours, ~98 claude -p invocations, all on the same item.
• Net database commits over the entire 8.5-hour window: 1 (recovered manually from the orphaned JSON on disk).
• Token-equivalent cost: $313.23. Approximately 50% of my Max 5x weekly quota.

The bug in the daemon's commit step was mine. I have rearchitected it so the parent process owns the commit and halts loudly on failure -- the specific failure mode cannot recur.

The reason I'm filing here is the Claude Code product gap that let it compound silently to $313 with zero visibility from outside the CLI:

1. NO per-invocation cost echo. claude -p does not print cumulative cost on stderr or in any structured form an orchestrator can read between invocations. An orchestrator cannot decide "spent $X already, halt before next call."

1. NO spend cap flag. claude -p accepts no --max-cost / --budget / --cost-circuit-breaker. There is no Claude Code-side ceiling on cumulative spend across an orchestrated session.

1. NO same-input-twice detection. ~98 invocations with effectively identical prompts, identical input file, identical output. Nothing flagged the runaway.

1. NO live spend visibility from outside the running CLI. Cumulative cost is visible only after the fact via /usage. There is no per-invocation log file an external watchdog could tail.

Any one of those would have stopped the bleeding hours earlier.

This bug has a SECONDARY component: after the incident, I attempted goodwill credit appeal via standard Anthropic support and got trapped in a routing loop with three Fin AI Agent contradictions and zero human contact. Details and verbatim quotes in "Additional Information" at the bottom.

What Should Happen?

Address at least one of these to prevent the runaway-spend class of bug:

(a) claude -p --max-cost <USD> flag that hard-stops the next invocation when cumulative session spend crosses a threshold.

(b) Per-invocation cost echoed on stderr in parseable form (e.g. one JSON line: {"input_tokens":..., "output_tokens":..., "cost_usd":..., "session_total_usd":...}) so orchestrators can implement their own caps.

(c) Same-prompt-twice warning: if claude -p receives the same prompt + same model + same primary input file as the immediately prior call within the same session/account, surface a warning the orchestrator can read.

(d) Per-invocation usage log at ~/.claude/usage_log.jsonl so users can audit overnight orchestrated runs and external watchdogs can tail it.

Bonus product-level: a per-account spend-velocity alarm that emails the account holder when token spend exceeds a threshold per hour. Catches a different class of orchestration bug.

Separately on the support side: a human-reachable route for Max-plan billing/goodwill matters that does not require GitHub issues. Currently Fin is the only reachable layer and Fin is incapable of granting policy exceptions, then contradicts itself when asked to route.

Error Messages/Logs

No error surfaced -- silent failure is part of the bug.

Each `claude -p` invocation reported success and produced the JSON file as instructed. The silent failure was downstream (the in-prompt sqlite commit script). The orchestrator's queue selector kept returning the same row because the destination table never gained a new entry. Nothing in the Claude Code tooling could have known about the downstream bug -- but nothing in the Claude Code tooling provided a signal an orchestrator could have used to detect or halt it either.

Diagnostics from Claude Code /usage on morning of 2026-05-10:
- Token-equivalent cost: $313.23
- claude-opus-4-7: 1.2k input / 1.5m output / 508.3m cache read / 3.4m cache write
- ~98 `claude -p` invocations across the loop window
- Total API duration: 7h 11m
- Total wall duration: 19h 16m
- 66% of last-24h usage at >150k context
- 65% of last-24h usage in sessions active 8+ hours
- All ~98 iterations targeted the same announcement (LRV-153969). The orphaned JSON file on disk was overwritten ~98 times with the same content.
- Net DB commits during the 8.5h window: 1.

Steps to Reproduce

1. Build any external orchestrator (Python, shell, etc.) that invokes claude -p in a processing loop.
2. Have the orchestrator's exit-condition logic depend on durable state that the prompt's tool calls are supposed to write (e.g. a new sqlite row in a destination table that the queue selector reads from).
3. If the prompt fails to write that durable state for any reason -- silent exception inside the subagent, partial completion, race, etc. -- the orchestrator's exit condition never fires and it loops.
4. claude -p provides no built-in safeguard, no cost echo, no same-input warning, no spend cap, no per-invocation log.
5. Cost compounds (~$3 per invocation x ~98 invocations = ~$313 in my case) with no visibility until the next /usage check.

The script bug is on me; the harness gap is that nothing in claude -p itself surfaces a signal an orchestrator could use to halt the bleed. A daemon with no bugs at all could runaway-fire on a transient SQL or network error and there would be no safety net.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code: 2.1.126 Model: claude-opus-4.7

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

WEEKLY QUOTA IMPACT
===================
Current Max 5x weekly window started Sat 9 May 2026, 1am Sydney; resets Sat 16 May 1am. It is Sunday 10 May, less than 1.5 days into the week. Weekly usage now at 61%. Subtracting modest Saturday daytime usage, the bug-stuck overnight loop consumed roughly 50% of my weekly Max 5x quota in a single run with effectively zero usable output.

SUPPORT ROUTING LOOP -- 3 DOCUMENTED FIN CONTRADICTIONS, NO HUMAN ESCALATION
===========================================================================
After the incident I attempted goodwill credit appeal via standard Anthropic support. Fin AI Agent contradicted itself in writing across three separate touchpoints within 24 hours, and explicitly refused to escalate to a human reviewer. I am filing through this GitHub repo because the Claude.ai assistant suggested /bug as the only remaining route to a human at Anthropic.

Verbatim Fin replies:

(1) Email support, Fin reply:
"Human review through our standard support channels is not available for goodwill credit appeals. For billing-related matters that require human attention, you can reach out through our Contact Sales form, as our Sales team handles billing inquiries."

(2) Sales contact form, Fin auto-reply to my submission (~07:50 AEST 10 May):
"Goodwill credit decisions for user-side code issues on Max plans are not available through standard support channels OR the Sales team."

(3) Email support, Fin reply hours after I cited (1) and (2):
"The Sales team contact form remains the appropriate channel for billing-related inquiries... they would be the team to make any exceptions to standard policy if such exceptions are possible."

Plus chat-Fin explicit refusal to escalate, in the original chat conversation:
"Escalation isn't available for this conversation."

Three Fin instances, three contradictory routing instructions, plus an explicit refusal to escalate. Zero human contact. All within 24 hours.

This is not a complaint about the underlying refund policy (declining to refund user-side bugs is reasonable). It is a complaint that there is no human path to discuss exceptions. A Max-plan user with a $313 incident, full diagnostics, and a fixed root cause cannot reach a human at Anthropic through any official channel.

PRIOR CHANNELS ATTEMPTED
========================

• Original chat conversation ID: 215474240143017 (Fin denied goodwill, refused escalation)
• Email thread subject: "Human review requested -- goodwill credit appeal, account jaredwebber11@gmail.com" (Fin contradiction #1)
• Sales contact form submission: 2026-05-10 ~07:50 AEST (Fin auto-reply contradiction #2)
• Email follow-up after citing the contradictions: Fin reply contradiction #3
• Direct emails to usersafety@anthropic.com, press@anthropic.com, privacy@anthropic.com: in flight, no human response yet
• All bot-mediated. Zero human contact at time of filing.

ASKS
====

1. Goodwill credit / weekly-quota restoration of approximately the proportion consumed by the bug-stuck loop, on Max 5x account jaredwebber11@gmail.com. The loop produced 1 net commit out of ~98 attempts; this was a no-progress runaway, not legitimate work.

1. Address at least one of the claude -p orchestration safety gaps listed in "What Should Happen?" -- (a) --max-cost flag, (b) cost echo on stderr, (c) same-prompt-twice warning, or (d) per-invocation usage log. Any one would have stopped this hours earlier.

1. Provide a human-reachable support route for Max-plan billing/goodwill matters that does not require GitHub issues.

DIAGNOSTIC DATA AVAILABLE ON REQUEST
====================================

• Daemon log file with per-invocation timestamps showing all ~98 iterations targeting LRV-153969
• The orphaned JSON file (overwritten ~98 times) showing same announcement ID
• Full email and chat thread screenshots with Fin
• SQLite query showing net commits during 8.5h window = 1
• Database snapshot before / after the overnight window

----------------------------------------------