Devotd Github
NewCoding agents

hystax/optscale-kompressor — Changes so that Monitor events are not counted as a termination

The keep-warm timer in hystax/optscale-kompressor has been changed so that it no longer treats a Monitor event as the termination of a background task, and it was fixed so that a shorter request cannot disturb the timers of other conversations.

Repositoryhystax/optscale-kompressor ↗

The keep-warm timer in hystax/optscale-kompressor has been changed so that it no longer treats a Monitor event as the termination of a background task, and it was fixed so that a shorter request cannot disturb the timers of other conversations.

GitHub description: Deterministic prompt compression for coding agents, in one Rust binary. Retrievable compression, works locally.

stars
★ 15
Forks
2
Language
Rust
License
MIT
Latest release
1.0.2
Read original source ↗View on GitHub ↗

hystax/optscale-kompressor is a project that deterministically compresses the prompts used for coding agents so that the original text can be recovered, and it runs locally as a single Rust binary. The GitHub commit 01880519a93cc9bd8090fcea323c7811fd02dbcc of November 6, 2026 changed the criterion by which this proxy's cache-keeping timer (keep-warm) decides that a background task has ended. The key point is that a Monitor event is not counted as the termination of the thing it is watching.

Monitor is a watch task that the agent has spawned, and while it is running it sends a notification for each event. Under the old rule, if even a single notification containing that task name arrived, it was counted as the end. So a watch that was still running could appear to have ended with just one event notification. The new rule ends the task only when the notification carries a status tag (completed, failed, killed) or is a 'Monitor expired' notice. Other forms of notification are treated as an end as before. Notifications are now each read only up to their own termination boundary, so two notifications contained in one message do not change each other.

The commit also came with supporting evidence. In the four captures in which such notifications arrived, tasks ending with a status tag numbered 2,952, those ending with an expiry notice numbered 38, and there was not a single instance of any other path. The failure case includes a request …0160 from train-fasttext. Under the old rule the unfinished task was not caught, so keep-warm could not fill the 408-second waiting window, and during that window 22,135 tokens were used again. The second fix is to record the number of messages in the request for each timer. Since a conversation only grows, a shorter request does not mean that that conversation has come back, and it neither cancels nor replaces the timer. The count was taken from prefix_identity, which was already parsing the request.

The limitations are also written in the commit. Rare though the case is, if a Claude Code session is rewound to an earlier point, the shortened request cannot cancel the previous timer, so that timer sends only a few more pings until the configured upper limit or until the next longest request arrives. A waiting period with only the Monitor watch left is cut off at the longest expiry time (expires in 10m). The workspace version in Cargo.toml went up from 1.5.14 to 1.5.16, the license is MIT, the change is on the order of 354 added lines and 40 deleted lines across 8 files, and a keep-warm diagram was also added. The evidence consists only of the four captures above and one failure case, so no broader measurement is presented. The scope of the change is narrowly confined to the decision rules of the keep-warm timer, so those relying on prompt cache maintenance appear to have something to check against 1.5.16.