How many? — few-shot means few.
More examples help — but only up to a point, and every one costs you.
Examples steer the answer, so the greedy next thought is obvious: if two help, surely twenty help ten times as much? Almost never. The gains fade fast.
The first example does the heavy lifting — it shows the model the pattern. The second and third sharpen it. After that, each extra example barely moves the answer: the model already has the idea.
Yet every example is more text in the prompt — more tokens (Lesson 2), which cost money and eat into the window. Past a handful you are paying steadily more for steadily less.
The practical rule is to use the fewest examples that lock the pattern — usually two or three. “Few-shot” really does mean few.
Drag the number of examples up. Watch reliability shoot up, then flatten — while the token bill keeps climbing in a straight line.
Same call, more examples.
Nothing changes in the code but the count. The reliability it buys saturates; the token cost does not.
Few, not many.
A couple of examples buys most of the reliability you are ever going to get. Beyond that the curve flattens, but the token cost keeps rising in a straight line — so you pay more and more for almost nothing.
Use the fewest examples that lock the pattern — usually two or three. If that is not enough, the answer is better examples, not more of them (next page).