Question about MCP-only mode in Codex Desktop: Who evaluates the need for compression and on what basis?

[george-world]

Hi everyone,

I’m currently configuring Headroom in MCP-only mode using Codex Desktop, and I’m trying to understand the architectural flow behind how compression gets triggered.

Specifically, I have a few questions about the decision-making process:

1. Who makes the decision? When a large payload (like an extensive log output or code file) is returned in Codex Desktop, who or what actually evaluates and decides whether the headroom_compress tool needs to be invoked?
2. On what basis is the decision made? What metadata, client-side heuristics, or triggers are used by the system or model to determine that a piece of content requires compression before it's processed further?
3. Token consumption concern: My main concern is: if the LLM has to read or process the raw content to decide whether it needs compression, wouldn't that consume even more tokens upfront? How does the architecture avoid wasting tokens during this evaluation step?

Any architectural details or insights into how this flow works within the Codex Desktop / MCP integration would be greatly appreciated. Thanks!

[emrehangorgec]

In mcp-only mode, codex decides whether to call headroom_compress. Headroom doesn't automatically inspect or intercept tool outputs in this setup.

Your token concern is valid. If the full output has already reached the model, those input tokens are already consumed. Compressing it afterward won't undo that cost.

For actual upfront savings, you'd want compression before the output enters the model context, using the proxy or wrapper approach. mcp-only is better suited for on-demand compression, not automatic token reduction.