Anthropic/Opus - error after prune

[BouquetAntoine]

Hi,

With the last version of DCP I have this message with Opus 4.5 :

prune tool seems to alter thinking & redacted_thinking blocks for Anthropic (something that Anthropic doesn't like that)

Any idea ? when it happens it's impossible to continue the conversation, or we need to fork from before the prune call

[Tarquinen]

This isn't a DCP bug its an opencode or anthropic bug, not sure why it happens. DCP tools don't modify any thinking blocks. I tried to reproduce this and there's nothing consistent about when it happens even in identical session

[BouquetAntoine]

Really weird, I think I will fork oh-my-opencode and extract their anthropic error recovering system as a dedicated plugin, thanks for the fast answer !

[BouquetAntoine]

Tried fixes all day, seems really hard to fix as Anthropic is very opaque about that, but I have a 100% working solution : stripping ALL thinking/reasoning blocks from all assistant messages EXCEPT last one (interleaved tool calls need the thinking block per the documentation), from https://platform.claude.com/docs/en/build-with-claude/extended-thinking#differences-in-thinking-across-model-versions

By doing that they manage all the thinking thing on their side (even if not sent), it works well with Opus 4.5/4.6 AND DCP, I'm now doing test to check if there is an impact on prompt caching

[Tarquinen]

Sure, but this breaks reasoning continuity and context maintenance as your screenshot shows? Sounds a lot better than the session bricking but maybe the real solution is find out whats modifying the thinking blocks? Either way this isn't DCP related, I saw this mentioned in the opencode discord, maybe they will figure it out

[BouquetAntoine]

If the doc is good there isn't breaking of reasoning continuity, it's enforced by Anthropic, thinking is preserved by default since Opus 4.5

Reasoning blocks were excluded for Sonnet (even if sent), and are enforced for Opus (even if not sent)
From their doc we only need to send them back for the last message when using interleaved thinking

I'm still doing tests to see if there is an impact on cache hit/miss

[BouquetAntoine]

Raw requests test (scripts created by Opus 4.6)
thinking_blocks_cache_report.md

[BouquetAntoine]

And the last test with interleaved thinking

RESULTS_interleaved_thinking_tools.md

Seems like a win 🥳
a standard opencode plugin can fix that, experimental.chat.messages.transform => remove every reasoning block except the last one if role=assistant & thinking block

Edit: btw I know this isn't DCP related, but I had that problem after pruning, just sharing a working solution until it's fixed :)

[Tarquinen]

Going to reopen this, turns out the person in my screenshot above tested incorrectly and they said they only get this issue with DCP, without the anthropic error never shows up

[Tarquinen]

not really a huge fan of stripping reasoning parts from all message parts other than the last message even if it fixes this, I'm not convinced this doesn't affect performance... Also not sure how this plugin is causing this in the first place because DCP doesn't make reasoning part modifications, or how to replicate the issue.

[BouquetAntoine]

Going to reopen this, turns out the person in my screenshot above tested incorrectly and they said they only get this issue with DCP, without the anthropic error never shows up

Same problem, doesn't happen without DCP, that's really weird as I tried a lot of workarounds on Opencode & DCP to fix the issue, with raw HTTP requests interception to check what was exactly sent to Anthropic and everything were good.
I'm working with my fix since the last week and didn't got any error since, and doesn't seems to affect performance for my workflows, both of my benchmarks shown it had no impact on prompt caching so I guess it's almost the same
The only problem is if we don't send any message < 5 min cache is expired, and because we don't keep reasoning parts the new cached sessions doesn't contains any of the reasoning blocks.