From 0cf1762638e0524852a4968d1b35d3879cd1974b Mon Sep 17 00:00:00 2001 From: Nan Gao Date: Fri, 11 Sep 2026 15:22:26 +0700 Subject: [PATCH] docs(config): note use_previous_response_id in the Responses API example (#5359) `use_previous_response_id` is not a DeerFlow config field; it reaches `ChatOpenAI` only because `ModelConfig` allows extra keys and the model factory forwards them. It is easy to mistake for `use_responses_api`, but the two are not equivalent: the former picks the endpoint, the latter switches the Responses API from replaying the full history each turn to chaining on `previous_response_id` with server-side state. Chained context is still billed as input tokens, and client-side history rewrites are only honored when the history is replayed. Document the key next to the Responses example so operators know what it changes. Comment only, no schema change. --- config.example.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/config.example.yaml b/config.example.yaml index 4d6e924c4..4e309da8a 100644 --- a/config.example.yaml +++ b/config.example.yaml @@ -252,6 +252,12 @@ models: # max_retries: 2 # use_responses_api: true # output_version: responses/v1 + # # Optional, forwarded to ChatOpenAI as-is (default false): send only the new + # # turn plus previous_response_id instead of replaying the full history. The + # # chained context is still billed as input tokens, and any client-side + # # history rewrite (e.g. blocked-write payload elision) is only honored when + # # the history is replayed. + # use_previous_response_id: false # context_window: 400000 # supports_vision: true