fix: ask the titler for the length the thread title bound allows #919

Merged

coilysiren merged 1 commit from issue-904-thread-title-length into main

2026-08-17 19:21:44 +00:00

coilyco-ops commented

2026-08-17 18:35:20 +00:00

Member

The clip was never a truncation. Fixes what actually decided title length.

What was happening

threadTitleRunes was 50 and threadNameRunes was 100. Neither is near thirty, and nothing else trims a title. The titler was asked to "name this request in at most six words", and six words is about thirty characters. So the bound was a ceiling the model never approached, and the reported clip was the model complying with its instructions.

Raising the cap alone, which is what the issue asks for on its face, would have changed nothing a member could see.

What changed

SIRENS_ECHO_THREAD_TITLE_WORDS, default 9, a new knob in config.go. threadTitlePrompt becomes a function built from it, the same shape threadTitleRetryPrompt already had for the rune bound.
SIRENS_ECHO_THREAD_TITLE_RUNES 50 to 60, the value the scope update asked to pin.
agent/rendered/knobs.txt regenerated by just knobs.

Nine words reaches roughly 54 characters, inside the 40 to 60 range, and under the 60 ceiling so the regeneration path does not start firing on every title.

The issue's second ask

"Confirm whether the earlier clip fix is still in place so the two truncations are not mistaken for one." Both are, and neither is this:

threadNameRunes at 100 bounds the derived name at Discord's own cap, in threadNameFrom.
Regenerating an over-long title rather than trimming it, from sirens-echo#753, is unchanged. The hard trim is still the second-failure fallback and still records thread.title.trimmed.

There were two bounds and one instruction, and the instruction was the binding one.

Tests

TestTheTitlerIsAskedForTheLengthTheBoundAllows asserts the word budget reaches the prompt, that the reachable length clears the 40 floor, that the rune bound sits in the 40 to 60 range, and that the words do not overshoot the bound.

TestAnOverLongTitleIsRegeneratedWithTheLimitStated asserted the literal string "50 characters", which is how a bound change strands a test. It now builds the sentence from the knob.

just gate PASS.

closes #904

The clip was never a truncation. Fixes what actually decided title length. ## What was happening `threadTitleRunes` was 50 and `threadNameRunes` was 100. Neither is near thirty, and nothing else trims a title. The titler was asked to **"name this request in at most six words"**, and six words is about thirty characters. So the bound was a ceiling the model never approached, and the reported clip was the model complying with its instructions. Raising the cap alone, which is what the issue asks for on its face, would have changed nothing a member could see. ## What changed * `SIRENS_ECHO_THREAD_TITLE_WORDS`, default **9**, a new knob in `config.go`. `threadTitlePrompt` becomes a function built from it, the same shape `threadTitleRetryPrompt` already had for the rune bound. * `SIRENS_ECHO_THREAD_TITLE_RUNES` **50 to 60**, the value the scope update asked to pin. * `agent/rendered/knobs.txt` regenerated by `just knobs`. Nine words reaches roughly 54 characters, inside the 40 to 60 range, and under the 60 ceiling so the regeneration path does not start firing on every title. ## The issue's second ask **"Confirm whether the earlier clip fix is still in place so the two truncations are not mistaken for one."** Both are, and neither is this: * `threadNameRunes` at 100 bounds the derived name at Discord's own cap, in `threadNameFrom`. * Regenerating an over-long title rather than trimming it, from sirens-echo#753, is unchanged. The hard trim is still the second-failure fallback and still records `thread.title.trimmed`. There were two bounds and one instruction, and the instruction was the binding one. ## Tests `TestTheTitlerIsAskedForTheLengthTheBoundAllows` asserts the word budget reaches the prompt, that the reachable length clears the 40 floor, that the rune bound sits in the 40 to 60 range, and that the words do not overshoot the bound. `TestAnOverLongTitleIsRegeneratedWithTheLimitStated` asserted the literal string `"50 characters"`, which is how a bound change strands a test. It now builds the sentence from the knob. `just gate` PASS. closes #904

coilyco-ops added 1 commit

2026-08-17 18:35:20 +00:00

fix: ask the titler for the length the thread title bound allows

ci / image-build (pull_request) Successful in 35s

Details

ci / test (pull_request) Successful in 58s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

e2ae8bb787

Thread titles read as clipped at around thirty characters, and nothing was
truncating them there. threadTitleRunes was 50 and threadNameRunes was 100,
neither near thirty. The titler was asked to "name this request in at most six
words", and six words is about thirty characters. The bound was a ceiling the
model never approached, so raising it alone would have changed nothing a
member could see.

The word budget becomes a knob, SIRENS_ECHO_THREAD_TITLE_WORDS, default nine,
and the prompt is built from it the way the retry prompt is already built from
the rune bound. threadTitleRunes goes 50 to 60, the value the scope update on
the issue asked to pin.

Both earlier truncations are still in place and are not this one:
threadNameRunes at 100 is Discord's cap on the derived name, and regenerating
rather than trimming an over-long title is unchanged from sirens-echo#753.

The regeneration test asserted the literal "50 characters", so it now builds
the sentence from the knob and cannot strand again.

closes #904

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-17 18:35:20 +00:00

coilyco-ops referenced this pull request

2026-08-17 18:35:40 +00:00

Discord thread titles are clipped at ~30 characters #904