@mastra/libsql 0.0.0-fix-thread-subscription-multi-instance-redis-streams-20260720232722 → 0.0.0-fix-thread-subscription-multi-instance-redis-streams-20260730204150

package/dist/docs/references/docs-rag-retrieval.md

@@ -160,15 +160,15 @@ When creating the tool, pay special attention to the tool's name and description
 
 This is particularly useful when:
 
-- Your agent needs to dynamically decide what information to retrieve
+- Your agent needs to decide at runtime what information to retrieve
 - The retrieval process requires complex decision-making
 - You want the agent to combine multiple retrieval strategies based on context
 
 #### Database-Specific Configurations
 
-The Vector Query Tool supports database-specific configurations that enable you to leverage unique features and optimizations of different vector stores.
+The Vector Query Tool supports database-specific configurations that enable you to use unique features and optimizations of different vector stores.
 
-> **Note:** These configurations are for **query-time options** like namespaces, performance tuning, and filtering—not for database connection setup.
+> **Note:** These configurations are for **query-time options** like namespaces, performance tuning, and filtering, not for database connection setup.
 >
 > Connection credentials (URLs, auth tokens) are configured when you instantiate the vector store class (e.g., `new LibSQLVector({ url: '...' })`).
 
@@ -235,7 +235,7 @@ const lanceQueryTool = createVectorQueryTool({
 - **pgVector optimization**: Control search accuracy and speed with ef/probes parameters
 - **Quality filtering**: Set minimum similarity thresholds to improve result relevance
 - **LanceDB tables**: Separate data into tables for better organization and performance
-- **Runtime flexibility**: Override configurations dynamically based on context
+- **Runtime flexibility**: Override configurations at runtime based on context
 
 **Common Use Cases:**
 
@@ -274,7 +274,7 @@ import { PGVECTOR_PROMPT } from '@mastra/pg'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${PGVECTOR_PROMPT}
@@ -291,7 +291,7 @@ import { PINECONE_PROMPT } from '@mastra/pinecone'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${PINECONE_PROMPT}
@@ -308,7 +308,7 @@ import { QDRANT_PROMPT } from '@mastra/qdrant'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${QDRANT_PROMPT}
@@ -325,7 +325,7 @@ import { CHROMA_PROMPT } from '@mastra/chroma'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${CHROMA_PROMPT}
@@ -342,7 +342,7 @@ import { ASTRA_PROMPT } from '@mastra/astra'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${ASTRA_PROMPT}
@@ -359,7 +359,7 @@ import { LIBSQL_PROMPT } from '@mastra/libsql'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${LIBSQL_PROMPT}
@@ -376,7 +376,7 @@ import { UPSTASH_PROMPT } from '@mastra/upstash'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${UPSTASH_PROMPT}
@@ -393,7 +393,7 @@ import { VECTORIZE_PROMPT } from '@mastra/vectorize'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${VECTORIZE_PROMPT}
@@ -410,7 +410,7 @@ import { MONGODB_PROMPT } from '@mastra/mongodb'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${MONGODB_PROMPT}
@@ -427,7 +427,7 @@ import { OPENSEARCH_PROMPT } from '@mastra/opensearch'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${OPENSEARCH_PROMPT}
@@ -444,7 +444,7 @@ import { S3VECTORS_PROMPT } from '@mastra/s3vectors'
 export const ragAgent = new Agent({
   id: 'rag-agent',
   name: 'RAG Agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   instructions: `
   Process queries using the provided context. Structure responses to be concise and relevant.
   ${S3VECTORS_PROMPT}
@@ -455,10 +455,10 @@ export const ragAgent = new Agent({
 
 ### Re-ranking
 
-Initial vector similarity search can sometimes miss nuanced relevance. Re-ranking is a more computationally expensive process, but more accurate algorithm that improves results by:
+Initial vector similarity search can sometimes miss detailed relevance. Re-ranking is a more computationally expensive process, but more accurate algorithm that improves results by:
 
 - Considering word order and exact matches
-- Applying more sophisticated relevance scoring
+- Applying more advanced relevance scoring
 - Using a method called cross-attention between query and documents
 
 Here's how to use re-ranking:
@@ -476,7 +476,7 @@ const initialResults = await pgVector.query({
 // Create a relevance scorer
 const relevanceProvider = new MastraAgentRelevanceScorer(
   'relevance-scorer',
-  'openai/gpt-5.5',
+  'openai/gpt-5.6-sol',
 )
 
 // Re-rank the results

package/dist/docs/references/docs-storage-overview.md

@@ -14,7 +14,7 @@ Storage powers:
 
 ## When to configure storage
 
-Configure a persistent storage adapter when state must survive restarts, be shared across processes, or be visible in Studio across sessions. The default in-memory store is useful for tests and short local experiments, but it loses data when the process exits.
+Configure a persistent storage adapter when state must survive restarts or be shared across processes. Persistent storage also keeps state visible in Studio across sessions. The default in-memory store is useful for tests and short local experiments, but it loses data when the process exits.
 
 Use storage when your application needs any of these behaviors:
 
@@ -144,7 +144,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support agent',
   instructions: 'Answer customer support questions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new PostgresStore({
       id: 'support-agent-storage',

package/dist/docs/references/docs-workflows-snapshots.md

@@ -24,11 +24,11 @@ Snapshots are the key mechanism enabling Mastra's suspend and resume capabilitie
 5. Later, when `resume()` is called on the suspended step, the snapshot is retrieved
 6. The workflow execution resumes from exactly where it left off
 
-This mechanism provides a powerful way to implement human-in-the-loop workflows, handle rate limiting, wait for external resources, and implement complex branching workflows that may need to pause for extended periods.
+The mechanism provides a powerful way to implement human-in-the-loop workflows, handle rate limiting, wait for external resources, and implement complex branching workflows that may need to pause for extended periods.
 
 ## Snapshot anatomy
 
-Each snapshot includes the `runId`, input, step status (`success`, `suspended`, etc.), any suspend and resume payloads, and the final output. This ensures full context is available when resuming execution.
+Each snapshot includes the `runId`, input, step status (`success`, `suspended`, etc.), any suspend and resume payloads, and the final output. As a result, full context is available when resuming execution.
 
 ```json
 {
@@ -152,7 +152,7 @@ export const mastra = new Mastra({
 1. **Ensure Serializability**: Any data that needs to be included in the snapshot must be serializable (convertible to JSON).
 2. **Minimize Snapshot Size**: Avoid storing large data objects directly in the workflow context. Instead, store references to them (like IDs) and retrieve the data when needed.
 3. **Handle Resume Context Carefully**: When resuming a workflow, carefully consider what context to provide. This will be merged with the existing snapshot data.
-4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows, especially long-running ones, to ensure they're properly resumed.
+4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows and especially long-running ones, plus to ensure they're properly resumed.
 5. **Consider Storage Scaling**: For applications with many suspended workflows, ensure your storage solution is appropriately scaled.
 
 ## Custom snapshot metadata

package/dist/docs/references/reference-core-mastra-class.md

@@ -103,4 +103,51 @@ Visit the [Configuration reference](https://mastra.ai/reference/configuration) f
 
 **versions.agents.versionId** (`string`): The ID of a specific version to use.
 
-**versions.agents.status** (`'draft' | 'published'`): Select the latest version with this publication status.
+**versions.agents.status** (`'draft' | 'published'`): Select the latest version with this publication status.
+
+**workers** (`MastraWorker[] | false`): Configure which workers run in this Mastra instance. When omitted, Mastra auto-creates default workers based on your PubSub and config. Pass false to disable all event processing (useful when running standalone workers separately). Pass a MastraWorker\[] to add custom workers — they are merged with the auto-created defaults, and a custom worker with the same name as a default replaces it.
+
+**backgroundTasks** (`BackgroundTaskManagerConfig`): Configure background task execution for agents. See background tasks configuration reference for all options.
+
+**backgroundTasks.enabled** (`boolean`): Enable background task dispatch.
+
+**backgroundTasks.globalConcurrency** (`number`): Max concurrent tasks across all agents.
+
+**backgroundTasks.perAgentConcurrency** (`number`): Max concurrent tasks per agent.
+
+**backgroundTasks.backpressure** (`'queue' | 'reject' | 'fallback-sync'`): Behavior when concurrency limit is reached.
+
+**backgroundTasks.defaultTimeoutMs** (`number`): Default task timeout in milliseconds.
+
+**backgroundTasks.defaultRetries** (`RetryConfig`): Default retry configuration.
+
+**scheduler** (`object`): Configure the scheduler worker for cron-driven workflow triggers. Auto-enables when any workflow declares a schedule. See Scheduled workflows.
+
+**scheduler.enabled** (`boolean`): Explicitly enable or disable the scheduler.
+
+**recovery** (`MastraRecoveryConfig`): Boot-time recovery behavior for orphaned agent and workflow runs. See Crash recovery. (Default: `{ durableAgents: 'off' }`)
+
+**recovery.durableAgents** (`'auto' | 'off'`): Set to 'auto' to automatically re-drive orphaned RUNNING durable agent runs on server boot. Recovery re-issues LLM calls and re-executes tool calls, so tools must be idempotent. See Crash recovery.
+
+## Methods
+
+### `recoverAllDurableAgents()`
+
+Re-drives every orphaned `running` durable-agent run across all registered durable agents. Called automatically on boot when `recovery.durableAgents` is `'auto'`. You can also call it directly for manual recovery or from a scheduled task.
+
+Requires persistent storage — with an in-memory store there is nothing to recover after a process restart.
+
+```typescript
+const result = await mastra.recoverAllDurableAgents()
+// { agents: 2, recovered: 3, succeeded: 3, failed: 0 }
+```
+
+Returns:
+
+**agents** (`number`): Number of durable agents scanned.
+
+**recovered** (`number`): Total number of runs that were re-driven.
+
+**succeeded** (`number`): Runs that restarted successfully.
+
+**failed** (`number`): Runs whose restart threw an error.

package/dist/docs/references/reference-file-based-agents-storage.md

@@ -27,4 +27,4 @@ Mastra registers the store before file-based agents and workflows, so storage-de
 
 ## Precedence with code
 
-Code-registered storage wins over `storage.ts`. Use `storage.ts` when one project-wide store is enough; use code registration when setup depends on runtime wiring in `src/mastra/index.ts`.
+Code-registered storage wins over `storage.ts`. Use `storage.ts` when one project-wide store is enough. Use code registration when setup depends on runtime wiring in `src/mastra/index.ts`.

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

@@ -2,7 +2,7 @@
 
 # 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.
+The `Memory` class provides a reliable 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.
 
 ## Usage example
 
@@ -14,7 +14,7 @@ export const agent = new Agent({
   id: 'test-agent',
   name: 'test-agent',
   instructions: 'You are an agent with memory.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     options: {
       workingMemory: {
@@ -47,7 +47,7 @@ export const agent = new Agent({
 
 **options.observationalMemory** (`boolean | ObservationalMemoryOptions`): Enable Observational Memory for long-context agentic memory. Set to true for defaults, or pass a config object to customize token budgets, models, and scope. See Observational Memory reference for configuration details.
 
-**options.generateTitle** (`boolean | { model: DynamicArgument<MastraLanguageModel>; instructions?: DynamicArgument<string> }`): Controls automatic thread title generation from the user's first message. Can be a boolean or an object with custom model and instructions.
+**options.generateTitle** (`boolean | { model: DynamicArgument<MastraLanguageModel>; instructions?: DynamicArgument<string> }`): Controls automatic thread title generation from the conversation transcript. Can be a boolean or an object with custom model and instructions.
 
 ## Returns
 
@@ -63,7 +63,7 @@ import { LibSQLStore, LibSQLVector } from '@mastra/libsql'
 export const agent = new Agent({
   name: 'test-agent',
   instructions: 'You are an agent with memory.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'test-agent-storage',
@@ -100,7 +100,7 @@ import { PgStore, PgVector } from '@mastra/pg'
 export const agent = new Agent({
   name: 'pg-agent',
   instructions: 'You are an agent with optimized PostgreSQL memory.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new PgStore({
       id: 'pg-agent-storage',

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

@@ -2,7 +2,7 @@
 
 # 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/).
+The DynamoDB storage implementation provides a high-capacity and performant NoSQL database solution for Mastra, using a single-table design pattern with [ElectroDB](https://electrodb.dev/).
 
 > **Observability Not Supported:** DynamoDB storage **doesn't support the observability domain**. Traces from the `MastraStorageExporter` can't be persisted to DynamoDB, and [Studio's](https://mastra.ai/docs/studio/overview) 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.
 
@@ -124,7 +124,7 @@ For local development, you can use [DynamoDB Local](https://docs.aws.amazon.com/
 
 ## TTL (time to live) configuration
 
-DynamoDB TTL allows you to automatically delete items after a specified time period. This is useful for:
+DynamoDB TTL allows you to automatically delete items after a specified duration for these use cases:
 
 - **Cost optimization**: Automatically remove old data to reduce storage costs
 - **Data lifecycle management**: Implement retention policies for compliance
@@ -259,19 +259,19 @@ Before diving into the architectural details, keep these key points in mind when
 
 ## 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.).
+This storage adapter utilizes a **single-table design pattern** with [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.).
 
 Key aspects of this approach:
 
-- **DynamoDB Native:** The single-table design is optimized for DynamoDB's key-value and query capabilities, often leading to better performance and scalability compared to mimicking relational models.
+- **DynamoDB Native:** The single-table design is optimized for DynamoDB's key-value and query capabilities, often leading to better performance and capacity compared to mimicking relational models.
 - **External Table Management:** Unlike some adapters that might offer helper functions to create tables via code, this adapter **expects the DynamoDB table and its associated Global Secondary Indexes (GSIs) to be provisioned externally** before use. Please refer to [TABLE\_SETUP.md](https://github.com/mastra-ai/mastra/blob/main/stores/dynamodb/TABLE_SETUP.md) for detailed instructions using tools like AWS CloudFormation or CDK. The adapter focuses solely on interacting with the pre-existing table structure.
 - **Consistency via Interface:** While the underlying storage model differs, this adapter adheres to the same `MastraStorage` interface as other adapters, ensuring it can be used interchangeably within the Mastra `Memory` component.
 
 ### Mastra Data in the Single Table
 
-Within the single DynamoDB table, different Mastra data entities (such as Threads, Messages, Traces, Evals, and Workflows) are managed and distinguished using ElectroDB. ElectroDB defines specific models for each entity type, which include unique key structures and attributes. This allows the adapter to store and retrieve diverse data types efficiently within the same table.
+Within the single DynamoDB table, different Mastra data entities (such as Threads, Messages, Traces, Evals, and Workflows) are managed and distinguished using ElectroDB. ElectroDB defines specific models for each entity type, which include unique key structures and attributes. It allows the adapter to store and retrieve diverse data types efficiently within the same table.
 
-For example, a `Thread` item might have a primary key like `THREAD#<threadId>`, while a `Message` item belonging to that thread might use `THREAD#<threadId>` as a partition key and `MESSAGE#<messageId>` as a sort key. The Global Secondary Indexes (GSIs), detailed in `TABLE_SETUP.md`, are strategically designed to support common access patterns across these different entities, such as fetching all messages for a thread or querying traces associated with a particular workflow.
+For example, a `Thread` item might have a primary key like `THREAD#<threadId>`, while a `Message` item belonging to that thread might use `THREAD#<threadId>` as a partition key and `MESSAGE#<messageId>` as a sort key. The Global Secondary Indexes (GSIs), detailed in `TABLE_SETUP.md`, are strategically designed to support common access patterns across these different entities, such as fetching all messages for a thread or querying traces associated with a workflow.
 
 ### Advantages of Single-Table Design
 
@@ -279,6 +279,6 @@ This implementation uses a single-table design pattern with ElectroDB, which off
 
 1. **Lower cost (potentially):** Fewer tables can simplify Read/Write Capacity Unit (RCU/WCU) provisioning and management, especially with on-demand capacity.
 2. **Better performance:** Related data can be co-located or accessed efficiently through GSIs, enabling fast lookups for common access patterns.
-3. **Simplified administration:** Fewer distinct tables to monitor, back up, and manage.
+3. **Simplified administration:** Fewer distinct tables to monitor and back up, with less to manage.
 4. **Reduced complexity in access patterns:** ElectroDB helps manage the complexity of item types and access patterns on a single table.
 5. **Transaction support:** DynamoDB transactions can be used across different "entity" types stored within the same table if needed.

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

@@ -4,9 +4,9 @@
 
 Storage grows without bound by default. Retention is an opt-in, age-based cleanup system: you declare per-table `maxAge` policies in the `retention` config, then call `storage.prune()` to delete rows older than their configured age. Anything you don't configure is kept forever, so there is no behavior change until you opt in.
 
-`prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk — on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
+`prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk: on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
 
-Retention covers **growth tables** only — tables that accumulate rows unbounded as a side effect of normal operation (conversation history, telemetry, job and run records, schedule fire history, event feeds). User-authored artifacts and config (agents, skills, workspaces, prompt blocks, datasets, schedule definitions, channel installations, and so on) grow with user intent and are edited or deleted explicitly, so they're not valid retention keys.
+Retention covers **growth tables** only: tables that accumulate rows unbounded as a side effect of normal operation (conversation history, telemetry, job and run records, schedule fire history, event feeds). User-authored artifacts and config (agents, skills, workspaces, prompt blocks, datasets, schedule definitions, channel installations, and so on) grow with user intent and are edited or deleted explicitly, so they're not valid retention keys.
 
 The reference implementations are [libSQL](https://mastra.ai/reference/storage/libsql), [PostgreSQL](https://mastra.ai/reference/storage/postgresql), and [MongoDB](https://mastra.ai/reference/storage/mongodb). Other adapters keep rows forever until they implement retention.
 
@@ -31,7 +31,7 @@ const storage = new LibSQLStore({
   },
 })
 
-// Wire this to your own cron/scheduler — Mastra never runs it for you.
+// Wire this to your own cron/scheduler: Mastra never runs it for you.
 const results = await storage.prune()
 ```
 
@@ -65,35 +65,35 @@ Set the `retention` field on the store config.
 
 ### Retention-eligible tables
 
-Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data: creation time for append-only logs, last activity for live state, and completion time for jobs and runs (so in-flight work is never pruned).
-
-| Domain            | Table key          | Anchor column    | `maxAge` measures                                                 |
-| ----------------- | ------------------ | ---------------- | ----------------------------------------------------------------- |
-| `memory`          | `threads`          | `createdAt`      | Thread age                                                        |
-| `memory`          | `messages`         | `createdAt`      | Message age                                                       |
-| `memory`          | `resources`        | `createdAt`      | Resource age                                                      |
-| `threadState`     | `threadState`      | `updatedAt`      | Inactivity — state for still-active threads survives              |
-| `observability`   | `spans`            | `startedAt`      | Span age                                                          |
-| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                    |
-| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                       |
-| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                     |
-| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                  |
-| `scores`          | `scorers`          | `createdAt`      | Score record age                                                  |
-| `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity — suspended or long-running workflows survive          |
-| `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion — in-flight tasks (`NULL`) are never pruned |
-| `experiments`     | `experiments`      | `completedAt`    | Time since completion — running experiments are never pruned      |
-| `notifications`   | `notifications`    | `createdAt`      | Notification age                                                  |
-| `harness`         | `sessions`         | `createdAt`      | Session record age                                                |
-| `schedules`       | `triggers`         | `actual_fire_at` | Fire-history age (epoch-ms column)                                |
+Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data. Append-only logs use creation time, and live state uses last activity. Jobs and runs use completion time, so in-flight work is never pruned.
+
+| Domain            | Table key          | Anchor column    | `maxAge` measures                                                |
+| ----------------- | ------------------ | ---------------- | ---------------------------------------------------------------- |
+| `memory`          | `threads`          | `createdAt`      | Thread age                                                       |
+| `memory`          | `messages`         | `createdAt`      | Message age                                                      |
+| `memory`          | `resources`        | `createdAt`      | Resource age                                                     |
+| `threadState`     | `threadState`      | `updatedAt`      | Inactivity: state for still-active threads survives              |
+| `observability`   | `spans`            | `startedAt`      | Span age                                                         |
+| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                   |
+| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                      |
+| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                    |
+| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                 |
+| `scores`          | `scorers`          | `createdAt`      | Score record age                                                 |
+| `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity, suspended or long-running workflows survive          |
+| `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion, in-flight tasks (`NULL`) are never pruned |
+| `experiments`     | `experiments`      | `completedAt`    | Time since completion, running experiments are never pruned      |
+| `notifications`   | `notifications`    | `createdAt`      | Notification age                                                 |
+| `harness`         | `sessions`         | `createdAt`      | Session record age                                               |
+| `schedules`       | `triggers`         | `actual_fire_at` | Fire-history age (epoch-ms column)                               |
 
 > **Note:**
 >
 > - The memory `observational_memory` table has no timestamp anchor, so it can't be age-pruned and isn't a valid retention key.
 > - Experiments prune as whole units: an aged experiment's result rows are deleted together with it (results cascade with their parent), so a run is never left partially deleted. Retention doesn't have a separate `results` key.
-> - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire) — schedule definitions are config and aren't pruned.
+> - For `schedules`, the growth table is the fire history (`schedule_triggers`, one row per fire): schedule definitions are config and aren't pruned.
 > - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
 > - LibSQL supports all domains above; PostgreSQL and MongoDB support all except `threadState` and `harness`, which they don't implement.
-> - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows — effective granularity is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
+> - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
 
 ## Methods
 
@@ -103,11 +103,11 @@ Each domain declares which of its tables can be age-pruned and which timestamp c
 
 Deletes rows older than their configured `maxAge` across every domain that has a policy in `retention`. Returns one `PruneResult` per table touched. With no `retention` configured it's a no-op returning `[]`.
 
-`prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks — each batch is its own transaction — so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
+`prune()` is designed to be safe on tables with millions of rows. It deletes in bounded, batched chunks (each batch is its own transaction) so it never takes a long lock or bloats the transaction log. It never runs a `VACUUM`.
 
-Pass `options.retention` to replace the configured policies for that call only — for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
+Pass `options.retention` to replace the configured policies for that call only: for example to skip a domain (keep chat history) or prune more aggressively than the standing config. The store's configured `retention` is unchanged.
 
-Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy — never at `init()` — so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build; subsequent prunes reuse the index.
+Anchor-column indexes are created lazily on the first `prune()` call for each table with a policy (never at `init()`) so deployments that don't configure retention pay no extra index write or disk overhead. The first prune of an existing large table pays a one-time index build. Subsequent prunes reuse the index.
 
 ```typescript
 const results = await storage.prune({
@@ -156,7 +156,7 @@ interface PruneResult {
 
 ## Running prune on a schedule
 
-`prune()` has no built-in scheduler — you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
+`prune()` has no built-in scheduler: you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
 
 ```typescript
 // Runs on your own cron (node-cron, a workflow schedule, an external job, etc.).
@@ -173,7 +173,7 @@ async function retentionTick() {
 }
 ```
 
-You can also cancel a long-running prune with an `AbortSignal` — the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
+You can also cancel a long-running prune with an `AbortSignal`: the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
 
 ## MongoDB TTL indexes (alternative to prune)
 
@@ -192,7 +192,7 @@ MongoDB offers native [TTL (Time-To-Live) indexes](https://www.mongodb.com/docs/
 > - You need resumable, cancellable cleanup operations
 > - You're using composite storage with multiple databases
 >
-> Both approaches are valid. TTL is simpler; `prune()` gives more control.
+> Both approaches are valid. TTL is simpler. `prune()` gives more control.
 
 ### Setting up TTL indexes on MongoDB
 
@@ -232,9 +232,9 @@ const storage = new MongoDBStore({
 
 ## Reclaiming disk
 
-`prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing — for most users this alone solves the unbounded-growth problem.
+`prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing: for most users this alone solves the unbounded-growth problem.
 
-Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself, in a maintenance window — a full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
+Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself in a maintenance window. A full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
 
 For MongoDB, deleted documents are reused by future insertions. To reclaim disk space, run [`db.runCommand({ compact: "collection_name" })`](https://www.mongodb.com/docs/manual/reference/command/compact/) during a maintenance window.
 

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

@@ -85,7 +85,7 @@ const results = await store.query({
 
 ### `createIndex()`
 
-Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscores. The dimension must be a positive integer.
+Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscore characters. The dimension must be a positive integer.
 
 **indexName** (`string`): Name of the index to create
 
@@ -279,7 +279,7 @@ export const libsqlAgent = new Agent({
   name: 'libSQL Agent',
   instructions:
     'You are an AI agent with the ability to automatically recall memories from previous interactions.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   memory: new Memory({
     storage: new LibSQLStore({
       id: 'libsql-agent-storage',