When to Use Zero-Shot Prompting

The Decision This Lesson Answers Every prompting task begins with a choice: describe the task (zero-shot), demonstrate it with examples (few-shot), add reasoning steps, provide reference documents, or split the work into several prompts.

Zero-shot prompting is the simplest of these options. This lesson explains how to decide when it is the right choice, when it is a good starting point that may need upgrading, and when another approach is clearly better.

The core principle:

Use zero-shot prompting when the task can be fully specified in words, and when the model already understands the concepts involved.

The Five Questions Ask these questions about your task. The answers point toward zero-shot or toward another technique.

Question 1: Does the Model Already Understand the Task? Zero-shot prompting relies on knowledge the model gained during training (Lesson 16).

Task Model Understands It? Zero-Shot Suitable? Summarize an article Yes, very common task ✓ Classify sentiment Yes, common concept ✓ Translate English to Hindi Yes, widely represented languages ✓ Label tickets with your company's internal codes, such as L2-ESC No, private convention ✗ without definitions Rate essays on your institute's custom rubric Only if the rubric is fully described Possibly Why it matters: If the concept exists only inside your organization, the model cannot know it from a label alone. You must either define it completely in words or show examples.

Question 2: Can the Requirements Be Described Precisely in Words? Some requirements are easy to describe; others are much easier to show.

Easy to Describe Hard to Describe "Return JSON with keys name and email" "Write in our brand voice" "Maximum 3 bullet points" "Match the tone of our previous newsletters" "Classify as Positive, Negative, or Neutral" "Decide whether this is a 'serious' complaint the way our team does" When a requirement is hard to put into words, examples usually work better than more description.

Question 3: How Important Is Consistency? Consistency Need Example Zero-Shot Fit Low Brainstorming ideas, drafting a personal email Excellent Medium Summarizing articles for a newsletter Good, with clear format rules High Labels used for routing and analytics Good if labels are well defined; test carefully Very high Exact format matching a strict specification across thousands of items Often needs examples, structured output features, and validation Question 4: Do You Have Good Examples Available? Few-shot prompting needs high-quality examples. If you do not have them yet, zero-shot is the practical choice. In fact, a zero-shot prompt is often how you create the first examples: run zero-shot, review and correct the outputs, and use the best ones as examples later.

Question 5: What Are the Cost and Speed Constraints? Every example added to a prompt adds tokens to every request. For high-volume applications, this matters.

Estimating the Cost Difference The following script compares the token cost of a zero-shot prompt and a few-shot version of the same prompt at scale. Prices change frequently, so the price is a variable you fill in from your provider's current pricing page.

Requirements: pip install tiktoken

import tiktoken

encoding = tiktoken.get_encoding("o200k_base")

zero_shot = """Classify the support ticket as Billing, Access, Technical, or Other. Billing: payments, refunds, invoices. Access: login, locked courses. Technical: bugs, video or app problems. Other: anything else. Reply with the label only."""

examples = """ Ticket: I was charged twice for the same course. Label: Billing

Ticket: The course still shows as locked after payment. Label: Access

Ticket: The video freezes after 10 seconds on Chrome. Label: Technical

Ticket: Do you have courses in Tamil? Label: Other """

few_shot = zero_shot + "\n\nExamples:" + examples

REQUESTS_PER_MONTH = 100_000 PRICE_PER_MILLION_INPUT_TOKENS = 0.0 # Fill in your model's current input price

for name, prompt in [("zero-shot", zero_shot), ("few-shot", few_shot)]: tokens = len(encoding.encode(prompt)) monthly_tokens = tokens * REQUESTS_PER_MONTH monthly_cost = monthly_tokens / 1_000_000 * PRICE_PER_MILLION_INPUT_TOKENS print(f"{name}: {tokens} tokens per request, " f"{monthly_tokens:,} tokens per month, cost {monthly_cost:.2f}") Code Explanation encoding.encode(prompt) counts the tokens in the fixed part of each prompt (Lesson 2). monthly_tokens multiplies the per-request count by the number of requests, showing how a small difference grows at scale. PRICE_PER_MILLION_INPUT_TOKENS is left as 0.0 deliberately. Fill in the current price for your model so the calculation reflects real costs. The underscores in 100_000 are Python's digit separators, which make large numbers easier to read. Interpreting the Result The few-shot prompt is several times longer here. Whether that matters depends on volume and on whether the examples improve accuracy enough to justify the cost. Some providers also offer prompt caching, which reduces the cost of a repeated fixed prompt prefix; check your provider's documentation, as this can change the calculation.

