@mastra/memory 1.6.1 → 1.6.2

package/dist/docs/references/docs-memory-working-memory.md

@@ -13,7 +13,7 @@ Working memory can persist at two different scopes:
 
 **Important:** Switching between scopes means the agent won't see memory from the other scope - thread-scoped memory is completely separate from resource-scoped memory.
 
-## Quick Start
+## Quick start
 
 Here's a minimal example of setting up an agent with working memory:
 
@@ -37,13 +37,13 @@ const agent = new Agent({
 })
 ```
 
-## How it Works
+## How it works
 
 Working memory is a block of Markdown text that the agent is able to update over time to store continuously relevant information:
 
 [YouTube video player](https://www.youtube-nocookie.com/embed/UMy_JHLf1n8)
 
-## Memory Persistence Scopes
+## Memory persistence scopes
 
 Working memory can operate in two different scopes, allowing you to choose how memory persists across conversations:
 
@@ -117,7 +117,7 @@ const memory = new Memory({
 - Temporary or session-specific information
 - Workflows where each thread needs working memory but threads are ephemeral and not related to each other
 
-## Storage Adapter Support
+## Storage adapter support
 
 Resource-scoped working memory requires specific storage adapters that support the `mastra_resources` table:
 
@@ -128,7 +128,7 @@ Resource-scoped working memory requires specific storage adapters that support t
 - **Upstash** (`@mastra/upstash`)
 - **MongoDB** (`@mastra/mongodb`)
 
-## Custom Templates
+## Custom templates
 
 Templates guide the agent on what information to track and update in working memory. While a default template is used if none is provided, you'll typically want to define a custom template tailored to your agent's specific use case to ensure it remembers the most relevant information.
 
@@ -142,7 +142,7 @@ const memory = new Memory({
       template: `
 # User Profile
 
-## Personal Info
+## Personal info
 
 - Name:
 - Location:
