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, we ask each question several times both ways (all N in one request, and one question per request) and compare the run-to-run std dev: how far an answer moves from one repeat to the next. Batching adds no noise. Most answers came back identical across all 5 repeats either way, std dev exactly 0.0. Cost and speed do change. The document dominates every request. N single-question calls pay for it N times, in N round trips; the batched call pays once. The bigger the document, the nearer that saving comes to a full Nx. The case here is a regulatory briefing. The document is the Wikipedia article on the GDPR (~54,000 characters), and a compliance team wants 13 things checked: 8 Noul questions, 2 Choice questions, and 3 Score questions.

Setup

then set TYPESAFE_API_KEY. To replay the published numbers without an API key, download json_cache.json from typesafe-public-examples into the folder you run the script from.

The document: the Wikipedia article on the GDPR

We fetch the article as plain text from a pinned revision and cache it 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

We track one number 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 divided by the top level, so it runs 0-1. criteria lists the level descriptions, from level 0 up.

Ask two ways, 5 times each

Each call sends some of the questions with the document, and we reduce each answer to its one tracked number. The document is byte-identical in every call. Both batching strategies run RUNS = 5 times, enough to compare the mean (do the two agree?) and the std dev (does batching add noise?). Calls are cached to json_cache.json; delete it to re-run live.

Batching doesn’t change the answers

For each question, the table shows the mean and std dev of its tracked number over the 5 runs under each batching strategy. A mean that shifts between the batched and single columns would be bias; a larger std dev would be noise.
  • Choices, scores, and six of the eight nouls come back identical across the 5 repeats: std dev exactly 0.0 under both batching strategies. One call with N questions gives the same answers as N calls with one question each.
  • breach_72h and criminal_penalties 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, not of how you batch: batching neither shifts the answer nor adds variance.

The only difference: cost and speed

The ~54,000-character article dominates every request, so:
  • Cost: 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 table 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.
Cost and time are averaged over the 5 runs.

Open it in the TypeSafe playground

The share link packs the same article and 13 questions. Open it to re-run the briefing live.
Open this article + questions in the TypeSafe playground →