pub const CONTEXT_RESPONSE_RESERVE_TOKENS: u64 = 16_384;Expand description
PARITY-18 — headroom reserved for the model’s own completion, folded
into the context-guard boundary alongside with_guard_margin. Neither
estimate_view_tokens nor estimate_request_tokens counts anything
for the reply the model is about to generate — this is a flat token
budget carved out of the model’s context window for it, since the
completion shares the same window as the request on every provider this
crate targets.
PARITY-18 v3 NOTE-AND-DECIDE (NF6, owner-recorded, not fixed here): this
is a FLAT reserve — it does not read Config::max_tokens
(crates/harness/src/config.rs, user-settable via --max-tokens, wired
into the actual provider request at provider.rs’s
ChatRequest::max_tokens). A user who passes --max-tokens greater than
16,384 can still pass this guard (projected + 16_384 <= context_limit)
and then draw a provider-side input_tokens + max_tokens > context_window
rejection the guard never anticipated — i.e. the guard’s margin can be
smaller than what the user actually asked the provider to reserve for the
completion. Making the reserve max(CONTEXT_RESPONSE_RESERVE_TOKENS, config.max_tokens) would close this, but context_guard doesn’t
currently receive Config at all (only messages/tools/
context_limit) — threading it through is a small but real signature
change touching every call site (resume_cmd, Agent::run_loop, and
this pass’s new reduce_to_fit fits closures) that’s out of scope for
this pass’s reducer/guard boundary fix. Recorded for the owner.