How Much Traffic Do You Need Before Traces Are Useful?
No traffic threshold is published, and this page does not invent one. The only hard floor documented anywhere in the platform is an output floor: trace processing fails if it produces fewer than 20 examples. Everything else has to be reasoned out from the processing pipeline’s documented defaults.
Is there a published threshold at all?
No. There is no documented minimum number of requests, sessions, or days of traffic. Anyone quoting you one is guessing.
What is documented is the pipeline the traces run through and the default parameters at each stage, in the trace processing configuration reference. Those defaults are informative, because they tell you what the pipeline consumes — and what it consumes is a better guide to volume than any headline number would be.
What do the documented defaults imply?
Each stage consumes traces differently, and each one implies something different about how many you need.
| Stage | Documented parameter | Default | What it implies about volume |
|---|---|---|---|
| Splitting | — | — | Traces are deduplicated first, so distinct conversations count, not request count |
| Train seeds | num_traces_as_training_base |
200 | The pipeline uses at most 200 traces as training seeds; the surplus is not wasted, it becomes unstructured context |
| Test seeds | num_traces_as_testing_base |
200 | Another 200 at most — and ignored entirely if you supply your own test.jsonl |
| Relevance filter | min_relevance_score |
4 of 5 | A strict bar, so you need headroom above the number you want to survive |
| Coherence filter | min_coherence_score |
3 of 5 | Deliberately looser, because the committee repairs partly-corrupted traces |
| Relabelling | relabel |
true |
Only seed traces are rewritten; leftovers pass through unchanged |
| Unstructured context | max_unstructured |
10,000 | Surplus traces keep contributing up to this cap |
| Output floor | min_generated_examples |
20 | Processing errors out below this, to stop training on too little |
Read together, those numbers say something fairly specific: the seed budget is capped in the low hundreds, and everything above it changes role rather than adding seed value. Traffic past roughly 400 distinct conversations is not useless — it becomes domain context for generation — but it stops being the thing that determines whether the run works.
The deduplication step at the front matters more than it looks. If your feature answers the same handful of questions all day, ten thousand requests may collapse to a few hundred distinct conversations. Volume without variety is the failure mode here, which is the same lesson deduplication research on pretraining corpora landed on for a much larger scale.
How few traces have actually worked?
Fewer than most teams expect, provided the traces are used as seeds rather than as labels.
| Setting | Trace count | Result |
|---|---|---|
| Deliberate low-data scenario | 5 traces | 0.852 via synthetic generation vs 0.649 training directly |
| Canonical benchmark source | 327 clean traces | 0.866 synthetic vs 0.864 direct on curated data |
| Production case study | 1,107 traces | 0.6B student at 79.49% exact match vs 50.0% for the 120B teacher |
The five-trace row is the one to sit with. In our traces benchmark, those five traces expanded to roughly 2,000 generated multi-turn conversations and landed within about 1.5 points of the curated-data ceiling, while direct training on the same five collapsed. The 1,107-trace row comes from a smart-home function-calling agent, written up in from production traces to a faster, cheaper, accurate model.
How were those measured?
The benchmark used the Schema-Guided Dialogue dataset from Google Research as a controlled stand-in for production logs, holding out 34 conversations as a shared test set and scoring roughly 360 turn pairs with an LLM judge. Student model Qwen3-1.7B, LoRA rank 64, same hyperparameters across both pipelines.
That construction is why the trace counts are trustworthy as lower bounds and not as thresholds: the traces were clean by construction, then corrupted deliberately. Real traffic arrives pre-corrupted in ways nobody controls.
What changes the number you need?
Four things, in order of impact.
Task complexity. Multi-turn tool calling needs more distinct conversations than single-label classification, because there are more interaction patterns to cover.
Trace diversity. Ten distinct intents beat a thousand repetitions of one. Deduplication removes the repetitions before anything else happens.
Trace cleanliness. Relevance filtering at 4-of-5 is strict. If a large share of your logs comes from a different service or a different prompt version, expect a lot of them to be dropped — see what makes a good production trace.
Whether you supply a test set. Providing your own test.jsonl frees the entire test seed budget and gives you an evaluation set you can actually vouch for.
How do you tell whether you have enough?
Run the processing and look, rather than estimating in advance. It is cheap and it is the only honest answer.
distil upload status reports whether processing succeeded — and the 20-example floor means failure is explicit rather than silent. Then distil upload download writes out the train, test, and unstructured splits the pipeline actually produced, so you can count what survived instead of guessing what would.
If the answer comes back too thin, you have two moves: loosen min_relevance_score, or stop waiting for traffic and hand-write a seed set instead. Twenty examples is a documented starting point — see how many examples do you actually need and fine-tune with 20 examples. The full upload procedure is in turn production traces into training data.