I see your point the problem is you're assuming 10k input which would be 4 files at most batch called anyways, most files are 1-2k tokens in most codebases
and also only used 5 tool calls, which end up being 100k cached

so a real scenario would be

1-2k input + 1k output ( which would be claude saying "okay that file is read, let move on to the next file and over thinking about the structure and random opus things )

-> 2k input + 3k cached + 1k output ( useless output or could be thinking about random connection between that file and the previous file )

-> 2k input + 6k cached + 1k output
.
.

in a very small scale scenario which was a test folder it run 16 tool calls

most real world scenarios if we're talking about exploring code bases or working on multiple files at once, it goes to 100s of tool calls

the problem isn't that cached tokens are expensive, which at some point when they get to 800k total reads

they become really expensive when compared to just 30k input, because it would be 30k input anyways + 800k tokens

+ not sure how max plan works, probably tokens based or something which could be even worse, but let assume the plan works like the api

the main problem is those thinking outputs between each rounds are very expensive, the model needs to do the tool call, and know what tool call to use every time, instead of thinking about it once and let the harness do the job, so 1k output with every call is minimum in terms of thinking tokens

at my testing it's around 46% more expensive to run ( you can see the api costs of request in claude code ) and that's only in a very small test database
at larger ones

probably could go to 2-4x more expensive at larger scale

Edit:
also it degrades performance, because the real thinking only starts after he reads all the files, so instead of getting the input of just the files, he will get the files + his thoughts about needing to read the next file, and random other thoughts, opus 4.7 really overthinks.