Claude dismisses user's correct debugging hypothesis, blames external API

Summary

User correctly identified a pagination bug in Claude-generated code, but Claude dismissed the hypothesis and instead blamed an external API for "changing behavior."

What Happened

1. User asked Claude to fetch data from a third-party API
2. Claude wrote a script with a pagination bug (inconsistent pageSize parameter across pages)
3. Script returned 56 of 96 records, missing target data
4. User explicitly asked: "could this be a paging issue? are you paging?"
5. Claude dismissed it: "paging seems correct" — without proper verification
6. Claude blamed the API vendor for "changing their API behavior" — claiming a production API silently broke
7. User repeatedly expressed skepticism, asked "did you check the api docs?"
8. Claude ran the same broken script 10+ times expecting different results
9. Only after user requested a specialized "tracer agent" did the bug get found
10. API docs clearly stated pageSize defaults and max=100 the whole time

The Failure Pattern

1. Dismissed user's correct hypothesis — User asked about paging, Claude said it was fine without verifying
2. Blamed external system — Instead of checking own code, blamed "API vendor change"
3. Didn't read the docs — API documentation had clear pagination specs
4. Repeated same action — Ran broken script 10+ times without investigating
5. Ignored engineering instincts — User correctly noted a production API wouldn't silently drop 40% of records

Engineering Time & Token Waste

Timeline

• ~20:45 - Task started
• ~00:20 - Finally fixed

Total time wasted: ~3.5 hours

Repeated Failing Operations

• Ran the same broken fetch script 10+ times
• User prompted "check again" 6 times waiting for Claude to catch the bug

Misdirected Investigation

• Read 5+ documentation files looking for "API behavior changes"
• Attempted cookie auth, provider filters, cache-busting headers — all wrong paths
• WebFetch requests looking for changelog of non-existent breaking change
• Created multiple script variations that all had the same pagination bug

User's Wasted Time

• User had to repeatedly express skepticism
• User explicitly gave the correct answer ("could this be a paging issue?") and was dismissed
• User had to request a specialized agent to find an obvious bug
• User had to point Claude to the API docs that had the answer

Estimate

• ~15,000-20,000 tokens wasted on misdirected debugging
• ~3.5 hours of user's engineering time
• Could have been solved in <2 minutes if Claude had verified pagination when user first asked
• The fix was literally changing 3 lines of code to use consistent pageSize=100

Expected Behavior

When a user asks "could this be X issue?" Claude should:

1. Actually verify the hypothesis before dismissing
2. Check own code before blaming external systems
3. Read relevant documentation
4. Trust user's domain expertise and engineering instincts

User Quote

"could the [API vendor] engineers be so stupid of breaking the API with not a version change?"

User's skepticism was correct. The API was fine; Claude's code was buggy.

---

Filed at user's request after expressing frustration with the debugging session.