A Decision Flowchart Is the task a common one the model understands (summarize, translate, classify by common concepts, explain, extract named fields)? │ ├── No → Can you define every concept fully in words? │ ├── No → Use few-shot examples (Lesson 26) │ └── Yes → Zero-shot with detailed definitions │ └── Yes → Does the task require multi-step reasoning or calculation? │ ├── Yes → Add reasoning (Chain-of-Thought lessons) or compute in code │ └── No → Does it need facts the model doesn't have (your policies, recent data, private documents)? │ ├── Yes → Provide the information as context (Lesson 19, RAG) │ └── No → START WITH ZERO-SHOT Test it → Good enough? → Done → Not good enough? → Improve it (Lesson 25) → Still failing? → Add examples How to Read the Flowchart The branches are not mutually exclusive. A context-based QA prompt (Lesson 19) is still a zero-shot prompt that also includes reference text. Reasoning instructions can be added to zero-shot prompts too (zero-shot Chain-of-Thought, Lesson 40). "Start with zero-shot" is the default at the end of most paths, because it is the fastest to build and the easiest to maintain. Scenarios and Recommendations Scenario Recommendation Reason Summarize daily news articles for an internal newsletter Zero-shot Common task; requirements are easy to describe Translate app notifications into Tamil and Hindi Zero-shot with glossary and rules Common languages; terminology handled by rules Extract fields from contact form messages Zero-shot with schema and validation Fields are easy to define Classify tickets into 4 clearly defined categories Zero-shot first; few-shot if boundaries stay inconsistent Definitions may be enough; test to confirm Write social media posts in a distinctive brand voice Few-shot Voice is easier to show than describe Label support tickets with 30 internal escalation codes Hierarchical classification or few-shot Many private labels with subtle boundaries Answer questions about your company's HR policies Zero-shot with provided context The model needs your documents, not examples Solve multi-step pricing calculations Compute in code; use the model to explain Exact computation is not a language task Convert data into an unusual custom text format Few-shot The format is easier to show than describe Brainstorm blog topics Zero-shot Variety is desired; low consistency needs Signs That Zero-Shot Is Working Outputs meet your success criteria on a varied test set (Lesson 12). Results are consistent across repeated runs. Remaining errors are rare and can be handled by validation or review. Adding more instructions no longer changes results noticeably. When these are true, stay with zero-shot. Adding examples would increase cost and maintenance without benefit.

Signs That Zero-Shot Is Not Enough The same boundary cases are classified differently across runs, even after you added rules. The output format is almost right but contains small, repeated deviations that rules do not fix. Your instructions keep growing with more and more special cases. You find yourself describing the desired style with many adjectives that the model interprets inconsistently. These are signals to add examples (few-shot), reasoning, or decomposition. Lesson 24 explains the underlying limitations, and Lesson 25 shows how to strengthen a zero-shot prompt before switching techniques.

Zero-Shot and Modern Reasoning Models Some newer models are trained to reason internally before producing a final answer. For these models, clear zero-shot instructions often work very well, and some providers recommend starting with zero-shot prompts before adding examples, because examples can sometimes constrain the model's own approach. Guidance differs between providers and model generations, so check the documentation for the model you use and compare zero-shot and few-shot versions on your own test set.

Common Mistakes Mistake 1: Jumping to Few-Shot Without a Zero-Shot Baseline What it is: Starting with a long prompt full of examples.

Why it happens: The belief that examples always improve results.

What it causes: Higher cost, longer prompts, and no evidence that the examples were needed.

How to fix it: Build and test a zero-shot version first, and add examples only when testing shows a need.

Mistake 2: Using Zero-Shot for Private Conventions What it is: Expecting the model to understand internal labels, codes, or styles from their names.

Why it happens: The conventions feel standard inside your organization.

What it causes: Guesses that look reasonable but do not match your conventions.

How to fix it: Define conventions fully in words or provide examples.

Mistake 3: Using Zero-Shot When Facts Are Missing What it is: Asking about your products or policies without providing them.

Why it happens: Treating a knowledge problem as a prompting problem.

What it causes: Invented facts. Neither better instructions nor examples can fix missing knowledge.

How to fix it: Provide the information as context.

Mistake 4: Ignoring Volume When Choosing a Technique What it is: Adding many examples to a prompt used hundreds of thousands of times.

Why it happens: Cost is not measured during development.

What it causes: Unnecessarily high costs.

How to fix it: Measure tokens per request and compare accuracy gains against cost.

Best Practices Make zero-shot your default starting point. It is the fastest to build, cheapest to run, and easiest to maintain.

Check whether the task depends on knowledge or conventions the model lacks. Provide definitions, context, or examples accordingly.

Choose few-shot when requirements are easier to show than to describe. Brand voice, unusual formats, and subtle boundaries are typical cases.

Measure before switching techniques. Compare zero-shot and alternatives on the same test set.

Consider cost at scale. Count tokens and multiply by volume.

Use zero-shot outputs to build future examples. Review and correct them, then reuse the best ones if few-shot becomes necessary.

Try It Yourself Exercise 1: Classify the Scenarios Decide whether each task should start with zero-shot, few-shot, context, or code, and explain why:

Rewrite course descriptions to be more beginner-friendly. Assign each student question to one of 15 internal mentor specializations. Calculate GST on invoices. Answer questions about your company's internship rules. Generate captions in the same playful style as your last 20 Instagram posts. Exercise 2: Measure the Trade-Off Take a classification task and build both a zero-shot and a few-shot prompt. Run both on the same 20-case test set and record accuracy. Use the token-counting script from this lesson to compare cost at your expected monthly volume. Decide which version you would deploy and justify your choice.

Exercise 3: Find the Breaking Point Start with a zero-shot prompt that works well for 4 categories. Increase the number of categories to 8 and then 15, adding definitions each time. Record how accuracy and consistency change, and note at which point examples or hierarchical classification would become necessary.