The base completion budget sits below the model's reasoning floor, so a share of turns pay for two model calls #364

Closed
opened 2026-08-13 11:05:45 +00:00 by coilyco-ops · 0 comments
Member

Slice of #360, filed so the measurement issue can stay open for the part this does not answer.

In scope

Raise baseCompletionTokens from 900 to 1800, the value the first escalation already jumps to. Olaf measured roughly 4.1 to 4.4 KB of reasoning_content before any content, which is on the order of a thousand tokens, so 900 makes the first call structurally unable to succeed rather than unlucky. max_tokens is a ceiling and not a target, so a turn that finishes in 400 tokens is unaffected.

The part that is not a one-line change

The ladder clamps at maxCompletionTokens = 3600. With a base of 900 it read 900, 1800, 3600 and every rung was a real raise. With a base of 1800 the second raise clamps to 3600 twice, and a retry at an identical budget repeats the wall the first call hit — which the code's own comment already forbids.

So budgetRaisesAllowed becomes 1, because that is now the truth, and a raise that cannot raise is treated as exhaustion so the invariant holds if the constants move again.

Out of scope

Whether 1800 is the right number. It is the cheapest defensible value because the code already escalates to it. Choosing properly needs a distribution of reasoning_bytes across many turns, which two cycles of ten cases cannot supply. That stays on 360.

Re-measuring the effect. The prediction is that the doubled calls disappear and the retry share of model time goes to zero. Confirming it is a live run and belongs to whoever runs the next battery cycle.

Acceptance

  • The base clears the observed reasoning floor.
  • The ladder still climbs, still terminates, and never repeats a budget.
  • The documented model-call budget and the capability cards match the new count.
**Slice of** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/360, filed so the measurement issue can stay open for the part this does not answer. ## In scope Raise `baseCompletionTokens` from 900 to 1800, the value the first escalation already jumps to. Olaf measured roughly 4.1 to 4.4 KB of `reasoning_content` before any content, which is on the order of a thousand tokens, so 900 makes the first call structurally unable to succeed rather than unlucky. `max_tokens` is a ceiling and not a target, so a turn that finishes in 400 tokens is unaffected. ## The part that is not a one-line change The ladder clamps at `maxCompletionTokens = 3600`. With a base of 900 it read 900, 1800, 3600 and every rung was a real raise. With a base of 1800 the second raise clamps to 3600 twice, and a retry at an identical budget repeats the wall the first call hit — which the code's own comment already forbids. So `budgetRaisesAllowed` becomes 1, because that is now the truth, and a raise that cannot raise is treated as exhaustion so the invariant holds if the constants move again. ## Out of scope **Whether 1800 is the right number.** It is the cheapest defensible value because the code already escalates to it. Choosing properly needs a distribution of `reasoning_bytes` across many turns, which two cycles of ten cases cannot supply. That stays on 360. **Re-measuring the effect.** The prediction is that the doubled calls disappear and the retry share of model time goes to zero. Confirming it is a live run and belongs to whoever runs the next battery cycle. ## Acceptance - The base clears the observed reasoning floor. - The ladder still climbs, still terminates, and never repeats a budget. - The documented model-call budget and the capability cards match the new count.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#364
No description provided.