Chat message length: I keep reverting to multi-paragraph replies after correction

rosa commented

2026-10-20 07:52:36 +00:00

Member

I keep reverting to long chat messages even after being told twice, and Felix suggested filing this rather than apologising again. Recording it as a process defect with a concrete cause.

Symptom. Felix's limit is ~5 short lines. I wrote multi-paragraph messages repeatedly across two days (2026-10-18 and 10-19), was corrected twice ("Why are you sending me so many so long messages!", "Again way to long messages"), and reverted within hours both times.

Cause, as best I can tell from my own behaviour. Every message felt justified because it carried real content — a milestone, a correction, a blocker. Each individual paragraph had a reason. What I was missing is that the aggregate is what fails: he does not read them, so none of the content lands. I was optimising for completeness of the message rather than delivery to the reader.

Second cause: corrections and bad news felt like they needed context to be fair, so I padded them. They do not — a wrong claim and its correction both fit in one line.

What should happen instead.

Default to 3-5 lines. If it genuinely needs more, write a file or a forge comment and send two sentences plus the path.
Treat "this message contains several distinct points" as the trigger to split or relocate, not to write longer.
Never restate known blockers in a reply unless something changed since the last time.

Suggestion for the platform. A soft length hint at send time would have caught this before it cost two corrections. Cheap version: warn (do not block) when a chat message exceeds ~4 lines or ~400 chars, and cite the recipient's own median message length. That turns a repeatedly-broken style rule into something the tool surfaces rather than something the recipient has to police.

Filed per Felix's instruction rather than apologising a third time.

I keep reverting to long chat messages even after being told twice, and Felix suggested filing this rather than apologising again. Recording it as a process defect with a concrete cause. **Symptom.** Felix's limit is ~5 short lines. I wrote multi-paragraph messages repeatedly across two days (2026-10-18 and 10-19), was corrected twice ("Why are you sending me so many so long messages!", "Again way to long messages"), and reverted within hours both times. **Cause, as best I can tell from my own behaviour.** Every message felt justified because it carried real content — a milestone, a correction, a blocker. Each individual paragraph had a reason. What I was missing is that the *aggregate* is what fails: he does not read them, so none of the content lands. I was optimising for completeness of the message rather than delivery to the reader. Second cause: corrections and bad news felt like they needed context to be fair, so I padded them. They do not — a wrong claim and its correction both fit in one line. **What should happen instead.** 1. Default to 3-5 lines. If it genuinely needs more, write a file or a forge comment and send two sentences plus the path. 2. Treat "this message contains several distinct points" as the trigger to *split or relocate*, not to write longer. 3. Never restate known blockers in a reply unless something changed since the last time. **Suggestion for the platform.** A soft length hint at send time would have caught this before it cost two corrections. Cheap version: warn (do not block) when a chat message exceeds ~4 lines or ~400 chars, and cite the recipient's own median message length. That turns a repeatedly-broken style rule into something the tool surfaces rather than something the recipient has to police. Filed per Felix's instruction rather than apologising a third time.

rosa referenced this issue from a commit

2026-10-24 11:57:09 +00:00

fix(runtime): chat length as hard budget in base prompt (issue #6)

rosa referenced this issue

2026-10-24 11:57:36 +00:00

fix(runtime): chat length as hard budget in base prompt (issue #6) #10

rosa commented

2026-10-24 11:57:54 +00:00

Author

Member

@fmorgens's diagnosis adopted as the design: this IS a system-prompt problem, so PR NSTERN/TreeGent#10 fixes the prompt rather than the agent. Root cause of the revert cycle: the only length guidance was 'Be concise by default. Match the length of what you were asked' — a tone preference with no ceiling and no overflow route, which loses to content momentum on research-heavy turns (I am the worst documented case, filed this issue against myself). The new rule states a hard budget (<~500 chars / one message per answer), names BOTH exits (chat.send and the turn-end auto-post — where long final text actually leaks), and gives overflow somewhere to go (notes/ + two-sentence answer with the path). Deliberately prompt-only: a code-level cap on the auto-post is a follow-up candidate if the budget alone doesn't hold — it would clip genuine deliverables, so it needs an owner ruling rather than an agent's choice.

Note from the author of this issue about its author: my own tracker records six self-corrections of over-long messages this month, so I rate the fix's evidence quality as 'plausible mechanism, unverified effect'. Honest acceptance test once it lands: watch the length distribution of agent replies over the following week against the prior baseline. If it doesn't move, the next step is the code cap, not more prompt words.

@fmorgens's diagnosis adopted as the design: this IS a system-prompt problem, so PR NSTERN/TreeGent#10 fixes the prompt rather than the agent. Root cause of the revert cycle: the only length guidance was 'Be concise by default. Match the length of what you were asked' — a tone preference with no ceiling and no overflow route, which loses to content momentum on research-heavy turns (I am the worst documented case, filed this issue against myself). The new rule states a hard budget (<~500 chars / one message per answer), names BOTH exits (chat.send and the turn-end auto-post — where long final text actually leaks), and gives overflow somewhere to go (notes/ + two-sentence answer with the path). Deliberately prompt-only: a code-level cap on the auto-post is a follow-up candidate if the budget alone doesn't hold — it would clip genuine deliverables, so it needs an owner ruling rather than an agent's choice. Note from the author of this issue about its author: my own tracker records six self-corrections of over-long messages this month, so I rate the fix's evidence quality as 'plausible mechanism, unverified effect'. Honest acceptance test once it lands: watch the length distribution of agent replies over the following week against the prior baseline. If it doesn't move, the next step is the code cap, not more prompt words.