Files
BFM-decomp/tools
Drew T db3fe3490b fix(lanes): raise HTTP_TIMEOUT with MAXTOK — they are one setting, not two
Probed ox-alpha directly on a real MIPS derivation:

  no reasoning cap      265.2s  finish=stop  completion=8,067  reasoning=0   30 tok/s
  reasoning cap 2000     22.3s  finish=stop  completion=  672  reasoning=0
  reasoning cap 6000     41.4s  finish=stop  completion=  618  reasoning=0

Three findings. (1) ox reports reasoning_tokens=0 — its thinking is IN the content
stream, so the output cap was capping the reasoning; that is exactly why turns ended
in 'no tool call (finish=length)'. (2) The uncapped hard prompt wanted 8,067 tokens —
it was finishing precisely where the old 8k cap cut it off. (3) It generates at ~30
tok/s, not the ~54 I estimated from turn gaps, so a full 16k generation needs ~530s
and the 420s socket would have killed the very turns the bigger budget exists to
allow. A timeout wastes the whole turn; truncation at least leaves a partial.

HTTP_TIMEOUT=700 on both drafting lanes. The ordering that must hold is generation <
HTTP_TIMEOUT (700) < stallguard's wedged-agent kill (1200s). 420 was itself deliberate
— 1800 once parked a hung agent for thirty minutes — and 700 keeps a hang under 12
minutes without strangling legitimate deep reasoning.

Also recorded: a reasoning cap DOES work on ox, but it shortens the ANSWER too (618-672
total tokens), so it is a quality knob, not a fix for truncation.
2026-08-24 16:36:47 -06:00
..