housellm: min_tokens is 3000 but its comment derives 8000 as the floor

[amiddavid]

The housellm preset sets the warm-path floor to 3000 while the comment above it documents
8000 as that floor, derived from measurement:

• config/config.go:463 — min_tokens: 3000
• config/config.go:518 — "min_tokens: 8000 is that path's floor, and it is DERIVED, not
  chosen. Measured on real warm sessions through a local proxy, an extraction call costs
  ~$0.015-0.018 and the cost is OUTPUT-dominated…"

One of the two is wrong, and which one decides whether the live deployment is correct.

Why this is not a comment typo

The comment does not merely mention a number — it records a derivation from measured call cost,
and states the floor is not a matter of taste. If the derivation is right, the shipped value is
2.7x below the measured break-even, which means the warm path is making calls the measurement
says do not pay for themselves. If the shipped value is right, then a documented derivation is
wrong and the next person to tune this floor will re-derive 8000 and "fix" the config back.

Either way the preset and its justification disagree, and this is the preset the one live
deployment runs.

What to check

Whether the 8000 derivation was superseded. Two things nearby could have moved it: min_tokens
was later joined by the derived pressure floor (pressureFloor), so an explicit floor is now one
of two mechanisms rather than the only one; and the cost basis in the comment (~$0.015-0.018 per
call, output-dominated) predates DefaultMaxTokens moving from 2048 to 4096, which changes what
an output-dominated call costs.

If 3000 is deliberate, the comment needs the reasoning that replaced the derivation, not just a
new number.

Found by

The implementation pass for #118, while migrating housellm to extract_llm_sweep. Preserved
rather than silently reconciled, because picking one of the two values is a measurement question
and guessing would bury it.

[amiddavid]

The two locations (line numbers have shifted since filing)

• config/config.go:586 — housellm sets extract_llm.min_tokens: 3000
• config/config.go:528 — 58 lines above, in the comment documenting that same preset: "min_tokens: 8000 is that path's floor, and it is DERIVED, not chosen."

(The issue cites 463/518; line 466 today is codesmart's own min_tokens: 3000, a separate preset that is not in conflict with anything.)

The derivation the comment records, step by step

This is the warm/tail path — extract_llm compacting a fresh tool output near the end of the transcript on the cheap model:

1. An extraction call costs ~$0.015–0.018, and the cost is output-dominated: shrinking the prompt barely moves it (context_messages 7 → 2 → 0 gave $0.0149 / $0.0159 / $0.0179 per call).
2. 1 in 5 calls is rejected outright and pays full price for nothing, so cost per accepted call is $0.0193.
3. The saving is priced at the cache-write rate, because the tail is being written into the cache on this turn. At that rate $0.0193 requires 4,060 saved tokens to break even.
4. Accepted tail calls reduce their candidate by ~65%, so the candidate must be ≈6,250 tokens to yield 4,060.
5. 8,000 carries the margin.

And the empirical check in the same block:

at min_tokens 1000, real sessions made 5 warm calls, accepted 4, saved 8,718 tokens for $0.0771 — net −$0.036… At 8,000 the same corpus makes zero warm calls and loses nothing, while the cold sweep still returns net +$0.062.

With the detail that matters most: those calls were admitted by the exploration budget (2 per session), not by the arithmetic. A low floor buys exploration waste, not savings.

Why 3000 is the side that looks wrong

3,000 < 6,250, so the shipped service config runs the warm path in the region its own documentation calls measurably loss-making. Every accepted call there is expected to cost more than it saves.

It compounds with #134, which is what makes this live rather than latent

Pinning the floor is not side-effect free. explicit is set by any of min_tokens, trigger.min_request_tokens, or trigger.min_output_tokens (components/offload/extract_llm.go:394-406), and shouldFire then short-circuits:

if minTokensSet { return true, "explicit min_tokens/trigger configured" }

housellm pins both min_tokens: 3000 and trigger.min_request_tokens: 3000. So on the shipped config the warm path fires on every request and does so below break-even. The pressure curve that would otherwise gate it is disabled by the very act of pinning the floor.

Scope: this is not the sweep

The same comment block (line 515) states "The sweep's floor is 1000 and not 3000", with its own derivation — at 3000 the old preset produced zero extractions across 3,437 requests, and the two accounts that measured net-positive both ran 1000. extract_llm_sweep.min_tokens: 1000 is internally consistent and is not part of this bug.

Measured on a second workload — the resolution is probably not "set 8000"

From iteration 022 (LOCA, 64k band, 14,309 tool outputs over 595 requests):

extract_llm.min_tokens	outputs at or above it
3000	2.79 per request
5000	2.24 per request
8000	1.60 per request
12000	1.09 per request

So 8,000 does not make the warm path inert here — it still admits 1.6 candidates per request. The break-even arithmetic is workload-independent, but the floor that satisfies it depends on that workload's call cost, its reduction ratio, and its output-size distribution. 8,000 was derived on production Claude Code warm sessions and is a fact about that corpus, not a constant.

Suggested resolution

Leave the floor unpinned and let pressureFloor derive it — which is what the component already does when nothing is pinned, and which #134 disables the instant anyone pins it. That addresses both issues with one change and removes the need to pick a number per workload.

Concretely for housellm: drop min_tokens and the whole trigger block from extract_llm, keep fire_on: pressure. Iteration 021's arm B ran exactly that configuration deliberately, and its config comment says why: "Pinning either sets explicit, and shouldFire() then returns true unconditionally, so the component fires on every request regardless of context size — measured at 72% of requests with request_trigger_not_fired never firing once."

If the floor must stay pinned, then the comment's derivation needs to state that it is corpus-specific and the preset needs 8,000 with a note that the number is workload-dependent. That is the weaker fix, because it leaves #134's forcing in place.

Analysis produced while configuring iteration 022, which inherited this preset verbatim. The next iteration runs the warm path unpinned.