How Large Language Models Respond to Prompts

The Journey of a Prompt

When you send a prompt to a Large Language Model (LLM), the response does not appear all at once. The model goes through a repeated process that turns your text into numbers, predicts what should come next, and turns the result back into text.

Your prompt (text)
        ↓
Tokenization: text is split into tokens
        ↓
The model reads all tokens in the context window
        ↓
It calculates a probability for every possible next token
        ↓
One token is selected
        ↓
The token is added to the end of the text
        ↓
Repeat until the response is finished
        ↓
Tokens are converted back into readable text

Understanding each step explains many behaviors that otherwise seem strange: why the same prompt gives different answers, why models struggle to count letters, why a chatbot "forgets" earlier messages, and why wording changes the result. Each of these behaviors has a direct consequence for how you should write prompts.

Step 1: Tokenization

What Is a Token?

Simple meaning: A token is a small piece of text that the model works with. Technical meaning: A token is a unit from the model's fixed vocabulary. Before the model processes your prompt, a component called a tokenizer splits the text into tokens and converts each token into a number (a token ID). The model only ever sees these numbers, never the original characters. Tokens are not the same as words: | Text | How It Is Typically Tokenized | |------|-------------------------------| | A common short word such as the | Usually 1 token | | A common word with a leading space, such as course | Usually 1 token (the space is part of the token) | | A long or rare word such as tokenization | Often split into several pieces | | A number such as 2026 | May be 1 or more tokens, depending on the tokenizer | | Punctuation such as . or { | Usually its own token | | Text in many non-English languages | Often uses more tokens per word than English | A rough guideline for English text is that one token is about four characters, or about three quarters of a word. This is only an estimate; the exact count depends on the tokenizer used by the specific model.

Example: Counting Tokens in Python

OpenAI publishes its tokenizer as the open-source tiktoken library. You can use it to see exactly how text is split. Install:

pip install tiktoken

Code:

import tiktoken
# o200k_base is the encoding used by recent OpenAI models such as GPT-4o.
encoding = tiktoken.get_encoding("o200k_base")
text = "Prompt engineering improves AI responses."
token_ids = encoding.encode(text)
print("Number of tokens:", len(token_ids))
print("Token IDs:", token_ids)
for token_id in token_ids:
    print(repr(encoding.decode([token_id])))

Example Explanation

• tiktoken.get_encoding("o200k_base") loads a specific tokenizer. Different model families use different encodings, so the same sentence can produce different token counts on different models.
• encoding.encode(text) converts the sentence into a list of integer token IDs. This list is what the model actually receives.
• len(token_ids) gives the token count, which is what context limits and API pricing are based on.
• The loop decodes each ID individually so you can see where the text was split. You will notice that many tokens include a leading space, such as ' engineering'. Spaces are not separate; they are attached to the following word.

  Why Tokenization Matters for Prompting

  1. Models are weak at character-level tasks. Because the model sees tokens rather than individual letters, tasks such as "count the letters in this word" or "reverse this string character by character" are harder than they look. The model never saw the individual characters directly. If your application needs exact character operations, do them in code, not with a prompt. 2. Limits and costs are measured in tokens. A prompt that seems short in words may be long in tokens if it contains code, JSON, URLs, or non-English text. Estimate token counts for prompts you reuse at scale. 3. Formatting adds tokens. Whitespace, repeated separators, and decorative characters all consume tokens. Clear formatting is worth its cost, but large amounts of meaningless decoration are not.

  ---

  Step 2: The Context Window

  What It Is

  The context window is the maximum number of tokens a model can consider in a single request. It includes everything:

• Your instructions (system or developer message)
• The conversation history
• Any documents or data you include
• The response the model is generating If a model has a context window of 128,000 tokens and your input uses 120,000, only about 8,000 tokens remain for the answer.

  What Happens When the Limit Is Exceeded

  The behavior depends on where you use the model:

