Skip to main content
You have one document and N questions about it. You can send one request with all N questions, or N requests with one question each. With TypeSafe the answers come out the same either way: each question is scored on its own against the document, so its answer doesn’t depend on what else is in the request. To check that, this cookbook asks both ways several times and compares the run-to-run std dev - how far each answer moves from one repeat to the next. Whatever noise a question type has, it is the same under both batching strategies (all N in one request, or one question per request); batching adds none. Each noul comes back bit-identical across all 5 repeats either way - the same value on every call, std dev exactly 0.0. The one thing that does change is cost and speed. The document dominates every request, so N single-question calls pay for it N times and make N round trips, while the batched call pays once. The bigger the document, the closer the saving gets to a full Nx. The case here is a regulatory briefing. The document is the Wikipedia article on the GDPR (~54,000 characters, a document-dominated workload where the document is most of every request), and a compliance team wants 13 things checked: 8 Nouls, 2 Choices, and 3 Scores.

Setup

then set TYPESAFE_API_KEY.

The document: the Wikipedia article on the GDPR

Fetched as plain text from a pinned revision of the article and cached in json_cache.json next to the API calls, so the document - and its numbers - stay fixed even as the live article gets edited.
📄 Read the pinned Wikipedia revision

The questions: 8 nouls + 2 choices + 3 scores

One number tracked per answer, by type:
  • Noul: the probability of “yes”.
  • Choice: the max prob, the probability on the picked label. criteria maps each label to its meaning.
  • Score: the score normalized to 0-1, the score divided by the top level. criteria lists the level descriptions, from level 0 up.

Ask two ways, 5 times each

ask() sends any subset of the questions with the document and reduces each answer to its one tracked number. The document is byte-identical in every call. Both batching strategies run RUNS = 5 times, giving each question 5 answers per strategy, enough to compare the mean (do the two agree?) and the std dev (does batching add noise?). Calls are cached to json_cache.json, which ships with the cookbook, so re-rendering is free; delete it to re-run live.

Batching doesn’t change the answers

Per question: the mean and std dev of its tracked number over the 5 runs, under each batching strategy. If batching changed the answers, the batched columns would differ from the single columns - a shifted mean (bias) or a larger std dev (noise).
Reading the table by question type:
  • Nouls come back bit-identical across the 5 repeats: std dev exactly 0.0 under both batching strategies, every batched and single call returning the same probability. One call with N nouls gives the same answers as N calls with one noul.
  • Choices and scores carry a little run-to-run sampling noise, and it’s the same size under both batching strategies, with the means agreeing to within that noise. The noise is a property of the question type, not of how you batch: batching neither shifts the answer nor adds variance.
Either way, there is no batching effect: no question’s answer depends on the 12 other questions sharing its request.

The only difference: cost and speed

Same answers, different bill. The ~54,000-character article dominates every request, so:
  • Cost (the robust number): the 13 single-question calls re-send the article 13 times; the batched call sends it once. This saving holds however you fire the calls.
  • Speed: the figure sums the 13 single-call latencies, so it assumes they run one after another. Fire them concurrently and the gap shrinks, but the 13x token cost stays.
Costs and latencies are averaged over the 5 runs and cached alongside the answers.

Open it in the TypeSafe playground

The same article and the same 13 questions, packed into a share link. Open it to re-run the briefing live; the same numbers come back.
Open this article + questions in the TypeSafe playground →