The load-bearing piece of this design is the allowlist, not the compression. GitHub sorted tool output by command class after reading its own benchmark runs, which showed that install, build, test and lint output tends to carry repetitive noise while source-like output and arbitrary command results tend to carry the thing the agent actually needs next [6]. That is a bet about where information density lives in a shell session, and it was derived from traces rather than from first principles [6].
The failure that produced the allowlist is more instructive than the policy. An early version compressed `git diff`. Benchmark tasks then showed agents reopening the original output to recover what had been stripped, and the filter was removed; GitHub says early versions were aggressive enough to make the model repeat work and reduce task success [10]. The RTK evaluation had already produced the same pattern from the outside, with shorter individual responses and tasks that on average used more tokens and took longer [5]. GitHub's conclusion is that tokens per tool call is the wrong objective, and that an efficiency change has to be measured from the user's request through the final result [11].
A compressor that mostly declines to compress is an odd thing to ship, and the post says as much: it is conservative because that is what the evaluations supported, not because conservatism was the goal [12].
The instrumentation is the part I would copy first. Compressed output keeps a direct recovery path to the complete original [8], and the team tracks whether the agent opened that saved original, reran commands, repeated exploration, narrowed its searches, or took additional turns [9]. Frequent recovery means the compressor removed something valuable [9]. So the safety valve doubles as the regression metric, which is cheap to add to any harness that already logs tool calls.
What the post does not give you is a magnitude. Across the four shipped changes and the RTK evaluation, there is no percentage, no token count, and no latency figure, only direction [1]. Offline agentic benchmarks picked the candidates and controlled online experiments validated the promising ones before shipping [2], but without the deltas you cannot size the win against the maintenance cost of a command-class allowlist.
For the RTK result to transfer to your setup, three things have to hold: your model recovers the same way when text goes missing, your build and test commands are verbose in the same proportion, and rerunning a command in your harness is cheap enough that the model prefers it to reasoning around the gap. GitHub fences the claim itself, saying it applies to the integration and workloads tested rather than to every RTK configuration or to output compression in general [11]. The examples are from Copilot CLI, with the Copilot app and Copilot code review sharing the same harness [3].
The other three changes get one line each: strip formatting that adds nothing, shorten instructions without changing useful behaviour, and hand back completed background work without a second retrieval [1]. That last one is the same principle pointed at a round trip instead of a payload.