• Through an API, a request that exceeds the limit is usually rejected with an error.
• In chat applications, older messages may be dropped or summarized automatically so the conversation can continue. This is why a long chat may "forget" details you gave at the beginning.

  Why It Matters for Prompting

  The model can only use information that is inside the context window for that request. If a fact is not in the prompt, in the included history, or in the model's training data, the model does not have it. This is the reason later lessons spend so much time on providing context and providing input data.

  ---

  Step 3: Next-Token Prediction

  How It Works

  After tokenization, the model processes all tokens in the context window and produces a probability distribution: a score for every token in its vocabulary, representing how likely that token is to come next. Consider this prompt:

  The best programming language for complete beginners is

  The model might assign probabilities like these to the next token (the numbers are illustrative, not real model output): | Candidate Next Token | Illustrative Probability | |----------------------|--------------------------| | Python | 0.62 | | often | 0.11 | | JavaScript | 0.09 | | Scratch | 0.05 | | a | 0.04 | | (thousands of others) | remaining probability | One token is selected. It is appended to the text, and the whole process runs again to predict the token after it. A 300-word answer requires several hundred of these prediction steps.

  How the Prompt Changes the Probabilities

  Now add context:

  I am a 10-year-old who wants to make simple games with drag-and-drop blocks.
  The best programming language for me is

  In this context, tokens such as Scratch become much more likely, because the prompt now describes a situation where that answer fits best. This is the most important idea in this lesson:

  A prompt does not "command" the model in the way code commands a computer. It shapes the probabilities of what the model will write next. Every word you include shifts those probabilities. Clear instructions, relevant context, and examples all work by making the desired kind of response more likely and undesired responses less likely.

  Each Generated Token Also Shapes the Rest

  The model's own output becomes part of the context for the next prediction. If the first sentence of a response heads in the wrong direction, the following sentences tend to continue in that direction. This is why defining the expected format and approach before the model starts writing is more effective than hoping it corrects itself later.

  ---

  Step 4: Selecting a Token

  The model produces probabilities, but something must decide which token is actually used. This is called decoding or sampling. | Method | How It Works | Result | |--------|--------------|--------| | Greedy selection | Always choose the single most probable token | Very predictable, can become repetitive | | Sampling | Choose randomly, weighted by probability | Varied, more natural, less predictable | Most chat models use sampling, adjusted by settings such as temperature and top_p (introduced in Lesson 1). This explains a behavior that surprises many beginners: The same prompt can produce different answers each time you run it. The model is not "changing its mind". At each step, a token was chosen from a probability distribution, and a different choice early in the response leads to a different path for everything that follows.

  Practical Consequence

  When you evaluate a prompt, run it more than once. A prompt that produced a perfect answer once may produce a poor one on the next run. What matters is whether the prompt produces acceptable answers consistently.

  ---

  Step 5: When Generation Stops

  The model keeps generating tokens until one of these conditions occurs:

1. It produces a special end-of-response token. The model has learned to signal that its answer is complete.
2. It reaches the maximum output length that you or the application set.
3. It produces a stop sequence, if the API supports and you configured one. The second case is a common source of bugs. If the output limit is too small, the response is cut off mid-sentence, or a JSON object is left without its closing braces.

   Example: Detecting a Truncated Response

   With the OpenAI Python SDK and the Responses API, you can check whether a response was cut short:

   from openai import OpenAI
   client = OpenAI()
   response = client.responses.create(
    model="gpt-5.4",  # Replace with a model available in your account
    input="List 30 common Python built-in functions with a one-line description each.",
    max_output_tokens=150,
   )
   if response.status == "incomplete":
    reason = response.incomplete_details.reason
    print(f"Response was cut off. Reason: {reason}")
   else:
    print(response.output_text)

   Example Explanation

• max_output_tokens=150 deliberately sets a limit that is too small for 30 descriptions.
• response.status is "completed" when the model finished normally and "incomplete" when generation stopped early.
• response.incomplete_details.reason tells you why. When the cause is the output limit, the reason is "max_output_tokens".
• In a real application, you would increase the limit, ask for fewer items, or request a more compact format rather than silently using a partial answer.

  Note: For reasoning models, the output limit can also include tokens the model uses internally for reasoning before writing the visible answer. A limit that looks generous may still be reached. Check the documentation for the model you use.

  ---

  How Chat Models Learn to Follow Prompts

  Not all language models respond to prompts in the same way. The difference comes from how they were trained.

  Stage 1: Pretraining (Base Models)

  A model is first trained on a very large collection of text to predict the next token. The result is a base model. A base model is good at continuing text but does not naturally act like an assistant. If you give a base model:

  Write a short poem about the ocean.

  it might continue with something that resembles a list of writing prompts, such as Write a short poem about the mountains., because lists of writing exercises are a common pattern in text.

  Stage 2: Instruction Tuning and Preference Training (Chat Models)

  The base model is then trained further on examples of instructions paired with good responses, and refined using feedback about which responses people prefer. The result is an instruction-following or chat model, which is what most people use today. Given the same prompt, a chat model writes the poem.

  Why This Matters

