Move nested handoffs to opt-in feature

[seratch]

The "nested handoffs" behavior introduced in #1996 was intended to address handoff quality issues starting with the GPT-5 series.

We still believe this is a valuable enhancement for that purpose; however, the underlying internal changes introduced some side effects (for example, #2151), and we need more time to stabilize it.

For this reason, we will roll back the change in the 0.7 series and move nested handoffs to an opt-in beta feature for developers who need it. We’ll continue improving it, and once it’s ready for all net-new developers, we’ll enable it by default again.

[ihower]

+1 for this change.

I personally don’t think nested handoffs are better, for a few reasons:

• It is incompatible with server-managed conversation. Handoff is incompatible with server-managed conversation #2151
• It break prompt caching by default.
• More importantly, it makes context engineering much harder. Many context editing techniques rely on item-level structure: keep only the last N turns, drop old tool outputs, trim specific ranges, etc. When nest_handoff_history collapses everything into one long string, those techniques become hard (or impossible) to apply.

So, I think nested handoffs should be an opt-in “context editing feature" at handoff time. And I think we can have multiple strategies to choose from in the future. For example, the new Responses API compact looks promising. It would be great if it could be offered as one option. More broadly, it may be worth designing a generic context editing interface or middleware so different strategies can be plugged in, and applied at different points, not only during handoff. For example, it could run between turns as well.