> ## Documentation Index
> Fetch the complete documentation index at: https://docs.poixe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Encrypted Reasoning Content Filtering

With the `OpenAI Responses` protocol, you may encounter an error like the following (common with agent tools such as **Codex CLI / OpenCode**):

```json theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  "error": {
    "message": "The encrypted content gAAA...xrM= could not be verified. Reason: Encrypted content organization_id did not match the target organization.",
    "type": "invalid_request_error",
    "code": "invalid_encrypted_content"
  }
}
```

This is usually related to `reasoning.encrypted_content`. This field is used in **stateless** scenarios to pass "encrypted reasoning state fragments" between multiple turns of requests, improving multi-turn consistency.

## When do you run into this problem?

Typical triggering scenarios:

* You use a tool such as **Codex / OpenCode** to call the `Responses` endpoint
* The tool automatically adds `include: ["reasoning.encrypted_content"]` to the request, and in the next request sends back the `reasoning.encrypted_content` (or the `type:"reasoning"` item) returned last time
* Meanwhile, Poixe, as an aggregation gateway, schedules across **multiple Keys / multiple organizations (org/project)** for capacity and stability
  This causes the "encrypted fragment generated in the previous turn" to mismatch the "organization/Key actually hit in the next turn", triggering a verification failure (the `organization_id did not match` you see)

In short: **an encrypted reasoning fragment is not a session credential that works across organizations/Keys**, and it is easy to trip over in load-balanced / multi-Key proxy environments.

## How Poixe handles it: filtering encrypted-reasoning fields

To avoid this kind of hard error that "blows up starting from the second turn", Poixe makes a compatibility trade-off on `Responses` requests, mainly including:

1. **Removing `include.reasoning.encrypted_content` from the request** (so the upstream does not return this field)
2. **Cleaning up reasoning fragments in the historical items of the request body**

   * Deleting items with `type: "reasoning"`, as well as all `encrypted_content` fields

This means that even if Codex / OpenCode automatically carries these parameters, they will be **filtered out and removed** once they reach Poixe, ensuring that organization mismatch errors are not triggered under multi-Key scheduling.

## Impact and notes

* Filtering does not "delete your conversation content"; your `input/messages` are still forwarded normally
* However, in stateless multi-turn flows, without the "reasoning continuation boost" from `reasoning.encrypted_content`, some agent tasks may show:

  * Reduced multi-turn consistency
  * Repeated planning and a stronger sense of lost context
    (this is a side effect of the inherent conflict between the upstream mechanism design and the proxy architecture)

## Need help?

If you confirm that **the missing field causes a major functional problem** (for example, Codex/OpenCode multi-turn does not work properly or quality clearly degrades), please contact us and we will evaluate a better compatibility strategy together.

<CardGroup cols={1}>
  <Card title="Contact Us" href="/en/help/introduction/overview">
    Report compatibility issues or suggest improvements
  </Card>
</CardGroup>

## References

### Official documentation (recommended reading first)

* **Responses API: the include parameter and related fields**\
  [https://platform.openai.com/docs/api-reference/responses/create#responses\_create-include](https://platform.openai.com/docs/api-reference/responses/create#responses_create-include)

* **Reasoning guide: reasoning outputs and the purpose of `encrypted_content`**\
  [https://platform.openai.com/docs/guides/reasoning#encrypted-reasoning-items](https://platform.openai.com/docs/guides/reasoning#encrypted-reasoning-items)

* **Migrating to Responses: when to use stateful vs. stateless, and notes on `encrypted_content`**\
  [https://platform.openai.com/docs/guides/migrate-to-responses#4-decide-when-to-use-statefulness](https://platform.openai.com/docs/guides/migrate-to-responses#4-decide-when-to-use-statefulness)

* **Cookbook: reasoning items example (Responses API)**\
  [https://developers.openai.com/cookbook/examples/responses\_api/reasoning\_items](https://developers.openai.com/cookbook/examples/responses_api/reasoning_items)

### Azure reference (corroboration of the same concept)

* **Azure OpenAI Responses: stateless multi-turn and related fields**\
  [https://learn.microsoft.com/zh-cn/azure/ai-foundry/openai/how-to/responses?view=foundry-classic\&utm\_source=chatgpt.com\&tabs=python-key#encrypted-reasoning-items](https://learn.microsoft.com/zh-cn/azure/ai-foundry/openai/how-to/responses?view=foundry-classic\&utm_source=chatgpt.com\&tabs=python-key#encrypted-reasoning-items)

### Community discussions / Issues (troubleshooting references)

* **Codex official repo discussion thread (consolidated discussion of related problems)**\
  [https://github.com/openai/codex/issues/8120](https://github.com/openai/codex/issues/8120)

* **OpenCode community feedback: second-turn / resumed-chat problems (corroboration)**\
  [https://github.com/anomalyco/opencode/issues/5104?utm\_source=chatgpt.com](https://github.com/anomalyco/opencode/issues/5104?utm_source=chatgpt.com)

* **new-api project: PR proposing removal of reasoning (reference for engineering-side handling)**\
  [https://github.com/QuantumNous/new-api/pull/2662](https://github.com/QuantumNous/new-api/pull/2662)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.