• Chat models are trained to be helpful, so they will usually try to answer even when your prompt is unclear, filling gaps with assumptions instead of asking. You must provide the details that prevent wrong assumptions.
• Chat models have learned typical "assistant" habits, such as adding introductions, caveats, or summaries. If you do not want these, you need to say so explicitly.

  ---

  Message Roles

  Chat models do not receive a single block of text. They receive a sequence of messages, each labeled with a role. The exact role names vary slightly between providers, but the concepts are the same. | Role | Who Writes It | Purpose | |------|---------------|---------| | System / Developer | The application developer | Sets overall behavior, rules, and context for the conversation | | User | The person using the application | The request or question | | Assistant | The model | The model's previous responses |

  Example

  [System]    You are a tutor for beginner Python students.
            Explain concepts using simple everyday analogies.
            Never give complete homework solutions; give hints instead.
  [User]      What is a variable?
  [Assistant] Think of a variable as a labeled box...
  [User]      Can you just write my whole assignment for me?

  Example Explanation

• The system message defines rules that apply to every turn, including the rule about homework.
• When the user asks for a full solution, the model sees both the system rule and the user request. Models are trained to give system and developer instructions higher priority than user messages, so it is likely to offer hints instead.
• The assistant message shows the model what it already said, which keeps the conversation consistent. In the OpenAI Responses API, the instructions parameter plays the system/developer role, and the input parameter carries user content, as shown in Lesson 1.

  ---

  Models Are Stateless

  What It Means

  An LLM does not remember previous requests. Every API call is independent. When a chatbot appears to remember what you said earlier, it is because the application sends the previous messages again with every new request.

  Example: Demonstrating Statelessness

  from openai import OpenAI
  client = OpenAI()
  MODEL = "gpt-5.4"  # Replace with a model available in your account
  # Request 1
  first = client.responses.create(
    model=MODEL,
    input="My name is Priya and I am learning Django.",
  )
  print(first.output_text)
  # Request 2: a completely separate call with no history
  second = client.responses.create(
    model=MODEL,
    input="What is my name and what am I learning?",
  )
  print(second.output_text)

  The second request has no access to the first. The model will respond that it does not know your name.

  Example: Sending the History Manually

  conversation = client.responses.create(
    model=MODEL,
    input=[
        {"role": "user", "content": "My name is Priya and I am learning Django."},
        {"role": "assistant", "content": "Nice to meet you, Priya! Django is a great choice."},
        {"role": "user", "content": "What is my name and what am I learning?"},
    ],
  )
  print(conversation.output_text)

  Example Explanation

• input is now a list of messages instead of a single string.
• The earlier user message and the assistant's earlier reply are included in the request, so the information is inside the context window.
• The model can now answer correctly, not because it remembered, but because the answer is present in the prompt.

  Note: The Responses API also offers a previous_response_id parameter. When you pass the ID of an earlier response, OpenAI includes that earlier conversation for you. The principle is the same: the history is still provided as context to the model, and it still counts toward the context window.

  Consequences for Prompting

• Long conversations grow expensive, because the entire history is processed again on every turn.
• Long conversations can lose early details, because chat applications trim or summarize history to stay inside the context window.
• Old, irrelevant messages still influence answers. If a conversation has drifted across several topics, earlier content can affect later responses. For a new task, starting a fresh conversation often gives cleaner results.

  ---

  Why Models Produce Confident but Wrong Answers

  What Happens

  Sometimes a model produces information that sounds correct but is false: a function that does not exist, a wrong date, or an invented citation. This is commonly called hallucination.

  Why It Happens

  Based on everything in this lesson, the cause is predictable:

