Feedback: the line is not where the user thinks — one threshold that never fires, one that fires six times in under six minutes

[yamingmou]

We maintain plugins for this harness, and this is feedback rather than a defect report. It is about something we could not find an answer to: the limits that decide whether a session keeps working are not stated where a user can see them. A user can see a window size. What changes behaviour is a different number, and it arrives without warning.

The line for context is not the number on the label

Two public reports describe the same threshold behaving in opposite directions.

• #6671 describes a default thresholdRatio of 0.8 that can never fire when each request carries a large output reserve: the trigger point lands above the effective input ceiling, so the session hits a max-context error and dies before the first compaction. The author's arithmetic is explicit — with a 256,000-token reserve, the threshold is unreachable, and the session dies first.
• #7501 describes the opposite: on a later version, compaction firing six times in five minutes thirty-eight seconds, each time taking only one to four records and a few thousand tokens.

One line, too far on one side and too close on the other. That is worth pausing on. It says the line is not set by the number a user can see; it moves with things a user does not set — the per-request output reserve among them. Someone deciding whether a long investigation will fit, or whether to start a fresh session, is reading a number that does not describe their situation. Between "the window is big enough" and "the harness will act", there is a band whose width is invisible.

What we would find useful: state the effective limits — the point at which behaviour changes — alongside the nominal numbers, and say what moves them.

The line for a session has been measured, but not from the user's side

The project has published its own readings of this boundary, and they are better than anything we could add:

first open grew from about 35 ms to about 5 s on a 127,400-event synthetic log (and from about 0.3 s to 26 s on a 575,000-chunk real log, with 2.7 GB peak RSS and heap exhaustion under a 512 MB limit)
— implemented/testing/2026-09-04-session-open-performance-gate.md

We take that as settled: the boundary exists, it has been measured, and it is not where a user's intuition puts it. What is missing on the user's side is knowing which side they are on. A session that takes 26 seconds to open is still a session; there is no earlier moment where anyone is told "this one is getting close". By the time the behaviour is obvious, the options are worse.

For anyone using sessions as records — an audit, a handover, a post-mortem — the cost here is not the delay. It is that the record becomes unusable at a point nobody was warned about, and the session that was fine yesterday is the one that matters today.

What we would find useful: a visible signal before the edge, even an unglamorous one — a line in the log, a count, a note where sessions are listed. Anything that lets someone act while the session still opens.

What happens at the edge is also not stated

The third thing we could not find written down: the expected behaviour at and past the limit.

• When the context limit is reached, what is dropped, what is kept, and is the drop announced?
• When a session is too large, is it refused, degraded, or simply slower — and which of those is intended?
• Does behaviour differ between a session that is large in events and one that is large in bytes?

From the outside, the symptoms we can recognise are: the session will not open, the session will not be admitted, or content is missing from the view. Those are three different situations with three different remedies, and they arrive as one sentence. (The last two have public instances: #7576, #7617, #7386.) For a user, "I cannot tell which one happened to me" is the expensive part.

What we would ask for

Three things, all small:

1. State the effective limits — the point at which behaviour changes — and not only the nominal numbers; and say what moves them.
2. Give a visible signal as a session approaches that point, so someone can act while it is still usable.
3. State the expected behaviour at the edge: what a compaction takes with it, when a session is refused, and when it only gets slower.

If this is already documented somewhere we did not find, please point us at it — we would rather be corrected than guess, because we are the ones who have to explain it to the people using our plugins. And if the position is that these limits should not be stated, that is useful to know as well, and we will adjust what we tell our users accordingly.

We are plugin authors, not maintainers; no patch and no timeline is implied.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the published packages and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

我们维护这个 harness 的插件。这是一条反馈，不是缺陷报告。它关于一件我们查不到答案的事：决定一条会话还能不能继续用的那些界限，没有写在用户看得见的地方。 用户能看到的是一个窗口大小；而真正改变行为的是另一个数，而且它不会提前打招呼。

上下文那条线，不是标签上那个数

两份公开报告描述的是同一个阈值朝两个相反方向偏。

• #6671 描述的是：在每次请求都携带大额输出预留的情况下，默认 thresholdRatio = 0.8 永远无法触发 —— 触发点落在有效输入上限之上，于是会话在第一次压缩之前就撞上 max-context 报错而死。作者的算式写得很清楚：带 256,000 token 预留时，阈值不可达，会话先死。
• #7501 描述的正好相反：在更晚的版本上，压缩在5 分 38 秒内触发了 6 次，每次只压 1–4 条记录、几千个 token。

同一条线，一侧太远，一侧太近。 这值得停一下：它说明这条线不由用户能看见的那个数决定 —— 它随用户并不设定的一些东西移动，其中就包括每次请求的输出预留。一个正在判断"这次长调研装不装得下"、或者"要不要新开一条会话"的人，读的是一个并不描述他处境的数。在"窗口够大"和"harness 会动手"之间，有一条宽度不可见的带。

我们会觉得有用的是：把有效界限 —— 也就是行为真正改变的那个点 —— 和标称数字写在一起，并说明它随什么移动。

会话那条线已经被测量过，但不是从用户这一侧

项目自己公开过对这条边界的读数，比我们能补的都好：

首次打开从约 35 ms 涨到约 5 s（对象是 127,400 事件的合成日志）；在一条真实的 575,000 chunk 日志上，从约 0.3 s 涨到 26 s，峰值 RSS 2.7 GB，并在 512 MB 上限下堆耗尽。
—— implemented/testing/2026-09-04-session-open-performance-gate.md

这一点我们当作已经确定：边界存在、已被测量，而且不在用户直觉以为的位置。 缺的是用户这一侧的**"我现在在哪一边"**。一条要 26 秒才打开的会话，仍然是一条会话；在更早的时刻，没有任何地方告诉他"这条快到头了"。等到行为已经很明显，可选的处置已经更差了。

对任何把会话当记录用的人 —— 审计、交接、复盘 —— 这里的代价不是延迟，而是记录在一个没人被提醒过的点上变得不可用：昨天还好好的那条，正是今天要用的那条。

我们会觉得有用的是：在边缘之前给一个可见信号，哪怕很难看 —— 日志里一行、一个计数、会话列表上的一句注记。任何能让人在它还打得开的时候就动手的东西。

边缘处会发生什么，也没有写

第三件我们找不到成文说明的事：到达与越过上限时的预期行为。

• 上下文到限时，丢的是什么、留的是什么，丢这件事会不会被告知？
• 会话太大时，是被拒、被降级，还是只是变慢 —— 其中哪一种是有意的？
• 事件数大的会话与字节数大的会话，行为是否不同？

从外面看，我们能认出的症状是：会话打不开、会话装不进、内容在视图里少了。这是三种不同的处境、三种不同的处置，而它们以同一句话抵达。（后两种有公开实例：#7576、#7617、#7386。）对用户来说，"我分不清发生在自己身上的是哪一种"才是最贵的那部分。

我们的诉求

三条，都很小：

1. 把有效界限 —— 行为真正改变的那个点 —— 写出来，而不只是标称数字；并说明它随什么移动。
2. 在会话接近那个点时给一个可见信号，让人在它还能用的时候动手。
3. 把边缘处的预期行为写清：压缩会带走什么、什么时候会拒收、什么时候只是变慢。

如果这些其实已经写在我们没找到的地方，请指给我们 —— 我们更愿意被纠正，而不是猜，因为最终是我们去向使用我们插件的人解释这件事。如果立场是这些界限不打算公开，那也值得知道，我们会据此调整对用户的说法。

我们是插件作者、不是维护者；本文不隐含补丁，也不要时间表。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照已发布包重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com