[BUG] Repeated incorrect bug diagnosis led to ~$94 wasted over 2 days on the same root cause

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?

Summary

Over 2 days of active Claude Code sessions, the same bug (wrong indicator card count in scene generation) was diagnosed incorrectly 3 times before the actual root cause was found. Total cost exceeded $94.

What happened

The bug: A scene generator was producing 1 indicator card instead of 2.

Diagnosis attempts:

| Attempt | Diagnosis | Action taken | Correct? |
|---------|-----------|--------------|----------|
| 1st | Cached JSON file from previous run | Deleted cache file | ❌ |
| 2nd | @st.cache_data returning stale data | Removed decorator | ❌ (partial) |
| 3rd | st.session_state.cart holding old object from before code change | Rewrote lookup logic | ✅ |

The actual root cause was straightforward: a cart object stored in session state had been populated before a code change, so it held outdated data. A simple print() of the cart contents would have revealed this in under 5 minutes.

Additional issue: A 3-hour blocking wait in a Streamlit loop (TTS + video rendering subprocess) with no meaningful progress feedback, resulting in the user assuming the process had hung.

Cost breakdown (estimated)

• Repeated wrong diagnoses: each incorrect attempt consumed a full context window of ~50k+ tokens
• Long CLAUDE.md (6,000+ tokens) reloaded on every turn throughout both sessions
• Scene regeneration API calls (repeated due to wrong fixes): ~5 calls × $0.40
• Total: approximately $94 over 2 sessions

Root cause of the cost problem

Claude Code diagnosed by guessing the most plausible surface cause rather than tracing the actual data flow. The correct diagnosis required:

1. Reading st.session_state.cart value at runtime
2. Checking what selected_indicators actually contained
3. Tracing back to why it was 1 instead of 2

None of these verification steps were done before the first two "fix" attempts.

Suggestion

For debugging tasks involving runtime state (session variables, cache, stale data):

• Claude Code should propose adding a diagnostic print/log first before modifying code
• Or explicitly state: "I'm guessing at this point — here's how to verify before I change anything"

This would prevent the pattern of: wrong fix → user retests → wrong fix again → user retests → correct fix.

Environment

• OS: Windows 11 Pro
• Shell: PowerShell
• Framework: Streamlit + Anthropic API (claude-sonnet-4-6)
• Session model: claude-sonnet-4-6

What Should Happen?

Summary

Over 2 days of active Claude Code sessions, the same bug (wrong indicator card count in scene generation) was diagnosed incorrectly 3 times before the actual root cause was found. Total cost exceeded $94.

What happened

The bug: A scene generator was producing 1 indicator card instead of 2.

Diagnosis attempts:

| Attempt | Diagnosis | Action taken | Correct? |
|---------|-----------|--------------|----------|
| 1st | Cached JSON file from previous run | Deleted cache file | ❌ |
| 2nd | @st.cache_data returning stale data | Removed decorator | ❌ (partial) |
| 3rd | st.session_state.cart holding old object from before code change | Rewrote lookup logic | ✅ |

The actual root cause was straightforward: a cart object stored in session state had been populated before a code change, so it held outdated data. A simple print() of the cart contents would have revealed this in under 5 minutes.

Additional issue: A 3-hour blocking wait in a Streamlit loop (TTS + video rendering subprocess) with no meaningful progress feedback, resulting in the user assuming the process had hung.

Cost breakdown (estimated)

• Repeated wrong diagnoses: each incorrect attempt consumed a full context window of ~50k+ tokens
• Long CLAUDE.md (6,000+ tokens) reloaded on every turn throughout both sessions
• Scene regeneration API calls (repeated due to wrong fixes): ~5 calls × $0.40
• Total: approximately $94 over 2 sessions

Root cause of the cost problem

Claude Code diagnosed by guessing the most plausible surface cause rather than tracing the actual data flow. The correct diagnosis required:

1. Reading st.session_state.cart value at runtime
2. Checking what selected_indicators actually contained
3. Tracing back to why it was 1 instead of 2

None of these verification steps were done before the first two "fix" attempts.

Suggestion

For debugging tasks involving runtime state (session variables, cache, stale data):

• Claude Code should propose adding a diagnostic print/log first before modifying code
• Or explicitly state: "I'm guessing at this point — here's how to verify before I change anything"

This would prevent the pattern of: wrong fix → user retests → wrong fix again → user retests → correct fix.

Environment

• OS: Windows 11 Pro
• Shell: PowerShell
• Framework: Streamlit + Anthropic API (claude-sonnet-4-6)
• Session model: claude-sonnet-4-6

Error Messages/Logs

Steps to Reproduce

Summary

Over 2 days of active Claude Code sessions, the same bug (wrong indicator card count in scene generation) was diagnosed incorrectly 3 times before the actual root cause was found. Total cost exceeded $94.

What happened

The bug: A scene generator was producing 1 indicator card instead of 2.

Diagnosis attempts:

| Attempt | Diagnosis | Action taken | Correct? |
|---------|-----------|--------------|----------|
| 1st | Cached JSON file from previous run | Deleted cache file | ❌ |
| 2nd | @st.cache_data returning stale data | Removed decorator | ❌ (partial) |
| 3rd | st.session_state.cart holding old object from before code change | Rewrote lookup logic | ✅ |

The actual root cause was straightforward: a cart object stored in session state had been populated before a code change, so it held outdated data. A simple print() of the cart contents would have revealed this in under 5 minutes.

Additional issue: A 3-hour blocking wait in a Streamlit loop (TTS + video rendering subprocess) with no meaningful progress feedback, resulting in the user assuming the process had hung.

Cost breakdown (estimated)

• Repeated wrong diagnoses: each incorrect attempt consumed a full context window of ~50k+ tokens
• Long CLAUDE.md (6,000+ tokens) reloaded on every turn throughout both sessions
• Scene regeneration API calls (repeated due to wrong fixes): ~5 calls × $0.40
• Total: approximately $94 over 2 sessions

Root cause of the cost problem

Claude Code diagnosed by guessing the most plausible surface cause rather than tracing the actual data flow. The correct diagnosis required:

1. Reading st.session_state.cart value at runtime
2. Checking what selected_indicators actually contained
3. Tracing back to why it was 1 instead of 2

None of these verification steps were done before the first two "fix" attempts.

Suggestion

For debugging tasks involving runtime state (session variables, cache, stale data):

• Claude Code should propose adding a diagnostic print/log first before modifying code
• Or explicitly state: "I'm guessing at this point — here's how to verify before I change anything"

This would prevent the pattern of: wrong fix → user retests → wrong fix again → user retests → correct fix.

Environment

• OS: Windows 11 Pro
• Shell: PowerShell
• Framework: Streamlit + Anthropic API (claude-sonnet-4-6)
• Session model: claude-sonnet-4-6

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

..

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_