Proposal: reduce token usage for common verbose exec_command outputs

Resolved 💬 2 comments Opened Mar 17, 2026 by joeeeeey Closed May 16, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Context

First, thank you for building and maintaining Codex.

I read the contribution policy in docs/contributing.md and understand that external code contributions are currently invitation-only.

I still wanted to share a concrete, tested implementation idea because this appears to be a common token-efficiency pain point in real usage.

Proposal

Reduce model token footprint for very common verbose shell outputs in exec_command responses:

Strip ANSI escape sequences before truncation.
Add conservative compaction for high-noise commands:

git status (non-porcelain): compact staged / unstaged / untracked summary
ls -l / ls -la: compact file-type + filename listing

Apply compaction only when it produces meaningful size savings; otherwise fallback to existing output.

Why this may help

In interactive coding sessions, git status and ls -la are frequently emitted.
Their default output often has high formatting overhead relative to decision-relevant signal, which increases context consumption.

A conservative compaction layer can preserve useful signal while reducing token pressure.

Ready Implementation (for reference)

I prepared a working patch on my fork with unit tests.

Branch: joey/token-compact-common-command-output
Commit: 9379013baf3f2c1c5242806cb9a9df027868c7ba
Fork branch URL: <https://github.com/joeeeeey/codex/tree/joey/token-compact-common-command-output>
Commit URL: <https://github.com/joeeeeey/codex/commit/9379013baf3f2c1c5242806cb9a9df027868c7ba>

Files changed:

codex-rs/core/src/tools/context.rs
codex-rs/core/src/tools/context_tests.rs

What I am asking

If this direction aligns with Codex priorities, could a maintainer advise whether:

you would prefer this as a feature request only, or
you would like to invite an external PR for this scope.

I am happy to adjust design details, naming, or test shape based on maintainer feedback.

Thank you for your time.

View original on GitHub ↗

2 Comments

joeeeeey · 5 months ago

I wanted to follow up with concrete before/after samples to quantify potential impact.

I ran local fixture-based measurements using the same compaction heuristics as the patch on my fork:

ANSI stripping before truncation
git status compaction (non-porcelain)
ls -la compaction (long listing)
same section cap behavior (120 entries per section)

For token estimates, I used len(text) / 4 (integer), which is the same lightweight approximation commonly used for trend analysis (not exact tokenizer counts).

Before/After Samples

| Scenario | Before bytes | After bytes | Byte reduction | Before est tokens | After est tokens | Token reduction | Before lines | After lines |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| git status (typical mixed) | 14274 | 12927 | 9.4% | 3568 | 3231 | 9.4% | 132 | 126 |
| git status (heavy staged/unstaged) | 69861 | 25773 | 63.1% | 17465 | 6443 | 63.1% | 608 | 246 |
| git status -uall (large untracked) | 45224 | 28972 | 35.9% | 11306 | 7243 | 35.9% | 451 | 286 |
| ls -la (420 entries) | 53820 | 8241 | 84.7% | 13455 | 2060 | 84.7% | 447 | 122 |
| ANSI escape-only output | 32 | 14 | 56.2% | 8 | 3 | 62.5% | 2 | 2 |

Key takeaways

The largest gains appear in exactly the high-noise cases this proposal targets (especially long ls -la and large git status outputs).
Even in a more typical mixed git status case, reduction is still positive.
In heavier workflows, reductions are substantial (roughly 36% to 85% in these fixtures), which can materially lower context pressure.

Patch reference

If helpful for evaluation, the implementation and tests are ready on my fork:

Branch: joey/token-compact-common-command-output
Commit: 9379013baf3f2c1c5242806cb9a9df027868c7ba
Branch URL: https://github.com/joeeeeey/codex/tree/joey/token-compact-common-command-output
Commit URL: https://github.com/joeeeeey/codex/commit/9379013baf3f2c1c5242806cb9a9df027868c7ba

If this direction is aligned with maintainers' priorities, I would be grateful for guidance on whether you would like this to remain as a feature discussion, or whether an invited PR would be appropriate.

etraut-openai contributor · 3 months ago

This feature hasn't received enough upvotes, so closing.