How many? — few-shot means few.
More examples help — but only up to a point, and every one costs you.
You have seen that examples steer the answer. So here is the natural next question: if two examples help, do twenty help ten times as much? Almost never. The gains from examples 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 has already got the idea.
Meanwhile every example is more text in the prompt — more tokens (Lesson 2), which cost money and eat into the window. So past a handful you are paying more and more for less and 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).