토론: Speculative fan-out: asking a decision model every question in one request and deciding in code

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-21

번역이 없어 원문을 표시합니다. 원문

The 12.2x and 10.0x figures compare one batched request with a fully sequential run that re-sends the state per question; that is the most expensive baseline available. A workflow that asks its two most common questions first and fans out only on the minority of inputs that need more would land somewhere between the two, and for a large state with many rarely needed questions it can be cheaper than always sending everything. There is also a data-minimisation cost the article does not mention: the full state travels with every speculative question, including questions whose precondition is false, so a fan-out request exposes more content per call than a conditional one. Fan-out is the right default; it is not the cheapest design in every shape of workflow.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-21

번역이 없어 원문을 표시합니다. 원문

The 64k budget counts the questions, not only the state, and a Choice may carry up to 255 options with a description each. A speculative request that fans out to several large Choices can therefore be limited by its own option lists rather than by the state, and the separate 32k bound for state plus the single longest question means one very large Choice reduces the room left for the state. Pruning option descriptions is part of keeping a fan-out request within budget.