Conversation History and Context

Conversation history is the earlier messages you include in a request so the model can use them on this turn.

Context is everything the model can see in that request — your new question, plus any history (and system instructions) you chose to send.

Most model APIs do not remember past calls for you. If you want memory, you send the history again.

Each call still starts fresh

You already know one turn. Here it is again as a full request and response.

Turn 1 — request:

{
  "model": "some-model",
  "messages": [
    {
      "role": "user",
      "content": "My cat is named Mango."
    }
  ]
}

Turn 1 — response:

{
  "message": {
    "role": "assistant",
    "content": "Got it — your cat is named Mango."
  }
}

Now a new call, with only the new question:

Turn 2 — request (no history):

{
  "model": "some-model",
  "messages": [
    {
      "role": "user",
      "content": "What is my cat's name?"
    }
  ]
}

The server has no leftover memory of Turn 1. The name “Mango” is not in this request, so the model may guess, invent, or say it does not know.

History means you resend earlier messages

To fix that, Turn 2 must include the earlier exchange — with roles — and then the new question:

Turn 2 — request (with history):

{
  "model": "some-model",
  "messages": [
    {
      "role": "user",
      "content": "My cat is named Mango."
    },
    {
      "role": "assistant",
      "content": "Got it — your cat is named Mango."
    },
    {
      "role": "user",
      "content": "What is my cat's name?"
    }
  ]
}

Now the model can see the name in this request. That list of earlier messages is the conversation history.

  Turn 1:  user → assistant
                      │
                      │  you keep both messages
                      ▼
  Turn 2:  [user, assistant, user]  →  assistant
            ▲               ▲
            history         new question

Some SDKs offer a “chat” helper that appends history for you. Under the hood it is still the same idea: the next request includes prior messages. Learn the idea first; helpers are optional.

Context is what the model can see

On any one call, context is the text inside that request:

• System instructions (if any)
• History you included
• The new user question

If it is not in the request, it is not in context.

So:

History is one way to build context. The new question is also context. System instructions are context too.

History has a cost

Every message you resend uses tokens — the same pieces of text you already know about.

Longer history → more input tokens → usually more cost and a longer request.

That is why programs often:

• Keep only recent turns
• Drop old small talk
• Summarize older parts later (advanced)

You do not need those strategies yet. Notice the tradeoff: more history can mean better answers, and it also means a bigger meter on the request.

Name differences (same jobs)

In our examples we use assistant for the model’s reply. Some APIs (including Gemini) use the role name model for that same job.

Learn the jobs. Remap the names when the SDK changes them.

See it in Code

The Code panel sends one request that already includes:

1. An earlier user message (the cat’s name)
2. An earlier assistant/model reply
3. A new user question (“What is my cat’s name?”)

Then it reads the new assistant text. Same idea in Python, Java, Go, and TypeScript.

Cast for this beat

Next: structured outputs — when you need the reply as data your program can parse, not only free prose.