Few-shot prompting: examples in the request instead of long explanations

Few-shot prompting means putting a few "input → correct output" examples right in the request. Instead of describing the format at length, you show two or three samples and the model continues in the same way. It's a useful technique, but the examples are sent with every request and cost tokens. Below: when few-shot helps, how to format examples, the most common mistakes, and how to work out whether the examples pay off.

How few-shot works

Zero-shot, no examples:

The model decides the formatting itself: whether to add an explanation, whether to wrap the JSON in a code block, whether age is a string or a number.

Few-shot, with examples:

The examples pin down the format better than any description: age is a number, there's no extra text, and the input can vary.

When few-shot helps

Unusual output formats. Internal markup, a specific report layout, a strict field order — anything that's hard to describe in words.

Non-obvious classification rules. For example, you need the sentiment plus a short reason:

Your own syntax. If the answer must follow your system's format, one sample often beats a paragraph of explanation:

When you don't need examples

• A simple answer. If you need one word from a short list ("positive, negative or neutral"), an instruction with the options is enough.
• A format defined by a schema. For JSON you can describe the fields and types, or use structured output if your client supports it.
• Lots of similar examples. Ten near-identical samples add little over three varied ones, yet cost three times as many tokens.

How to format examples

As messages (recommended for the API)

Each example is a user/assistant pair, and the real request comes last:

messages = [
    {"role": "system", "content": "Classify sentiment. Answer with one word: positive, negative or neutral."},
    {"role": "user", "content": "Delivery was a week late"},
    {"role": "assistant", "content": "negative"},
    {"role": "user", "content": "The courier arrived ahead of schedule"},
    {"role": "assistant", "content": "positive"},
    {"role": "user", "content": "The order arrived on the usual date"},
    {"role": "assistant", "content": "neutral"},
    {"role": "user", "content": "Great service, thank you!"},
]

The model sees the examples as its own earlier answers, and the boundary between samples and the real request stays clear.

In a single text

When the interface only lets you send one message, use explicit labels and identical formatting for every example:

Common mistakes

Real data in examples

If your samples contain real numbers, addresses or names, the model may carry them over into an answer for a different request. For masking and extraction tasks use obviously synthetic values: 000-00-0000, user@example.com.

Skewed examples

If all three examples are negative reviews, the model will answer "negative" more often. If all inputs are short, long texts may be handled worse. Pick samples that cover different classes and different kinds of input.

A mistake in a sample

The model repeats what it sees. A typo in a JSON key or a wrong answer in one example will show up in the output. Check examples as carefully as code.

Examples that are too similar

If the samples are nearly identical, the model may copy their structure where the task needs something else. Three to five varied examples are enough.

What examples cost

Examples are sent with every request as input tokens. The formula:

example cost = example_tokens × number_of_requests × input_price / 1,000,000

Zukko prices per 1M tokens (input and output are the same): claude-sonnet-5 and gpt-5.6-sol — $0.3, glm-5.3 — $0.1, glm-5.3-flash — $0.04. For the current model list and prices, call GET https://api.zukko.pro/v1/models or open the Models page in your dashboard.

Example: five examples of 50 tokens each, 250 tokens per request.

• 10,000 requests × 250 tokens = 2,500,000 tokens;
• on claude-sonnet-5: 2.5 × $0.3 = $0.75;
• on glm-5.3-flash: 2.5 × $0.04 = $0.10.

Do the examples pay off? Say answers average 500 tokens without them and 400 with them. You save 100 output tokens per request but spend 250 on examples. In Zukko input and output cost the same, so comparing tokens is enough: 400 + 250 = 650 versus 500. With examples, it costs more. On answer length alone, the examples only pay off if they cut it by at least 250 tokens, that is, in half. In practice few-shot usually pays off another way: fewer bad answers, fewer retries and fewer manual fixes. That's what you should measure.

A caveat about caching: with vendors, a repeated prompt prefix can be cached, and cache reads cost about 10% of the input price. Zukko bills cached tokens at the normal input price. So for requests with a large identical block of examples, the gap versus official pricing is smaller than a straight price comparison suggests.

Code: few-shot in Python

from openai import OpenAI

client = OpenAI(
    base_url="https://api.zukko.pro/v1",
    api_key="fetch_your_key",
)

EXAMPLES = [
    ("Delivery was a week late", "negative"),
    ("The courier arrived ahead of schedule", "positive"),
    ("The order arrived on the usual date", "neutral"),
]

response.usage.prompt_tokens shows how many input tokens the instruction, examples and request took, which tells you what the examples cost. More on the request format in the chat completions reference↗; create a key in your dashboard↗.

How to check whether few-shot helps

1. Collect 30–50 real inputs with known correct answers.
2. Run them without examples and with examples on the same model.
3. Compare the share of correct answers and the average token usage from usage.
4. Repeat on another model from the list: results depend on the model and the task, so don't carry them over blindly.

FAQ

How many examples do I need?

For format, one or two are usually enough. For non-obvious logic, three to five varied ones. More only makes sense if a test shows accuracy going up.

Do I need examples for classification with 10 or more classes?

Examples should cover at least the most frequent classes and the ones most easily confused. If covering every class takes too many examples, give the list of classes with short definitions and add examples only for borderline cases.

Can I use few-shot with streaming?

Yes. Examples go into messages as usual. When streaming, check if chunk.choices: before chunk.choices[0], because the last chunk arrives with usage and an empty choices.

Does few-shot work the same on every model?

No, models respond to examples differently. Test on your own data using the method above before choosing a model and the number of examples.