Handling Conversation History
Claude is stateless between calls
The API does not remember previous messages automatically. Every call must include the full conversation history in the messages array — alternating user/assistant turns — for Claude to have context.
Storing history server-side
Store each conversation's messages in Firestore (or another database) keyed by a conversation ID. On each new user message, fetch the prior history, append the new message, send the full array to Claude, then append Claude's reply and save.
Managing context window limits
Long conversations eventually exceed the context window or become expensive. Common strategies: truncate to the last N turns, summarize older turns into a condensed system note, or use a sliding window.
Key Takeaways
- The API is stateless — you must resend full history each call.
- Store conversation history server-side, keyed by conversation ID.
- Long conversations need truncation or summarization strategies.
- Never trust the client to hold or send authoritative history.
Persist a multi-turn conversation
Extend your API route to accept a `conversationId`, store messages in Firestore, and replay full history on each call. Test a 3-turn conversation where Claude remembers earlier context.