Apply the context trim to streamed runs

[elias-ba]

Short Description

context_management was only passed on the planner's non-streaming call. Global chat streams, so the config only ever reached a path production does not take. Both calls now share one definition.

Implementation Details

Lightning sends "options" => {"stream" => true} to /services/global_chat/stream (apollo_client.ex:280), global_chat reads that flag and the router hands it to the planner, so _call_api always takes the streaming branch in production. That branch called self.client.messages.stream on the non-beta client with no betas and no context_management, while the non-streaming branch below it had both. The streaming call moves to self.client.beta.messages.stream, which accepts both, and the config becomes one shared constant so the two cannot drift apart again.

Worth being straight about what this does not do. With max_tool_calls at 20 and the trigger at 40 tool uses, the trim cannot fire on either path: a run tops out around 20 plus a small parallel overshoot, and return_history carries no tool_use blocks so nothing accumulates across turns. This is a backstop if the budget rises, not something that bounds a run today. Actually bounding it means putting the trigger below the budget and protecting the wrap-up round some other way, or measuring the trigger in input_tokens rather than tool uses. That is a separate change and I have not made it here.

The unit tests patch _call_api, so nothing exercises the new request shape and this is now the only path that runs. I sent a real streaming request against claude-opus-4-8 with the beta header, context_management, tools, thinking and output_config: it returned end_turn with BetaContextManagementResponse(applied_edits=[]), so the shape is accepted and, as expected, nothing was cleared.

AI Usage

Please disclose whether you've used AI in this work (it's cool, we just want to know!):

• Yes, I have used AI
• No, I have not used AI

You can read more details in our Responsible AI Policy