Avoid cloning normalized conversation history again during request construction

What variant of Codex are you using?

CLI

What feature would you like to see?

I found a potential performance concern in the current source rather than a confirmed user-visible bug.

Please preserve the existing model-request behavior while avoiding a second request-sized clone of normalized conversation history during request construction. The normalized prompt input could be transferred, borrowed, or represented with shared/copy-on-write ownership so it is materialized again only when a request-specific transformation, such as Responses Lite image-detail stripping, actually requires mutation.

Additional information

Evidence

• At audited upstream commit 5157493, ContextManager::for_prompt normalizes shared session history and returns an owned Vec<ResponseItem> through Arc::unwrap_or_clone.
• Prompt::get_formatted_input_for_request immediately calls self.input.clone() before conditionally stripping image details.
• This means the common path still deeply clones the complete normalized input even when use_responses_lite is false and no request-specific mutation occurs.
• Merged PRs #28306, #28313, and #34825 removed adjacent request-sized clones but do not remove this remaining two-stage materialization.
• The related PRs discuss histories around 260,000 input tokens, providing a realistic large-history scenario where a full additional deep copy may be non-trivial.

Impact

Not measured. The additional allocation volume and request-construction latency are unknown.

The source establishes that the cost scales with the number and size of ResponseItem values and occurs whenever the prompt input is formatted into a model request, including request construction repeated for later model steps or retries. This report does not claim a measured user-visible slowdown.

Question

Would maintainers prefer request construction to consume or borrow the normalized prompt input, or to use a shared/copy-on-write representation that materializes an owned copy only when a transport-specific mutation is required?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 Sol (runtime-default reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.