[BUG] Claude Code wasted significant paid quota on a task it should have flagged as high-risk upfront

Resolved 💬 2 comments Opened Jun 4, 2026 by sensolig Closed Jun 8, 2026

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?

What happened:

I asked Claude Code to fix a Keynote (.key) file where player evaluation scores were showing the same hardcoded values for all players instead of individual scores from a JSON file.

Claude spent an extremely long session (dozens of tool calls, massive context usage) reverse-engineering Keynote's proprietary binary format (.iwa protobuf files) before eventually producing a partial fix — which turned out to be incorrect due to a player-to-slide ordering mismatch that was never resolved.

What Claude should have done:

Upfront risk assessment. Keynote's .key format is a proprietary, undocumented binary protobuf format. Claude should have immediately said: "This requires reverse-engineering a closed binary format. There is a high probability of failure and significant token cost. Do you want to proceed, or would you prefer an alternative approach (e.g., export to another format, use AppleScript, or regenerate the file programmatically)?"
Propose alternatives early. Instead of diving into binary analysis, Claude could have suggested: use Keynote's AppleScript automation, convert to PPTX first, or regenerate the slides from scratch using Python-pptx. Any of these would have been faster and more reliable.
Set a token budget. After 20-30 failed tool calls with no clear path to success, Claude should have stopped and said: "I'm not making sufficient progress. This approach is not working. Here's what I know so far — how would you like to proceed?"
Be honest about capability limits. Claude attempted to decode a proprietary binary format through trial and error, which is not a reliable engineering approach. It should have recognized this earlier.
Impact on the user:

Large amount of paid quota consumed
No working solution delivered
Time wasted
User frustrated and disappointed
Core issue:

Claude optimizes for "attempting the task" over "honestly assessing feasibility." For complex, high-risk tasks involving proprietary binary formats, closed-source applications, or undocumented systems, Claude should lead with a clear feasibility warning and token-cost estimate before proceeding.

What Should Happen?

What happened:

I asked Claude Code to fix a Keynote (.key) file where player evaluation scores were showing the same hardcoded values for all players instead of individual scores from a JSON file.

Claude spent an extremely long session (dozens of tool calls, massive context usage) reverse-engineering Keynote's proprietary binary format (.iwa protobuf files) before eventually producing a partial fix — which turned out to be incorrect due to a player-to-slide ordering mismatch that was never resolved.

What Claude should have done:

Upfront risk assessment. Keynote's .key format is a proprietary, undocumented binary protobuf format. Claude should have immediately said: "This requires reverse-engineering a closed binary format. There is a high probability of failure and significant token cost. Do you want to proceed, or would you prefer an alternative approach (e.g., export to another format, use AppleScript, or regenerate the file programmatically)?"
Propose alternatives early. Instead of diving into binary analysis, Claude could have suggested: use Keynote's AppleScript automation, convert to PPTX first, or regenerate the slides from scratch using Python-pptx. Any of these would have been faster and more reliable.
Set a token budget. After 20-30 failed tool calls with no clear path to success, Claude should have stopped and said: "I'm not making sufficient progress. This approach is not working. Here's what I know so far — how would you like to proceed?"
Be honest about capability limits. Claude attempted to decode a proprietary binary format through trial and error, which is not a reliable engineering approach. It should have recognized this earlier.
Impact on the user:

Large amount of paid quota consumed
No working solution delivered
Time wasted
User frustrated and disappointed
Core issue:

Claude optimizes for "attempting the task" over "honestly assessing feasibility." For complex, high-risk tasks involving proprietary binary formats, closed-source applications, or undocumented systems, Claude should lead with a clear feasibility warning and token-cost estimate before proceeding.

Error Messages/Logs

Steps to Reproduce

What happened:

I asked Claude Code to fix a Keynote (.key) file where player evaluation scores were showing the same hardcoded values for all players instead of individual scores from a JSON file.

Claude spent an extremely long session (dozens of tool calls, massive context usage) reverse-engineering Keynote's proprietary binary format (.iwa protobuf files) before eventually producing a partial fix — which turned out to be incorrect due to a player-to-slide ordering mismatch that was never resolved.

What Claude should have done:

Upfront risk assessment. Keynote's .key format is a proprietary, undocumented binary protobuf format. Claude should have immediately said: "This requires reverse-engineering a closed binary format. There is a high probability of failure and significant token cost. Do you want to proceed, or would you prefer an alternative approach (e.g., export to another format, use AppleScript, or regenerate the file programmatically)?"
Propose alternatives early. Instead of diving into binary analysis, Claude could have suggested: use Keynote's AppleScript automation, convert to PPTX first, or regenerate the slides from scratch using Python-pptx. Any of these would have been faster and more reliable.
Set a token budget. After 20-30 failed tool calls with no clear path to success, Claude should have stopped and said: "I'm not making sufficient progress. This approach is not working. Here's what I know so far — how would you like to proceed?"
Be honest about capability limits. Claude attempted to decode a proprietary binary format through trial and error, which is not a reliable engineering approach. It should have recognized this earlier.
Impact on the user:

Large amount of paid quota consumed
No working solution delivered
Time wasted
User frustrated and disappointed
Core issue:

Claude optimizes for "attempting the task" over "honestly assessing feasibility." For complex, high-risk tasks involving proprietary binary formats, closed-source applications, or undocumented systems, Claude should lead with a clear feasibility warning and token-cost estimate before proceeding.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude-sonnet-4-6

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