Speculative fan-out
Speculative fan-out: send many questions in one request, including questions that only matter for some inputs. If the ticket is not a bug, ignore severity. You already paid a few question tokens and almost no extra latency.
This page is for builders crossing from curious to production-minded Jev use. jev.pro is an independent unofficial field guide — not affiliated with TypeSafe AI. Cover intents; do not clone rival IA. Confirm facts on docs.typesafe.ai.
TypeSafe publishes a Parallel questions cookbook that runs a multi-question briefing over a long Wikipedia article and reports that batching beats one-question-per-call on both cost and latency, with no change in answers. Their docs index and primitives page quote slightly different multiples for that cookbook; we will not pick a number. Read the cookbook for the current figure.
Why answers stay stable
Questions are independent. Extra questions are not supposed to rot the others’ context. (Unrelated state still can; that is a different warning.)
Agent habit to break
One question per HTTP call wastes the request budget and re-sends state. Install the agent skill so tools batch.
When a second request is truly required — you need the first answer to fetch documents or to build the next option list — that is sequential workflow, not fan-out. TypeSafe calls out skill suggestion, structure recovery, and hierarchical classification as examples that earn a second round trip.
Worked sketch: listing-moderation extras
A real-estate marketplace screens a new listing. Ask category plus extras you will ignore when they do not apply. Official fan-out pattern uses a support ticket — cite speculative fan-out; this sketch is listing copy.
{
"listing": "Sunlit 2BR. 'Guaranteed 12% rental yield.' Owner financing. Photos look like a hotel brochure."
}
| Id | Type | Speculative? |
|---|---|---|
kind |
Choice | sale / rent / room / other — always used |
yield_claim |
Noul | Only matters if copy mentions return % |
owner_finance |
Noul | Only matters for sale |
stock_photo |
Noul | Photo-policy flag; ignore if no image text |
tone |
Score | brochure vs factual (3 levels) |
kind = answers["kind"]
if kind.choice == "sale" and answers["owner_finance"].noul >= T:
flags.append("owner_finance")
if answers["yield_claim"].noul >= T:
flags.append("yield_claim")
# if kind is rent, owner_finance is ignored — already paid
TypeSafe’s latency claim: extra questions are evaluated in parallel and usually add little wall time. Treat that as a vendor claim; measure usage and your p99. Extra questions still add input tokens at $0.042 / M (vendor claim). Filter state — do not POST the whole MLS dump (jev-1.13 large-state jaggedness).
Pin jev-1.13.0. POST https://api.typesafe.ai/v1/systemone. Jaggedness: no math on “12%”; extract numbers in code.
When not to use
- The next question’s options depend on the first answer (cascade / hierarchy) — second round trip.
- You are issuing many rows (different listings) — that is bulk, not fan-out on one state.
See also
FAQ
Does fan-out mean many HTTP calls?
No. That is the anti-pattern. One POST, many questions.
Will extra questions change cost a lot?
State is ingested once. Extra questions add tokens. Measure usage — we will not invent a multiple.
Multi-row batch?
Different problem — bulk imports.
Official latency multiple?
Vendor claim on the parallel-questions cookbook. We will not pick a number their pages disagree on.
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.