Skip to main content
UltraContext - Store & retrieve contexts guide cover

Guide Overview

After this guide, you’ll be able to:
  • Persist context across sessions (e.g. chats, conversations)
  • Retrieve context from a specific point in time

Why Store & Retrieve Contexts?

Picture this: You build a simple AI agent. Works like a charm. As it gets more useful, you wanna save messages so you can get back to past conversations. Sounds simple, right? So you start storing them somewhere. You didn’t notice it yet, but complexity quietly added up in your system. You’re now dealing with timestamps, ordering, metadata and sessions. At some point, while implementing a tiny custom feature, you realize you’ve been wasting more time on infrastructure rather than on the agent itself. You feel frustrated. The initial excitement fades away. Welcome to the club. What if infrastructure wasn’t the bottleneck? Everything would be way simpler. With UltraContext, storing and retrieving contexts is trivial. From now on, we’ll do the heavy lifting for you. It’s time to build.

Storing Contexts

Create a context and append messages:
Appends don’t generate new versions—only updates and deletes do. This means you can travel back in time by index or timestamp without version overhead. See the View Context History guide for more details.
UltraContext is schema-free. Store any fields you need. Only id and index are reserved keys.

Metadata

Attach metadata at both the context level and message level:
Context level metadata is useful for:
  • User IDs
  • Session types
Message level metadata is great for:
  • Marking checkpoints
  • Token usage
  • Model

Retrieving Contexts

Multiple ways to fetch context: current state, specific version, point in time, or by message index.

Get current state

Retrieve by index

Get messages 0 through a specific index:

Retrieve by timestamp

Get state at any point in time:

Retrieve by version

Use history: true to see what mutations happened and which versions exist:
Then you can retrieve the state at a specific version:
See View Context History for advanced time-travel patterns.

Listing Contexts

List all contexts in your project. By default, contexts are sorted by created_at in descending order (newest first).

Filter by metadata

Filter contexts by metadata fields stored at creation time. All filters are optional and can be combined.
Metadata filters use a GIN index on the metadata JSONB column for fast lookups.

Examples

Resume Chats

Resuming chats is simple. Just retrieve the associated context and continue the conversation from there.
Store the contextId in your session, database, or URL. Retrieve it on return visits to resume the conversation.

Retrieve to Checkpoint

Retrieve the context up to a specific checkpoint.
1

Mark your checkpoint with metadata as you go

2

Find checkpoint index

3

Retrieve messages up to checkpoint

4

(Optional) Fork context from checkpoint

You can use metadata to retrieve a context up to a specific relevant part, discard everything after that point to start a fresh context from there.Forking is a great way to carry context over new sessions while maintaining a high signal-to-noise token ratio (and still preserving the original).See the Fork & Clone Contexts guide for this pattern.

Start Fresh with Summary

Start a new context with a summary of the previous one.
1

Get latest context

2

Summarize context

3

Create new context

4

Append summary


Switch Frameworks

UltraContext is framework-agnostic. Switch between LLM frameworks without changing your stored data.
The parseFor* functions are placeholders—implement based on your schema and each provider’s message format.
Store context once, use anywhere. No vendor lock-in. No data migration when switching providers.

Next: Edit Contexts

Update and delete messages with full audit trail.