feat(threads): read every thread whole, dropping the per-channel toggle #834

Merged

coilysiren merged 1 commit from aos/claude/wy58-thread-prefill-always into main

2026-08-15 20:03:51 +00:00

coilyco-ops commented

2026-08-15 17:28:22 +00:00

Member

Closes #769. Follow-on to #827, which landed the feature behind a toggle.

What this does

I don't remember asking for a per channel toggle :p. This doesn't seem like a per channel thing, remove that filter condition

So the filter condition goes. A turn inside a thread reads the whole thread everywhere, with nothing to configure.

Removed: SIRENS_ECHO_THREAD_PREFILL_CHANNELS, the boot check that a named parent channel is admitted, the opted-in count on discord.ready, and threadPrefillOn itself.

Everything #827 built stays untouched - the bounded walk, the Capped floor and its at least hedge, oldest-first dropping, the annotation as a service-authored suffix. Only the condition in front of it changed.

The consequence nobody asked for, named rather than absorbed

Removing the toggle removed the staged rollout with it. The spec's plan was ship-off, measure a long thread, then enable per channel. Nothing gates this on one channel now, so threadPrefillBytes (32 KiB) and threadPrefillReads (10 pages) carry the whole context risk on their own, on every thread turn rather than an opted-in few.

history.thread.read and history.thread.dropped on the community.history span are how to see what real threads produce. If you want a measure-first step back, lowering threadPrefillBytes and raising it once you have numbers is the cheap version.

The retired env var is inert, not fatal

A deployment still carrying SIRENS_ECHO_THREAD_PREFILL_CHANNELS loads fine rather than failing boot, pinned by a test. coilyco-bridge/deploy never set it - checked, not assumed - so nothing needs cleaning up there.

Tests

Four toggle tests removed, because they describe a knob that no longer exists. Two added:

every thread reads whole with nothing configured, and the MaxContextMessages window limit does not bound it (250 messages read against limit: 3)
a stale retired env var still loads

Verification

ward gate green: build, policy-check, vet, test, test-skips, pre-commit.

Note on #832

I opened #832 earlier today with a second, independent implementation of this issue. #827 merged five minutes after I branched and I did not re-check main before pushing. #832 is closed as duplicate with the details recorded there; #827's implementation is the better one and is what this builds on.

🤖 Generated with Claude Code

Closes #769. Follow-on to #827, which landed the feature behind a toggle. ## What this does > I don't remember asking for a per channel toggle :p. This doesn't seem like a per channel thing, remove that filter condition So the filter condition goes. A turn inside a thread reads the whole thread everywhere, with nothing to configure. Removed: `SIRENS_ECHO_THREAD_PREFILL_CHANNELS`, the boot check that a named parent channel is admitted, the opted-in count on `discord.ready`, and `threadPrefillOn` itself. Everything #827 built stays untouched - the bounded walk, the `Capped` floor and its `at least` hedge, oldest-first dropping, the annotation as a service-authored suffix. Only the condition in front of it changed. ## The consequence nobody asked for, named rather than absorbed Removing the toggle removed the staged rollout with it. The spec's plan was ship-off, measure a long thread, then enable per channel. Nothing gates this on one channel now, so `threadPrefillBytes` (32 KiB) and `threadPrefillReads` (10 pages) carry the whole context risk on their own, on every thread turn rather than an opted-in few. `history.thread.read` and `history.thread.dropped` on the `community.history` span are how to see what real threads produce. If you want a measure-first step back, lowering `threadPrefillBytes` and raising it once you have numbers is the cheap version. ## The retired env var is inert, not fatal A deployment still carrying `SIRENS_ECHO_THREAD_PREFILL_CHANNELS` loads fine rather than failing boot, pinned by a test. `coilyco-bridge/deploy` never set it - checked, not assumed - so nothing needs cleaning up there. ## Tests Four toggle tests removed, because they describe a knob that no longer exists. Two added: - every thread reads whole with nothing configured, and the `MaxContextMessages` window limit does not bound it (250 messages read against `limit: 3`) - a stale retired env var still loads ## Verification `ward gate` green: build, policy-check, vet, test, test-skips, pre-commit. ## Note on #832 I opened #832 earlier today with a second, independent implementation of this issue. #827 merged five minutes after I branched and I did not re-check `main` before pushing. #832 is closed as duplicate with the details recorded there; #827's implementation is the better one and is what this builds on. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-15 17:28:22 +00:00

feat(threads): read every thread whole, dropping the per-channel toggle

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

Details

ci / test (pull_request) Successful in 40s

Details

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

Details

ci / publish-observed (pull_request) Has been skipped

Details

9d2914edda

#827 landed whole-thread prefill behind SIRENS_ECHO_THREAD_PREFILL_CHANNELS,
following the design pass. Kai then said on the issue that she did not ask for
a per-channel toggle and that this is not a per-channel thing, so the filter
condition goes.

A turn inside a thread now reads the whole thread everywhere, with nothing to
configure. Gone with the toggle: the env var, the boot check that a named
parent channel is admitted, the opted-in count on discord.ready, and
threadPrefillOn itself.

The retired env var is inert rather than a boot failure, so a deployment still
carrying it cannot take the service down. coilyco-bridge/deploy never set it,
checked rather than assumed, so nothing needs cleaning up there.

Everything #827 built stays: the bounded walk, the capped-read floor and its
`at least` hedge, oldest-first dropping, and the annotation. Only the condition
in front of it changed.

Worth naming, because it follows from removing the toggle rather than from
anything asked for: the staged rollout is gone too. The spec's plan was
ship-off, measure a long thread, then enable per channel. Nothing gates this on
one channel now, so threadPrefillBytes and threadPrefillReads carry the whole
context risk. `history.thread.read` and `history.thread.dropped` on the
community.history span are how to see what real threads produce.

Four toggle tests are removed because they describe a knob that no longer
exists. Two replace them: every thread reads whole with nothing configured and
the window limit does not bound it, and a stale env var still loads.

Closes #769

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-15 17:28:22 +00:00

coilyco-ops referenced this pull request

2026-08-15 17:28:39 +00:00

feat(threads): prefill the whole thread when a turn is inside one #832