1. The model predicts plausible text, not verified facts. It has no built-in step that checks a statement against a database before writing it.
2. Its knowledge ends at its training cutoff. It does not know about events, library versions, or prices after that point unless you provide them.
3. It is trained to be helpful, so when information is missing, it tends to produce a likely-sounding answer rather than stopping.

   Example

   What does the function fast_sort_v2() do in the Python standard library?

   No such function exists in the Python standard library, but the name looks plausible. A model may describe what such a function "would" do as if it were real.

   Reducing the Problem With the Prompt

   Does the Python standard library contain a function named fast_sort_v2()?
   If you are not certain it exists, say so clearly instead of guessing.
   Only describe functions you are confident are part of the standard library.

   This does not guarantee a correct answer, but it changes the probabilities: an honest "I am not aware of such a function" now fits the prompt better than an invented description. Techniques for grounding answers in provided documents are covered in the RAG lessons later in this series.

   ---

   Why Wording and Position Matter

   Because every token influences the probabilities, small changes can affect the response. Wording: "Explain recursion" and "Explain recursion to a beginner using one real-life analogy" lead to noticeably different responses, because the second prompt makes a specific kind of answer far more likely. Labels and structure: Text labeled Article: followed by Summary: signals strongly what should come next. Structure is one of the most reliable ways to guide output. Position in long prompts: When a prompt contains a long document, models may pay uneven attention to different parts of it. Research on long-context models has found that information placed in the middle of a very long input can be used less reliably than information near the beginning or end, although newer models have improved. Many providers recommend placing long documents first and the specific question or instructions after them, so the task is fresh at the point where the model starts writing. Practical example:

   <document>
   [... several pages of a refund policy ...]
   </document>
   Using only the document above, answer this question:
   Can a customer get a refund 20 days after purchase?
   If the document does not answer this, say "Not specified in the policy."

   The document is clearly delimited, and the question and rules come last, immediately before the model writes its answer.

   ---

   Common Mistakes

   Mistake 1: Assuming the Model Remembers Previous Requests

   Why it happens: Chat interfaces make conversations feel continuous. What it causes: In an application, follow-up requests fail because the earlier information was never sent. How to fix it: Include the necessary history or context in every request, or use the API's conversation features deliberately.

   Mistake 2: Expecting Identical Output Every Time

   Why it happens: Traditional software is deterministic: the same input gives the same output. What it causes: Code that depends on exact wording breaks on the next run. How to fix it: Define a strict output format, validate it in code, and design your application to accept variations in wording.

   Mistake 3: Using Prompts for Exact Character or Arithmetic Operations

   Why it happens: Models handle language so well that it seems they should handle simple counting. What it causes: Wrong letter counts, wrong string reversals, and arithmetic errors on large numbers. How to fix it: Perform exact operations in code. Use the model for language understanding and generation.

   Mistake 4: Assuming the Model Knows Current Information

   Why it happens: Models answer confidently about many topics. What it causes: Outdated library syntax, old prices, or incorrect claims about recent events. How to fix it: Provide current information in the prompt, or use a system that retrieves it, and verify version-specific technical details against official documentation.

   Mistake 5: Ignoring Truncated Output

   Why it happens: A cut-off response can look complete at a glance. What it causes: Incomplete lists and invalid JSON passed to the rest of your program. How to fix it: Check the response status in code and set output limits appropriate to the task.

   ---

   Best Practices

   Put every required fact in the prompt. The model can only use what is in its training data or in the current context window. If your task depends on specific information, include it. Shape the start of the response. Because each token influences the next, define the format and approach before the model begins writing. Run prompts multiple times during testing. Sampling means one good result is not proof of reliability. Use roles correctly. Put lasting rules in the system or developer instructions and put user-specific content in the user message. Keep conversations focused. Start a new conversation for an unrelated task, so old context does not influence the new one. Measure tokens for prompts used at scale. Token counts determine cost, speed, and whether your input fits. Let code do what code does best. Use deterministic code for counting, exact math, and validation, and use the model for understanding and generating language.

   ---

   Try It Yourself

   Exercise 1: Observe Sampling

   Send this prompt to any AI chat tool three times, each in a new conversation:

   Suggest a name for a coffee shop run by programmers.

   Notice that the answers differ. Then try:

   Suggest exactly one name for a coffee shop run by programmers.
   The name must combine a coffee word and a programming word.
   Reply with the name only.

   The names will still vary, but the form of the answer becomes consistent. This shows the difference between controlling what kind of answer you get and controlling the exact answer.

   Exercise 2: Observe Statelessness

   In a chat tool, tell the model your favorite programming language. Then open a new conversation and ask what your favorite language is. Unless the tool has a separate memory feature, the model cannot know, because the new conversation does not include the earlier messages.

   Exercise 3: Observe the Effect of Context

   Run these two prompts and compare the answers:

   What is the best database?

   I am building a small personal blog with Django and expect fewer than
   1,000 visitors per month. I want the simplest setup possible.
   What is the best database for this project, and why?

   The second prompt makes a specific, justified answer far more likely, because the context changes which responses fit best.