Every call to a model like GPT-4 or Claude is processed in complete isolation — the API has no server-side memory of anything you sent it a moment ago. If a chat feels continuous to the user, that continuity is an illusion your application is maintaining, not something the model does on its own.

This single fact drives almost every design decision in building a chat feature: your code, not the model, is responsible for remembering what was said.

A chat is represented as an ordered array of role-tagged objects — system, user, and assistant — and every single API call resends that entire array from the beginning, not just the newest message. When the array contains 'user: Hi, I am Bob' followed later by 'user: What is my name?', the model only knows the name because it's still sitting there in the array it was just handed.

There is no shortcut: forgetting to include an earlier turn in the array is functionally identical, from the model's perspective, to that turn never having happened.

In a React chat component, the message array itself becomes your state — typically initialized with just a system message, then grown by one entry every time the user sends something or the assistant replies. Rendering the chat UI is then a straightforward map() over that same array.

Because this state lives in the browser (or wherever the component tree lives), it vanishes on page refresh unless you separately persist it — the model was never storing it for you.

Adding a new turn means building a brand-new array with setMessages([...messages, userMsg]) rather than pushing onto the existing array in place — the same immutability rule that applies to any other piece of React state, since mutating messages directly wouldn't reliably trigger a re-render.

This new array is also exactly what you send as the request body on the next API call, so 'updating the UI' and 'updating what the model remembers' are the same operation.

Because the full array is resent on every request, a conversation's token cost grows roughly linearly with its length — turn 50 of a long chat pays for re-sending turns 1 through 49 as well, every single time. This is both a real dollar cost (most APIs bill per input token) and a hard ceiling risk if the total exceeds the model's context window.

A naive chat implementation that never trims history will eventually either get expensive or start throwing context-length errors.

A sliding window keeps the system message pinned in place (since it defines the assistant's whole behavior) and drops the oldest user/assistant turns once the array exceeds a fixed count, keeping only the most recent N exchanges. This bounds token cost at a predictable ceiling no matter how long the user keeps chatting.

The tradeoff is real: anything mentioned only in a dropped turn is genuinely forgotten, which is fine for casual chat but wrong for a conversation where an early detail (like an account ID) still matters much later.

Rather than dropping old turns outright, summary memory asks the model itself to condense the conversation-so-far into a short paragraph, then replaces the discarded turns with that single summary message going forward. This is lossy compression, not a full record, but it preserves the gist of a long conversation at a fraction of the token cost of the original turns.

Production chat systems often combine both patterns: a sliding window for the most recent exchanges, plus a running summary for everything older than that.

For a short-lived support widget, a plain unbounded array is often fine since sessions rarely get long enough to matter. For an always-on personal assistant that users chat with for months, some combination of sliding window and summarization is close to mandatory.

The right choice depends entirely on expected conversation length and how much a stray forgotten detail would actually cost the user — there's no single correct answer for every product.

So far the system message has just been 'You are a helpful assistant' — the next lesson digs into how much more precisely you can shape a model's persona, tone, and hard constraints through careful system prompt design.

LLMs like GPT-4 or Claude are 'stateless'. They have no memory of your past prompts. Every API call is a blank slate.

To create a 'chat' experience, we must manage an array of previous messages and send the ENTIRE history every single time.

In React, we manage this array using state. When a user types, we append their message and trigger the API call.

Checkpoint: If an LLM is stateless, how does it know what was said earlier in the chat?

• →It uses internal server memory
• →We pass the full history array in every request

When sending a new message, use the spread operator to create a new array with the latest user input. Do not mutate the state!

As history grows, so does the token count. You'll eventually need to 'summarize' or 'trim' the history to fit the model's context window.

Checkpoint: Which role is typically used to give the AI its overarching personality or instructions?

• →role: 'user'
• →role: 'system'

For very long chats, you can use a 'sliding window' approach. This removes the oldest messages while keeping the most recent ones.

Another advanced technique is 'Summary Memory', where you ask the AI to condense the previous chat into a few sentences.

Checkpoint: What is the primary benefit of 'Trimming' or 'Summarizing' chat history?

• →It makes the model respond in a different language
• →It saves tokens and prevents hitting the context limit

History managed! Your applications can now sustain long, complex conversations.

Next, we'll dive deeper into 'System Prompts' to control AI behavior with precision.

Validate Real Role Alternation. Finish checking that conversation roles alternate correctly (user, assistant, user, ...) after the system prompt.