Opus 4.6 failing the new V3 compress tool in subagent space?

[nmzpy]

I've seen it fail like even 5 times in a row, what is going on? is it getting Prune ID's from the MAIN conversation you think?

This doesn't always happen. A lotta times it works fine

[DanielusG]

I noticed it too; every now and then they fail to compact correctly, and depending on the model, some carry on as if nothing happened, while others try again several times.

[nmzpy]

You'd think that opus 4.6 thinking should be able to do this

[Tarquinen]

This is interesting, haven't seen opus fail like this myself so there might be a bug. If possible, can you go through the steps in #431 and if the information isn't sensitive send the jsons? If it is sensitive, can you look through the jsons at the tool calls and try to see if there's some reason it's using those IDs?

[nmzpy]

I for sure will debug this in upcoming days, now im tight on some deadlines dont worry -- another occurence:

[Tarquinen]

yea there's definitely a bug here, this is all in subagents right? Also any pattern you can think of so I can replicate?

[nmzpy]

This happens kind of very often for me so replicating I guess is just having DCP work inside subagents windows. Maybe this is an Opencode glitch? I've seen it new versions continue subagents conversations instead of creating new ones so maybe there's a conflict there even IF there is a NEW subagent session.

I don't think this is an Opus issue - GLM-5 also does this and GPT 5.4 -- so something is weird. You might want to try it yourself just hop on any plan and spam subagent sessions let the models ramble for a bit I guess

[Tarquinen]

yea I don't think it's a model / opencode issue, think I have a race condition bug, looking for it

[Tarquinen]

yep found it, here's your bug:

all parallel subagents looked like this

and with the fix

[Tarquinen]

bug vs fix:

[Tarquinen]

fixed in 43ac7b4