@@ -156,7 +156,7 @@ const memory = new Memory({
   - [Deadline 1]: [Date]
   - [Deadline 2]: [Date]
 
-## Session State
+## Session state
 
 - Last Task Discussed:
 - Open Questions:
@@ -168,13 +168,13 @@ const memory = new Memory({
 })
 ```
 
-## Designing Effective Templates
+## Designing effective templates
 
-A well-structured template keeps the information easy for the agent to parse and update. Treat the template as a short form that you want the assistant to keep up to date.
+A well-structured template keeps the information straightforward for the agent to parse and update. Treat the template as a short form that you want the assistant to keep up to date.
 
-- **Short, focused labels.** Avoid paragraphs or very long headings. Keep labels brief (for example `## Personal Info` or `- Name:`) so updates are easy to read and less likely to be truncated.
+- **Short, focused labels.** Avoid paragraphs or very long headings. Keep labels brief (for example `## Personal Info` or `- Name:`) so updates are readable and less likely to be truncated.
 - **Use consistent casing.** Inconsistent capitalization (`Timezone:` vs `timezone:`) can cause messy updates. Stick to Title Case or lower case for headings and bullet labels.
-- **Keep placeholder text simple.** Use hints such as `[e.g., Formal]` or `[Date]` to help the LLM fill in the correct spots.
+- **Keep placeholder text minimal.** Use hints such as `[e.g., Formal]` or `[Date]` to help the LLM fill in the correct spots.
 - **Abbreviate very long values.** If you only need a short form, include guidance like `- Name: [First name or nickname]` or `- Address (short):` rather than the full legal text.
 - **Mention update rules in `instructions`.** You can instruct how and when to fill or clear parts of the template directly in the agent's `instructions` field.
 
@@ -206,7 +206,7 @@ const paragraphMemory = new Memory({
 })
 ```
 
-## Structured Working Memory
+## Structured working memory
 
 Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Zod](https://zod.dev/) schema. When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
@@ -263,22 +263,22 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
 
 - **Object fields are deep merged:** Only provided fields are updated; others remain unchanged
 - **Set a field to `null` to delete it:** This explicitly removes the field from memory
-- **Arrays are replaced entirely:** When an array field is provided, it replaces the existing array (arrays are not merged element-by-element)
+- **Arrays are replaced entirely:** When an array field is provided, it replaces the existing array (arrays aren't merged element-by-element)
 
-## Choosing Between Template and Schema
+## Choosing between template and schema
 
 - Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics** — the agent must provide the complete memory content on each update.
 - Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. Schemas use **merge semantics** — the agent only provides fields to update, and existing fields are preserved.
-- Only one mode can be active at a time: setting both `template` and `schema` is not supported.
+- Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
 
-## Example: Multi-step Retention
+## Example: Multi-step retention
 
 Below is a simplified view of how the `User Profile` template updates across a short user conversation:
 
 ```nohighlight
 # User Profile
 
-## Personal Info
+## Personal info
 
 - Name:
 - Location:
@@ -301,9 +301,9 @@ Below is a simplified view of how the `User Profile` template updates across a s
 
 The agent can now refer to `Sam` or `Berlin` in later responses without requesting the information again because it has been stored in working memory.
 
-If your agent is not properly updating working memory when you expect it to, you can add system instructions on _how_ and _when_ to use this template in your agent's `instructions` setting.
+If your agent isn't properly updating working memory when you expect it to, you can add system instructions on _how_ and _when_ to use this template in your agent's `instructions` setting.
 
-## Setting Initial Working Memory
+## Setting initial working memory
 
 While agents typically update working memory through the `updateWorkingMemory` tool, you can also set initial working memory programmatically when creating or updating threads. This is useful for injecting user data (like their name, preferences, or other info) that you want available to the agent without passing it in every request.
 
@@ -372,7 +372,7 @@ await memory.updateWorkingMemory({
 })
 ```
 
-## Read-Only Working Memory
+## Read-only working memory
 
 In some scenarios, you may want an agent to have access to working memory data without the ability to modify it. This is useful for:
 

package/dist/docs/references/reference-core-getMemory.md

@@ -22,7 +22,7 @@ const thread = await memory.createThread({
 
 **memory** (`TMemory[TMemoryKey]`): The memory instance with the specified key. Throws an error if the memory is not found.
 
-## Example: Registering and Retrieving Memory
+## Example: Registering and retrieving memory
 
 ```typescript
 import { Mastra } from '@mastra/core'

package/dist/docs/references/reference-core-listMemory.md

@@ -20,7 +20,7 @@ This method takes no parameters.
 
 **memory** (`Record<string, MastraMemory>`): An object containing all registered memory instances, keyed by their registry keys.
 
-## Example: Checking Registered Memory
+## Example: Checking registered memory
 
 ```typescript
 import { Mastra } from '@mastra/core'

package/dist/docs/references/reference-memory-clone-utilities.md

@@ -1,8 +1,8 @@
-# Cloned Thread Utilities
+# Cloned thread utilities
 
 The Memory class provides utility methods for working with cloned threads. These methods help you check clone status, retrieve clone metadata, navigate clone relationships, and track clone history.
 
-## isClone()
+## `isClone()`
 
 Checks whether a thread is a clone of another thread.
 
@@ -28,7 +28,7 @@ if (memory.isClone(thread)) {
 }
 ```
 
-## getCloneMetadata()
+## `getCloneMetadata()`
 
 Retrieves the clone metadata from a thread if it exists.
 
@@ -54,7 +54,7 @@ if (cloneInfo) {
 }
 ```
 
-## getSourceThread()
+## `getSourceThread()`
 
 Retrieves the original source thread that a cloned thread was created from.
 
@@ -79,7 +79,7 @@ if (sourceThread) {
 }
 ```
 
-## listClones()
+## `listClones()`
 
 Lists all threads that were cloned from a specific source thread.
 
@@ -104,7 +104,7 @@ for (const clone of clones) {
 }
 ```
 
-## getCloneHistory()
+## `getCloneHistory()`
 
 Retrieves the full clone history chain for a thread, tracing back to the original.
 
@@ -136,7 +136,7 @@ for (let i = 0; i < history.length; i++) {
 }
 ```
 
-## Complete Example
+## Complete example
 
 ```typescript
 import { mastra } from './mastra'

package/dist/docs/references/reference-memory-cloneThread.md

@@ -2,7 +2,7 @@
 
 The `.cloneThread()` method creates a copy of an existing conversation thread, including all its messages. This enables creating divergent conversation paths from a specific point in a conversation. When semantic recall is enabled, the method also creates vector embeddings for the cloned messages.
 
-## Usage Example
+## Usage example
 
 ```typescript
 const { thread, clonedMessages } = await memory.cloneThread({
@@ -52,7 +52,7 @@ The cloned thread's metadata includes a `clone` property with:
 
 **lastMessageId** (`string`): The ID of the last message in the source thread at the time of cloning.
 
-## Extended Usage Example
+## Extended usage example
 
 ```typescript
 import { mastra } from './mastra'
@@ -98,7 +98,7 @@ const response = await agent.generate("Let's try a different approach", {
 })
 ```
 
-## Vector Embeddings
+## Vector embeddings
 
 When the Memory instance has semantic recall enabled (with a vector store and embedder configured), `cloneThread()` automatically creates vector embeddings for all cloned messages. This ensures that semantic search works correctly on the cloned thread.
 
@@ -127,7 +127,7 @@ const results = await memory.recall({
 })
 ```
 
-## Observational Memory
+## Observational memory
 
 When [Observational Memory](https://mastra.ai/docs/memory/observational-memory) is enabled, `cloneThread()` automatically clones the OM records associated with the source thread. The behavior depends on the OM scope:
 
@@ -135,4 +135,4 @@ When [Observational Memory](https://mastra.ai/docs/memory/observational-memory)
 - **Resource-scoped OM (same `resourceId`)**: The OM record is shared between the source and cloned threads since they belong to the same resource. No duplication occurs.
 - **Resource-scoped OM (different `resourceId`)**: The OM record is cloned to the new resource. Message IDs are remapped and any thread-identifying tags within observations are updated to reference the cloned thread.
 
-Only the current (most recent) OM generation is cloned — older history generations are not copied. Transient processing state (observation/reflection in-progress flags) is reset on the cloned record.
+Only the current (most recent) OM generation is cloned — older history generations aren't copied. Transient processing state (observation/reflection in-progress flags) is reset on the cloned record.

package/dist/docs/references/reference-memory-createThread.md

@@ -2,7 +2,7 @@
 
 The `.createThread()` method creates a new conversation thread in the memory system. Each thread represents a distinct conversation or context and can contain multiple messages.
 
-## Usage Example
+## Usage example
 
 ```typescript
 await memory?.createThread({ resourceId: 'user-123' })

package/dist/docs/references/reference-memory-getThreadById.md

@@ -2,7 +2,7 @@
 
 The `.getThreadById()` method retrieves a specific thread by its ID.
 
-## Usage Example
+## Usage example
 
 ```typescript
 await memory?.getThreadById({ threadId: 'thread-123' })

package/dist/docs/references/reference-memory-listThreads.md

@@ -2,7 +2,7 @@
 
 The `listThreads()` method retrieves threads with pagination support and optional filtering by `resourceId`, `metadata`, or both.
 
-## Usage Examples
+## Usage examples
 
 ### List all threads with pagination
 
@@ -26,7 +26,7 @@ const result = await memory.listThreads({
 })
 ```
 
-### Filter by resourceId
+### Filter by `resourceId`
 
 ```typescript
 const result = await memory.listThreads({
@@ -119,7 +119,7 @@ while (hasMorePages) {
 }
 ```
 
-## Metadata Filtering
+## Metadata filtering
 
 The metadata filter uses AND logic - all specified key-value pairs must match for a thread to be included in the results:
 

package/dist/docs/references/reference-memory-memory-class.md

@@ -1,4 +1,4 @@
-# Memory Class
+# Memory class
 
 The `Memory` class provides a robust system for managing conversation history and thread-based message storage in Mastra. It enables persistent storage of conversations, semantic search capabilities, and efficient message retrieval. You must configure a storage provider for conversation history, and if you enable semantic recall you will also need to provide a vector store and embedder.
 

package/dist/docs/references/reference-memory-observational-memory.md

@@ -1,4 +1,4 @@
-# Observational Memory
+# Observational memory
 
 **Added in:** `@mastra/memory@1.1.0`
 
@@ -26,6 +26,8 @@ export const agent = new Agent({
 
 The `observationalMemory` option accepts `true`, a configuration object, or `false`. Setting `true` enables OM with `google/gemini-2.5-flash` as the default model. When passing a config object, a `model` must be explicitly set — either at the top level, or on `observation.model` and/or `reflection.model`.
 
+Observer input is multimodal-aware. OM keeps text placeholders like `[Image #1: screenshot.png]` in the transcript it builds for the Observer, and also sends the underlying image parts when possible. This applies to both single-thread observation and batched multi-thread observation. Non-image files appear as placeholders only.
+
 **enabled** (`boolean`): Enable or disable Observational Memory. When omitted from a config object, defaults to \`true\`. Only \`enabled: false\` explicitly disables it. (Default: `true`)
 
 **model** (`string | LanguageModel | DynamicModel | ModelWithRetries[]`): Model for both the Observer and Reflector agents. Sets the model for both at once. Cannot be used together with \`observation.model\` or \`reflection.model\` — an error will be thrown if both are set. When using \`observationalMemory: true\`, defaults to \`google/gemini-2.5-flash\`. When passing a config object, this or \`observation.model\`/\`reflection.model\` must be set. Use \`"default"\` to explicitly use the default model (\`google/gemini-2.5-flash\`). (Default: `'google/gemini-2.5-flash' (when using observationalMemory: true)`)
@@ -40,7 +42,7 @@ The `observationalMemory` option accepts `true`, a configuration object, or `fal
 
 **observation.instruction** (`string`): Custom instruction appended to the Observer's system prompt. Use this to customize what the Observer focuses on, such as domain-specific preferences or priorities.
 
-**observation.messageTokens** (`number`): Token count of unobserved messages that triggers observation. When unobserved message tokens exceed this threshold, the Observer agent is called.
+**observation.messageTokens** (`number`): Token count of unobserved messages that triggers observation. When unobserved message tokens exceed this threshold, the Observer agent is called. Image parts are included with model-aware estimates when possible, with deterministic fallbacks when image metadata is incomplete. Image-like \`file\` parts are counted the same way when uploads are normalized as files.
 
 **observation.maxTokensPerBatch** (`number`): Maximum tokens per batch when observing multiple threads in resource scope. Threads are chunked into batches of this size and processed in parallel. Lower values mean more parallelism but more API calls.
 
@@ -80,9 +82,9 @@ OM persists token payload estimates so repeated counting can reuse prior tiktoke
 
 - Part-level cache: `part.providerMetadata.mastra`.
 - String-content fallback cache: message-level metadata when no parts exist.
-- Cache entries are ignored and recomputed if cache version/tokenizer source does not match.
-- Per-message and per-conversation overhead are always recomputed at runtime and are not cached.
-- `data-*` and `reasoning` parts are skipped and do not receive cache entries.
+- Cache entries are ignored and recomputed if cache version/tokenizer source doesn't match.
+- Per-message and per-conversation overhead are always recomputed at runtime and aren't cached.
+- `data-*` and `reasoning` parts are skipped and don't receive cache entries.
 
 ## Examples
 
@@ -283,7 +285,7 @@ observationalMemory: {
 
 Setting `bufferTokens: false` disables both observation and reflection async buffering. Observations and reflections will run synchronously when their thresholds are reached.
 
-> **Note:** Async buffering is not supported with `scope: 'resource'` and is automatically disabled in resource scope.
+> **Note:** Async buffering isn't supported with `scope: 'resource'` and is automatically disabled in resource scope.
 
 ## Streaming data parts
 

package/dist/docs/references/reference-processors-token-limiter-processor.md

@@ -47,8 +47,8 @@ const processor = new TokenLimiterProcessor({
 
 When used as an input processor, `TokenLimiterProcessor` throws a `TripWire` error in the following cases:
 
-- **Empty messages**: If there are no messages to process, a TripWire is thrown because you cannot send an LLM request with no messages.
-- **System messages exceed limit**: If system messages alone exceed the token limit, a TripWire is thrown because you cannot send an LLM request with only system messages and no user/assistant messages.
+- **Empty messages**: If there are no messages to process, a TripWire is thrown because you can't send an LLM request with no messages.
+- **System messages exceed limit**: If system messages alone exceed the token limit, a TripWire is thrown because you can't send an LLM request with only system messages and no user/assistant messages.
 
 ```typescript
 import { TripWire } from '@mastra/core/agent'

package/dist/docs/references/reference-storage-dynamodb.md

@@ -1,8 +1,8 @@
-# DynamoDB Storage
+# DynamoDB storage
 
 The DynamoDB storage implementation provides a scalable and performant NoSQL database solution for Mastra, leveraging a single-table design pattern with [ElectroDB](https://electrodb.dev/).
 
-> **Observability Not Supported:** DynamoDB storage **does not support the observability domain**. Traces from the `DefaultExporter` cannot be persisted to DynamoDB, and Mastra Studio's observability features won't work with DynamoDB as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
+> **Observability Not Supported:** DynamoDB storage **doesn't support the observability domain**. Traces from the `DefaultExporter` can't be persisted to DynamoDB, and Mastra Studio's observability features won't work with DynamoDB as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
 
 > **Item Size Limit:** DynamoDB enforces a **400 KB maximum item size**. This limit can be exceeded when storing messages with base64-encoded attachments such as images. See [Handling large attachments](https://mastra.ai/docs/memory/storage) for workarounds including uploading attachments to external storage.
 
@@ -120,7 +120,7 @@ For local development, you can use [DynamoDB Local](https://docs.aws.amazon.com/
 
 **config.ttl** (`object`): TTL (Time To Live) configuration for automatic data expiration. Configure per entity type: thread, message, trace, eval, workflow\_snapshot, resource, score. Each entity config includes: enabled (boolean), attributeName (string, default: 'ttl'), defaultTtlSeconds (number).
 
-## TTL (Time To Live) Configuration
+## TTL (time to live) configuration
 
 DynamoDB TTL allows you to automatically delete items after a specified time period. This is useful for:
 
@@ -211,12 +211,12 @@ aws dynamodb update-time-to-live \
 1. Go to the DynamoDB console
 2. Select your table
 3. Go to "Additional settings" tab
-4. Under "Time to Live (TTL)", click "Manage TTL"
+4. Under "Time to Live (TTL)", select "Manage TTL"
 5. Enable TTL and specify the attribute name (default: `ttl`)
 
 > **Note:** DynamoDB deletes expired items within 48 hours after expiration. Items remain queryable until actually deleted.
 
-## AWS IAM Permissions
+## AWS IAM permissions
 
 The IAM role or user executing the code needs appropriate permissions to interact with the specified DynamoDB table and its indexes. Below is a sample policy. Replace `${YOUR_TABLE_NAME}` with your actual table name and `${YOUR_AWS_REGION}` and `${YOUR_AWS_ACCOUNT_ID}` with appropriate values.
 
@@ -246,7 +246,7 @@ The IAM role or user executing the code needs appropriate permissions to interac
 }
 ```
 
-## Key Considerations
+## Key considerations
 
 Before diving into the architectural details, keep these key points in mind when working with the DynamoDB storage adapter:
 
@@ -255,7 +255,7 @@ Before diving into the architectural details, keep these key points in mind when
 - **Understanding GSIs:** Familiarity with how the GSIs are structured (as per `TABLE_SETUP.md`) is important for understanding data retrieval and potential query patterns.
 - **ElectroDB:** The adapter uses ElectroDB to manage interactions with DynamoDB, providing a layer of abstraction and type safety over raw DynamoDB operations.
 
-## Architectural Approach
+## Architectural approach
 
 This storage adapter utilizes a **single-table design pattern** leveraging [ElectroDB](https://electrodb.dev/), a common and recommended approach for DynamoDB. This differs architecturally from relational database adapters (like `@mastra/pg` or `@mastra/libsql`) that typically use multiple tables, each dedicated to a specific entity (threads, messages, etc.).
 

package/dist/docs/references/reference-storage-libsql.md

@@ -1,4 +1,4 @@
-# libSQL Storage
+# libSQL storage
 
 [libSQL](https://docs.turso.tech/libsql) is an open-source, SQLite-compatible database that supports both local and remote deployments. It can be used to store message history, workflow snapshots, traces, and eval scores.
 

package/dist/docs/references/reference-storage-mongodb.md

@@ -1,4 +1,4 @@
-# MongoDB Storage
+# MongoDB storage
 
 The MongoDB storage implementation provides a scalable storage solution using MongoDB databases with support for both document storage and vector operations.
 
@@ -56,7 +56,7 @@ const storage = new MongoDBStore({
 
 > **Deprecation Notice:** The `url` parameter is deprecated but still supported for backward compatibility. Please use `uri` instead in all new code.
 
-## Constructor Examples
+## Constructor examples
 
 You can instantiate `MongoDBStore` in the following ways:
 
@@ -84,7 +84,7 @@ const store2 = new MongoDBStore({
 })
 ```
 
-## Additional Notes
+## Additional notes
 
 ### Collection Management
 
@@ -136,9 +136,9 @@ const memoryStore = await storage.getStore('memory')
 const thread = await memoryStore?.getThreadById({ threadId: '...' })
 ```
 
-> **Warning:** If `init()` is not called, collections won't be created and storage operations will fail silently or throw errors.
+> **Warning:** If `init()` isn't called, collections won't be created and storage operations will fail silently or throw errors.
 
-## Vector Search Capabilities
+## Vector search capabilities
 
 MongoDB storage includes built-in vector search capabilities for AI applications:
 
@@ -190,7 +190,7 @@ const results = await vectorStore.query({
 });
 ```
 
-## Usage Example
+## Usage example
 
 ### Adding memory to an agent
 

package/dist/docs/references/reference-storage-postgresql.md

@@ -1,4 +1,4 @@
-# PostgreSQL Storage
+# PostgreSQL storage
 
 The PostgreSQL storage implementation provides a production-ready storage solution using PostgreSQL databases.
 
@@ -71,7 +71,7 @@ const storage = new PostgresStore({
 
 **indexes** (`CreateIndexOptions[]`): Custom indexes to create during initialization.
 
-## Constructor Examples
+## Constructor examples
 
 You can instantiate `PostgresStore` in the following ways:
 
@@ -119,7 +119,7 @@ const store4 = new PostgresStore({
 })
 ```
 
-## Additional Notes
+## Additional notes
 
 ### Schema Management
 
@@ -177,7 +177,7 @@ const memoryStore = await storage.getStore('memory')
 const thread = await memoryStore?.getThreadById({ threadId: '...' })
 ```
 
-> **Warning:** If `init()` is not called, tables won't be created and storage operations will fail silently or throw errors.
+> **Warning:** If `init()` isn't called, tables won't be created and storage operations will fail silently or throw errors.
 
 ### Using an Existing Pool
 
@@ -201,7 +201,7 @@ const storage = new PostgresStore({
 
 **Pool lifecycle behavior:**
 
-- When you **provide a pool**: Mastra uses your pool but does **not** close it when `store.close()` is called. You manage the pool lifecycle.
+- When you **provide a pool**: Mastra uses your pool but **doesn't** close it when `store.close()` is called. You manage the pool lifecycle.
 - When Mastra **creates a pool**: Mastra owns the pool and will close it when `store.close()` is called.
 
 ### Direct Database and Pool Access
@@ -316,7 +316,7 @@ This pattern ensures only one `PostgresStore` instance is created regardless of
 
 > **Tip:** This singleton pattern is only necessary during local development with HMR. In production builds, modules are only loaded once.
 
-## Usage Example
+## Usage example
 
 ### Adding memory to an agent
 
@@ -387,7 +387,7 @@ for await (const chunk of stream.textStream) {
 }
 ```
 
-## Index Management
+## Index management
 
 PostgreSQL storage provides index management to optimize query performance.
 

package/dist/docs/references/reference-storage-upstash.md

@@ -1,10 +1,10 @@
-# Upstash Storage
+# Upstash storage
 
 The Upstash storage implementation provides a serverless-friendly storage solution using Upstash's Redis-compatible key-value store.
 
 > **Pricing:** When using Mastra with Upstash, the pay-as-you-go model can result in unexpectedly high costs due to the high volume of Redis commands generated during agent conversations. We strongly recommend using a **fixed pricing plan** for predictable costs. See [Upstash pricing](https://upstash.com/pricing/redis) for details and [GitHub issue #5850](https://github.com/mastra-ai/mastra/issues/5850) for context.
 
-> **Observability Not Supported:** Upstash storage **does not support the observability domain**. Traces from the `DefaultExporter` cannot be persisted to Upstash, and Mastra Studio's observability features won't work with Upstash as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
+> **Observability Not Supported:** Upstash storage **doesn't support the observability domain**. Traces from the `DefaultExporter` can't be persisted to Upstash, and Mastra Studio's observability features won't work with Upstash as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
 
 ## Installation
 
@@ -52,7 +52,7 @@ const storage = new UpstashStore({
 
 **prefix** (`string`): Key prefix for all stored items (Default: `mastra:`)
 
-## Additional Notes
+## Additional notes
 
 ### Key Structure
 
@@ -87,7 +87,7 @@ For optimal performance:
 - Monitor Redis memory usage
 - Consider data expiration policies if needed
 
-## Usage Example
+## Usage example
 
 ### Adding memory to an agent