@mastra/mcp-docs-server 1.1.26-alpha.1 → 1.1.26-alpha.11

package/.docs/docs/mastra-platform/overview.md

@@ -73,4 +73,6 @@ Develop your project locally with [`mastra dev`](https://mastra.ai/reference/cli
 
 Once you're ready to deploy your application to production, use [`mastra studio deploy`](https://mastra.ai/reference/cli/mastra) and [`mastra server deploy`](https://mastra.ai/reference/cli/mastra) to push your application to the cloud.
 
-Follow the [Studio deployment guide](https://mastra.ai/docs/studio/deployment) and [Server deployment guide](https://mastra.ai/guides/deployment/mastra-platform) for step-by-step instructions.
+Follow the [Studio deployment guide](https://mastra.ai/docs/studio/deployment) and [Server deployment guide](https://mastra.ai/guides/deployment/mastra-platform) for step-by-step instructions.
+
+If you host your Mastra application on your own infrastructure, you can still send observability data to Studio using the [CloudExporter](https://mastra.ai/docs/observability/tracing/exporters/cloud).

package/.docs/docs/memory/observational-memory.md

@@ -333,13 +333,33 @@ Reflection works similarly — the Reflector runs in the background when observa
 
 ### Settings
 
-| Setting                        | Default | What it controls                                                                                                                                                                      |
-| ------------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `observation.bufferTokens`     | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens` — with the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).    |
-| `observation.bufferActivation` | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history. |
-| `observation.blockAfter`       | `1.2`   | Safety threshold as a multiplier of `messageTokens`. At `1.2`, synchronous observation is forced at 36k tokens (1.2 × 30k). Only matters if buffering can't keep up.                  |
-| `reflection.bufferActivation`  | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                  |
-| `reflection.blockAfter`        | `1.2`   | Safety threshold for reflection, same logic as observation.                                                                                                                           |
+| Setting                        | Default | What it controls                                                                                                                                                                                                                                                                                                                       |
+| ------------------------------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `observation.bufferTokens`     | `0.2`   | How often to buffer. `0.2` means every 20% of `messageTokens` — with the default 30k threshold, that's roughly every 6k tokens. Can also be an absolute token count (e.g. `5000`).                                                                                                                                                     |
+| `observation.bufferActivation` | `0.8`   | How aggressively to clear the message window on activation. `0.8` means remove enough messages to keep only 20% of `messageTokens` remaining. Lower values keep more message history.                                                                                                                                                  |
+| `observation.blockAfter`       | `1.2`   | Safety threshold as a multiplier of `messageTokens`. At `1.2`, synchronous observation is forced at 36k tokens (1.2 × 30k). Only matters if buffering can't keep up.                                                                                                                                                                   |
+| `activateAfterIdle`            | none    | Forces buffered observations and buffered reflections to activate after a period of inactivity, even if their token thresholds have not been reached yet. Accepts milliseconds or duration strings like `300_000`, `"5m"`, or `"1hr"`. Set this to your prompt cache TTL if you want activation to happen before the next cold prompt. |
+| `activateOnProviderChange`     | `false` | Forces buffered observations and reflections to activate when the next step uses a different `provider/model` than the one that produced the latest assistant step. Use this when switching providers or models would invalidate prompt cache reuse.                                                                                   |
+| `reflection.bufferActivation`  | `0.5`   | When to start background reflection. `0.5` means reflection begins when observations reach 50% of the `observationTokens` threshold.                                                                                                                                                                                                   |
+| `reflection.blockAfter`        | `1.2`   | Safety threshold for reflection, same logic as observation.                                                                                                                                                                                                                                                                            |
+
+If you're relying on prompt caching, set `activateAfterIdle` to match your cache TTL. That way, once a thread has been idle long enough for the cache to expire, the next request can activate buffered observations or reflections first and send a smaller compressed context window.
+
+```typescript
+const memory = new Memory({
+  options: {
+    observationalMemory: {
+      model: 'google/gemini-2.5-flash',
+      activateAfterIdle: '5m',
+      activateOnProviderChange: true,
+    },
+  },
+})
+```
+
+With a 5-minute prompt cache TTL, this activates buffered context after 5 minutes of inactivity so the next uncached prompt uses observations and reflections instead of a larger raw message window. If you prefer, `300_000` works the same way.
+
+Changing model or providers mid-thread will invalidate the prompt cache. If your agent can switch between providers or models mid-thread, `activateOnProviderChange: true` forces buffered context to activate before the new provider runs. That avoids sending a large raw window to a provider that cannot reuse the previous prompt cache.
 
 ### Disabling
 

package/.docs/docs/observability/tracing/exporters/cloud.md

@@ -2,6 +2,18 @@
 
 The `CloudExporter` sends traces, logs, metrics, scores, and feedback to the Mastra platform. Use it to route observability data from any Mastra app to a hosted project in the Mastra platform.
 
+> **Self-hosted or standalone apps:** If you host your Mastra application on your own infrastructure (not on Mastra Platform), you still need a deployed Studio project to view traces, logs, and metrics. `CloudExporter` sends data to a Studio project, so one must exist before you can use it.
+>
+> 1. [Create a Mastra project](https://mastra.ai/guides/getting-started/quickstart) if you don't have one yet.
+> 2. [Deploy Studio](https://mastra.ai/docs/studio/deployment) to the Mastra platform with `mastra studio deploy`.
+> 3. Follow the [quickstart steps below](#quickstart) to create an access token and find your project ID.
+
+## Version compatibility
+
+- Use `CloudExporter` with `@mastra/observability@1.8.0` or later.
+- If you use `@mastra/observability@1.8.0` through `1.9.1`, set `MASTRA_CLOUD_TRACES_ENDPOINT=https://observability.mastra.ai` in addition to `MASTRA_CLOUD_ACCESS_TOKEN` and `MASTRA_PROJECT_ID`.
+- Starting in `@mastra/observability@1.9.2`, `CloudExporter` defaults to `https://observability.mastra.ai`, so `MASTRA_CLOUD_TRACES_ENDPOINT` is only required when you want to send telemetry to a different collector.
+
 ## Quickstart
 
 To connect `CloudExporter`, create an access token, find the destination `projectId`, and add the exporter to your observability config.
@@ -57,52 +69,30 @@ MASTRA_PROJECT_ID=<your-project-id>
 
 ### 3. Set your environment variables
 
-Tokens created with `mastra auth tokens create` are organization-scoped, so `MASTRA_PROJECT_ID` is required.
-
-If you use a project-scoped token from the Mastra platform instead, `CloudExporter` can route without `projectId`, but setting it explicitly is still supported.
-
-Add both values to your environment:
+Set both values in your environment so `CloudExporter` can authenticate and route telemetry to the correct project:
 
 ```bash
 MASTRA_CLOUD_ACCESS_TOKEN=<your-cloud-access-token>
 MASTRA_PROJECT_ID=<your-project-id>
 ```
 
-For example:
+If you use `@mastra/observability@1.8.0` through `1.9.1`, also set the Mastra platform collector explicitly:
 
 ```bash
-MASTRA_CLOUD_ACCESS_TOKEN=<your-cloud-access-token>
-MASTRA_PROJECT_ID=<your-project-id>
+MASTRA_CLOUD_TRACES_ENDPOINT=https://observability.mastra.ai
 ```
 
-### 4. Enable `CloudExporter`
-
-The following example demonstrates how to add `CloudExporter` to your observability config:
-
-```ts
-import { Mastra } from '@mastra/core'
-import { Observability, CloudExporter } from '@mastra/observability'
+If you want to send telemetry somewhere other than Mastra platform, set `MASTRA_CLOUD_TRACES_ENDPOINT` as well. Pass either a base origin or a full traces publish URL ending in `/spans/publish`.
 
-export const mastra = new Mastra({
-  observability: new Observability({
-    configs: {
-      production: {
-        serviceName: 'my-service',
-        exporters: [
-          new CloudExporter({
-            accessToken: process.env.MASTRA_CLOUD_ACCESS_TOKEN,
-            projectId: process.env.MASTRA_PROJECT_ID,
-          }),
-        ],
-      },
-    },
-  }),
-})
+```bash
+MASTRA_CLOUD_TRACES_ENDPOINT=https://collector.example.com
 ```
 
-Set `serviceName` in code on the observability config, not on `CloudExporter` itself. In the example above, the value is `configs.production.serviceName`.
+When you pass a base origin, `CloudExporter` derives the matching publish URLs for traces, logs, metrics, scores, and feedback automatically.
+
+### 4. Enable `CloudExporter`
 
-For example:
+The following example demonstrates how to add `CloudExporter` to your observability config:
 
 ```ts
 import { Mastra } from '@mastra/core'
@@ -120,6 +110,8 @@ export const mastra = new Mastra({
 })
 ```
 
+Set `serviceName` on the observability config, not on `CloudExporter` itself.
+
 Use a stable `serviceName` value. In Studio, traces can be filtered by **Deployments → Service Name**, so a consistent name makes traces easier to find.
 
 Visit [Observability configuration reference](https://mastra.ai/reference/observability/tracing/configuration) for the full observability config shape.
@@ -130,7 +122,7 @@ If you prefer, rely entirely on environment variables:
 new CloudExporter()
 ```
 
-With `MASTRA_CLOUD_ACCESS_TOKEN` and `MASTRA_PROJECT_ID` set, `CloudExporter` automatically sends data to the correct Mastra platform project.
+With `MASTRA_CLOUD_ACCESS_TOKEN` and `MASTRA_PROJECT_ID` set, `CloudExporter` sends data to the Mastra platform project you configured. If you also set `MASTRA_CLOUD_TRACES_ENDPOINT`, it sends data to that collector instead.
 
 > **Note:** Visit [CloudExporter reference](https://mastra.ai/reference/observability/tracing/exporters/cloud-exporter) for the full list of configuration options.
 
@@ -162,13 +154,17 @@ export const mastra = new Mastra({
 
 ## Complete configuration
 
-The following example demonstrates how to configure custom endpoints and batching behavior:
+`CloudExporter` defaults to Mastra platform. If you want to send telemetry to a different collector, set `MASTRA_CLOUD_TRACES_ENDPOINT` in your environment or pass `endpoint` in code.
+
+```bash
+MASTRA_CLOUD_TRACES_ENDPOINT=https://collector.example.com
+```
+
+The following example demonstrates how to override the collector endpoint and batching behavior in code:
 
 ```ts
 new CloudExporter({
-  accessToken: process.env.MASTRA_CLOUD_ACCESS_TOKEN,
-  projectId: process.env.MASTRA_PROJECT_ID,
-  endpoint: 'https://cloud.your-domain.com',
+  endpoint: 'https://collector.example.com',
   maxBatchSize: 1000,
   maxBatchWaitMs: 5000,
   logLevel: 'info',
@@ -179,13 +175,10 @@ new CloudExporter({
 
 After you enable `CloudExporter`, open your project in [Mastra Studio](https://projects.mastra.ai) to inspect the exported data.
 
-- Open your project and select **Open Studio**.
+- Open the project you set `MASTRA_PROJECT_ID` to and select **Open Studio**.
 - In Studio, go to **Traces** to inspect agent and workflow traces.
 - Open the filter menu and use **Deployments → Service Name** to isolate traces from a specific app or deployment.
 - Use the **Logs** page in the project dashboard to inspect exported logs.
-- Use the project named by `MASTRA_PROJECT_ID` when you work with organization-scoped tokens.
-
-> **Note:** If you use a project-scoped token, open the project that issued the token. If you use an organization-scoped token, open the project named by `MASTRA_PROJECT_ID`.
 
 When you deploy with Mastra Studio, set **Deployment → Service Name** to a stable value and keep it aligned with the `serviceName` in your observability config. This makes traces easier to filter in Studio through **Deployments → Service Name** when multiple services or deployments send data to the same project.
 

package/.docs/docs/observability/tracing/exporters/langfuse.md

@@ -122,6 +122,35 @@ new LangfuseExporter({
 })
 ```
 
+#### Batch Tuning for High-Volume Traces
+
+For self-hosted Langfuse deployments or streamed runs that produce many spans per second, you can tune the OTEL batch size and flush interval to reduce request pressure on the Langfuse ingestion endpoint:
+
+```typescript
+new LangfuseExporter({
+  publicKey: process.env.LANGFUSE_PUBLIC_KEY!,
+  secretKey: process.env.LANGFUSE_SECRET_KEY!,
+  flushAt: 500, // Maximum spans per OTEL export batch
+  flushInterval: 20, // Maximum seconds between flushes
+})
+```
+
+To suppress high-volume span types entirely (for example `MODEL_CHUNK` spans from streamed responses), use the observability-level [`excludeSpanTypes` option](https://mastra.ai/reference/observability/tracing/span-filtering) rather than configuring the exporter:
+
+```typescript
+import { SpanType } from '@mastra/core/observability'
+
+new Observability({
+  configs: {
+    langfuse: {
+      serviceName: 'my-service',
+      exporters: [new LangfuseExporter()],
+      excludeSpanTypes: [SpanType.MODEL_CHUNK],
+    },
+  },
+})
+```
+
 ### Complete Configuration
 
 ```typescript
@@ -133,6 +162,8 @@ new LangfuseExporter({
   // Optional settings
   baseUrl: process.env.LANGFUSE_BASE_URL, // Default: https://cloud.langfuse.com
   realtime: process.env.NODE_ENV === 'development', // Dynamic mode selection
+  flushAt: 500, // Maximum spans per OTEL export batch
+  flushInterval: 20, // Maximum seconds between flushes
   logLevel: 'info', // Diagnostic logging: debug | info | warn | error
 
   // Langfuse-specific settings

package/.docs/guides/build-your-ui/ai-sdk-ui.md

@@ -242,7 +242,7 @@ Use [`prepareSendMessagesRequest`](https://ai-sdk.dev/docs/reference/ai-sdk-ui/u
 
 When your agent has [memory](https://mastra.ai/docs/memory/overview) configured, Mastra loads conversation history from storage on the server. Send only the new message from the client instead of the full conversation history.
 
-Sending the full history is redundant and can cause message ordering bugs because client-side timestamps can conflict with the timestamps stored in your database.
+Sending the full history is redundant and can cause message-ordering bugs because client-side timestamps can conflict with the timestamps stored in your database.
 
 ```typescript
 import { useChat } from '@ai-sdk/react'
@@ -392,7 +392,8 @@ Mastra streams data to the frontend as "parts" within messages. Each part has a
 | Data Part Type       | Source                  | Description                                                                        |
 | -------------------- | ----------------------- | ---------------------------------------------------------------------------------- |
 | `tool-{toolKey}`     | AI SDK built-in         | Tool invocation with states: `input-available`, `output-available`, `output-error` |
-| `data-workflow`      | `workflowRoute()`       | Workflow execution with step inputs, outputs, and status                           |
+| `data-workflow`      | `workflowRoute()`       | Workflow execution state snapshots with step status and final outputs              |
+| `data-workflow-step` | `workflowRoute()`       | Workflow step delta with the full payload for the step that just changed           |
 | `data-network`       | `networkRoute()`        | Agent network execution with ordered steps and outputs                             |
 | `data-tool-agent`    | Nested agent in tool    | Agent output streamed from within a tool's `execute()`                             |
 | `data-tool-workflow` | Nested workflow in tool | Workflow output streamed from within a tool's `execute()`                          |
@@ -505,11 +506,11 @@ export function Chat() {
 
 ### Rendering workflow data
 
-When using `workflowRoute()` or `handleWorkflowStream()`, Mastra emits `data-workflow` parts that contain the workflow's execution state, including step statuses and outputs.
+When using `workflowRoute()` or `handleWorkflowStream()`, Mastra emits `data-workflow` parts for workflow state snapshots and `data-workflow-step` parts for the full payload of the step that just changed. This keeps long-running workflows from repeating every completed step output in every intermediate snapshot.
 
 **Backend**:
 
-Define a workflow with multiple steps that will emit `data-workflow` parts as it executes.
+Define a workflow with multiple steps that will emit `data-workflow` and `data-workflow-step` parts as it executes.
 
 ```typescript
 import { createStep, createWorkflow } from '@mastra/core/workflows'
@@ -584,14 +585,15 @@ export const mastra = new Mastra({
 
 **Frontend**:
 
-Check for `data-workflow` parts and render each step's status and output using the `WorkflowDataPart` type for type safety.
+Check for `data-workflow` parts to render workflow status snapshots. If you need the full payload for the step that just changed, also read `data-workflow-step` parts.
 
 ```typescript
 import { useChat } from '@ai-sdk/react'
 import { DefaultChatTransport } from 'ai'
-import type { WorkflowDataPart } from '@mastra/ai-sdk'
+import type { WorkflowDataPart, WorkflowStepDataPart } from '@mastra/ai-sdk'
 
 type WorkflowData = WorkflowDataPart['data']
+type WorkflowStepData = WorkflowStepDataPart['data']
 type StepStatus = 'running' | 'success' | 'failed' | 'suspended' | 'waiting'
 
 function StepIndicator({
@@ -652,6 +654,17 @@ export function WorkflowChat() {
                 </div>
               )
             }
+            if (part.type === 'data-workflow-step') {
+              const stepData = part.data as WorkflowStepData
+              return (
+                <StepIndicator
+                  key={index}
+                  name={stepData.step.name}
+                  status={stepData.step.status}
+                  output={stepData.step.output}
+                />
+              )
+            }
             return null
           })}
         </div>

package/.docs/guides/deployment/netlify.md

@@ -1,6 +1,6 @@
 # Deploy Mastra to Netlify
 
-Use `@mastra/deployer-netlify` to deploy your Mastra server as serverless functions on Netlify. The deployer bundles your code and generates a `.netlify` directory conforming to Netlify's [frameworks API](https://docs.netlify.com/build/frameworks/frameworks-api/#netlifyv1functions), ready to deploy.
+Use `@mastra/deployer-netlify` to deploy your Mastra server on Netlify. The deployer bundles your code and generates a `.netlify` directory conforming to Netlify's [Frameworks API](https://docs.netlify.com/build/frameworks/frameworks-api/), ready to deploy. You can deploy as serverless functions (default) or as [edge functions](https://docs.netlify.com/build/edge-functions/overview/) for lower latency and longer execution times.
 
 > **Info:** This guide covers deploying the [Mastra server](https://mastra.ai/docs/server/mastra-server). If you're using a [server adapter](https://mastra.ai/docs/server/server-adapters) or [web framework](https://mastra.ai/docs/deployment/web-framework), deploy the way you normally would for that framework.
 
@@ -49,6 +49,21 @@ export const mastra = new Mastra({
 })
 ```
 
+To deploy as edge functions instead, pass `{ target: 'edge' }`:
+
+```typescript
+import { Mastra } from '@mastra/core'
+import { NetlifyDeployer } from '@mastra/deployer-netlify'
+
+export const mastra = new Mastra({
+  deployer: new NetlifyDeployer({
+    target: 'edge',
+  }),
+})
+```
+
+Edge functions run on Deno at the edge closest to your users. They have no hard execution timeout (only a CPU time limit), making them a better fit for longer-running AI workflows. See the [constructor options](https://mastra.ai/reference/deployer/netlify) for details.
+
 Create a `netlify.toml` file with the following contents in your project root:
 
 ```toml

package/.docs/guides/migrations/mastra-cloud.md

@@ -56,11 +56,136 @@ The Mastra platform replaces Mastra Cloud with separate Studio and Server produc
 
 ## Replace Mastra Cloud Store with a hosted database
 
-Mastra Cloud provided a managed LibSQL database. The Mastra platform does not host a database for you, so you need to point your storage at an externally hosted instance.
+Mastra Cloud provided a managed libSQL database, backed by [Turso](https://turso.tech). The Mastra platform does not host a database for you, so you need to point your storage at an externally hosted instance.
 
-If you were already using a hosted database ("bring your own"), no changes are needed. Make sure the connection string is set as an environment variable in the dashboard rather than hardcoded.
+If you were already using a hosted database ("bring your own"), no changes are needed. Ensure the connection string is set as an environment variable in the dashboard rather than hardcoded.
 
-If you were using `file:./mastra.db` with Cloud Store, please [contact support](mailto:support@mastra.ai) for a migration path to export and import your data.
+If you were using Cloud Store, follow the steps below to export your data and load it into a new libSQL database that you control.
+
+### Export your Cloud Store data
+
+There are two ways to export your Cloud Store data: a one-click download from the dashboard, or a manual dump via the Turso CLI.
+
+#### Option A — Export from the dashboard (recommended)
+
+Open your project in the [Mastra dashboard](https://projects.mastra.ai) and navigate to **Runtime → Settings → Storage**. Click the **Export Database** button. The dashboard generates a full `.sql` dump of your Cloud Store and downloads it directly to your Downloads folder.
+
+Once the download completes, convert the dump into a SQLite database file:
+
+```bash
+sqlite3 mydb.db < ~/Downloads/mastra-cloud-dump.sql
+```
+
+You now have a portable `mydb.db` file you can inspect locally, back up, or use as the source for the new database in the steps that follow.
+
+#### Option B — Export via the Turso CLI
+
+If you prefer to work from the command line, or need to script the export, you can dump the database directly using the [Turso CLI](https://docs.turso.tech/cli). This approach requires the database URL and an auth token, both surfaced in the dashboard.
+
+1. Retrieve your Cloud Store credentials from the dashboard.
+
+   Open your project in the [Mastra dashboard](https://projects.mastra.ai) and navigate to **Runtime → Settings → Env Variables**. For Cloud Store–backed projects, two variables are injected alongside your own:
+
+   - `MASTRA_STORAGE_URL`: A libSQL connection string (e.g. `libsql://<db-name>-<org>.turso.io`).
+   - `MASTRA_STORAGE_AUTH_TOKEN`: A read-capable auth token scoped to that database.
+
+   Each row supports the standard environment variable actions — show/hide via the eye toggle, Edit, Delete, and Copy Value. Use **Copy Value** to grab both values for the dump command below.
+
+   > **Note:** These variables only appear for projects that were provisioned with Cloud Store. If you brought your own database to Mastra Cloud, you already have these credentials and can skip ahead to [Point your Mastra app at the new database](#point-your-mastra-app-at-the-new-database).
+
+   > **Info:** If the variables are missing, the values do not decrypt, or the Turso CLI rejects the token, email <support@mastra.ai> from the address associated with your Mastra Cloud account and ask for the libSQL URL and auth token for the project you want to export. Include the project name/ID. Support can also run the dump on your behalf if CLI access is blocked on your network.
+
+2. Install the Turso CLI.
+
+   ```bash
+   brew install tursodatabase/tap/turso
+   ```
+
+   ```bash
+   curl -sSfL https://get.tur.so/install.sh | bash
+   ```
+
+   See the [Turso CLI introduction](https://docs.turso.tech/cli/introduction) for Windows and headless-install options.
+
+3. Export the database to a SQL dump.
+
+   Set the credentials provided by support (or use the dashboard values if you already copied them earlier) as environment variables, then dump the database to a local file:
+
+   ```bash
+   export MASTRA_STORAGE_URL="libsql://<db-name>-<org>.turso.io"
+   export MASTRA_STORAGE_AUTH_TOKEN="<token-from-dashboard-or-support>"
+
+   turso db shell "$MASTRA_STORAGE_URL?authToken=$MASTRA_STORAGE_AUTH_TOKEN" ".dump" > mastra-cloud-dump.sql
+   ```
+
+   > **Warning:** Embedding the auth token in the connection string is less secure than Turso's recommended pattern — the full URL (with token) can end up in shell history, process listings, and terminal logs. Turso officially recommends running `turso auth login` and then dumping by database name only: `turso db shell <database-name> ".dump" > mastra-cloud-dump.sql`. That flow requires the database to live in a Turso account you own, which is not the case for Cloud Store, so the env-var example above is provided as an alternative for this one-time export. If you prefer to avoid token interpolation entirely, ask support to run the dump on your behalf and send you the resulting SQL file.
+
+   The resulting `mastra-cloud-dump.sql` contains the full schema and data: thread and message history, workflow snapshots, traces, and eval scores. Store it somewhere safe before continuing.
+
+### Load the dump into a new libSQL database
+
+The dump is a standard SQL file and can be loaded into any libSQL-compatible database. The example below uses a new Turso-hosted database, which keeps the migration like-for-like and avoids schema translation.
+
+1. Authenticate the Turso CLI against your own Turso account.
+
+   ```bash
+   turso auth login
+   ```
+
+   If you do not have a Turso account, the CLI will prompt you to create one. See [Turso pricing](https://turso.tech/pricing) for plan details.
+
+2. Create a new database and load the dump in one step.
+
+   ```bash
+   turso db create mastra-migrated --from-dump ./mastra-cloud-dump.sql
+   ```
+
+   `--from-dump` restores a local SQLite/libSQL dump at create time, which is faster and safer than piping statements through `turso db shell` after the fact. Pick a region close to where your Mastra Server runs to minimize latency — list available regions with `turso db locations` and pass `--group <group-name>` if you manage multiple groups.
+
+   For multi-gigabyte dumps, add `--wait` so the CLI blocks until the database is fully available.
+
+3. Generate connection credentials for the new database.
+
+   ```bash
+   turso db show mastra-migrated --url
+   turso db tokens create mastra-migrated
+   ```
+
+   The first command prints the libSQL URL. The second prints an auth token. Both are needed by `LibSQLStore`.
+
+### Point your Mastra app at the new database
+
+Set the new credentials as environment variables, either locally in `.env` or in the Mastra platform dashboard:
+
+```bash
+TURSO_DATABASE_URL="libsql://mastra-migrated-<org>.turso.io"
+TURSO_AUTH_TOKEN="<token-from-turso-db-tokens-create>"
+```
+
+Configure `LibSQLStore` to read from those variables:
+
+```ts
+import { Mastra } from '@mastra/core/mastra'
+import { LibSQLStore } from '@mastra/libsql'
+
+export const mastra = new Mastra({
+  storage: new LibSQLStore({
+    id: 'libsql-storage',
+    url: process.env.TURSO_DATABASE_URL!,
+    authToken: process.env.TURSO_AUTH_TOKEN,
+  }),
+})
+```
+
+See the [libSQL storage reference](https://mastra.ai/reference/storage/libsql) for the full set of options.
+
+### Verify the migration
+
+Before decommissioning your Cloud project, confirm the new database serves the data your app expects.
+
+- Run `turso db shell mastra-migrated "SELECT name FROM sqlite_master WHERE type='table';"` to list tables. The output should include the Mastra-managed tables (e.g. `mastra_threads`, `mastra_messages`, `mastra_workflow_snapshot`, `mastra_traces`).
+- Run a row count against a known-populated table, for example `turso db shell mastra-migrated "SELECT COUNT(*) FROM mastra_messages;"`, and compare it to the same query against the Cloud Store URL.
+- Start your Mastra app against the new credentials and confirm that an existing thread or workflow run loads as expected in [Studio](https://mastra.ai/docs/studio/observability).
 
 ## Update observability configuration
 

package/.docs/models/gateways/netlify.md

@@ -1,6 +1,6 @@
 # Netlify
 
-Netlify AI Gateway provides unified access to multiple providers with built-in caching and observability. Access 62 models through Mastra's model router.
+Netlify AI Gateway provides unified access to multiple providers with built-in caching and observability. Access 63 models through Mastra's model router.
 
 Learn more in the [Netlify documentation](https://docs.netlify.com/build/ai-gateway/overview/).
 
@@ -43,6 +43,7 @@ ANTHROPIC_API_KEY=ant-...
 | `anthropic/claude-opus-4-5`                 |
 | `anthropic/claude-opus-4-5-20251101`        |
 | `anthropic/claude-opus-4-6`                 |
+| `anthropic/claude-opus-4-7`                 |
 | `anthropic/claude-sonnet-4-0`               |
 | `anthropic/claude-sonnet-4-20250514`        |
 | `anthropic/claude-sonnet-4-5`               |

package/.docs/models/gateways/openrouter.md

@@ -1,6 +1,6 @@
 # ![OpenRouter logo](https://models.dev/logos/openrouter.svg)OpenRouter
 
-OpenRouter aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 170 models through Mastra's model router.
+OpenRouter aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 171 models through Mastra's model router.
 
 Learn more in the [OpenRouter documentation](https://openrouter.ai/models).
 
@@ -41,6 +41,7 @@ ANTHROPIC_API_KEY=ant-...
 | `anthropic/claude-opus-4.1`                                     |
 | `anthropic/claude-opus-4.5`                                     |
 | `anthropic/claude-opus-4.6`                                     |
+| `anthropic/claude-opus-4.7`                                     |
 | `anthropic/claude-sonnet-4`                                     |
 | `anthropic/claude-sonnet-4.5`                                   |
 | `anthropic/claude-sonnet-4.6`                                   |

package/.docs/models/gateways/vercel.md

@@ -1,6 +1,6 @@
 # ![Vercel logo](https://models.dev/logos/vercel.svg)Vercel
 
-Vercel aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 231 models through Mastra's model router.
+Vercel aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 234 models through Mastra's model router.
 
 Learn more in the [Vercel documentation](https://ai-sdk.dev/providers/ai-sdk-providers).
 
@@ -72,6 +72,7 @@ ANTHROPIC_API_KEY=ant-...
 | `anthropic/claude-opus-4.1`                    |
 | `anthropic/claude-opus-4.5`                    |
 | `anthropic/claude-opus-4.6`                    |
+| `anthropic/claude-opus-4.7`                    |
 | `anthropic/claude-sonnet-4`                    |
 | `anthropic/claude-sonnet-4.5`                  |
 | `anthropic/claude-sonnet-4.6`                  |
@@ -119,6 +120,7 @@ ANTHROPIC_API_KEY=ant-...
 | `google/text-embedding-005`                    |
 | `google/text-multilingual-embedding-002`       |
 | `inception/mercury-2`                          |
+| `inception/mercury-coder-small`                |
 | `inception/mercury-edit-2`                     |
 | `kwaipilot/kat-coder-pro-v1`                   |
 | `kwaipilot/kat-coder-pro-v2`                   |
@@ -264,4 +266,5 @@ ANTHROPIC_API_KEY=ant-...
 | `zai/glm-4.7-flashx`                           |
 | `zai/glm-5`                                    |
 | `zai/glm-5-turbo`                              |
+| `zai/glm-5.1`                                  |
 | `zai/glm-5v-turbo`                             |

package/.docs/models/index.md

@@ -1,6 +1,6 @@
 # Model Providers
 
-Mastra provides a unified interface for working with LLMs across multiple providers, giving you access to 3596 models from 99 providers through a single API.
+Mastra provides a unified interface for working with LLMs across multiple providers, giving you access to 3651 models from 101 providers through a single API.
 
 ## Features
 
@@ -228,6 +228,41 @@ Mastra tries your primary model first. If it encounters a 500 error, rate limit,
 
 Your users never experience the disruption - the response comes back with the same format, just from a different model. The error context is preserved as the system moves through your fallback chain, ensuring clean error propagation while maintaining streaming compatibility.
 
+### Per-model settings
+
+Each fallback entry can carry its own `modelSettings`, `providerOptions`, and `headers` — useful when models in the chain need different temperatures or provider-specific knobs to produce comparable output.
+
+```typescript
+import { Agent } from '@mastra/core/agent';
+
+const agent = new Agent({
+  id: 'tuned-resilient',
+  name: 'Tuned Resilient Agent',
+  instructions: 'You are a helpful assistant.',
+  model: [
+    {
+      model: 'google/gemini-2.5-flash',
+      maxRetries: 2,
+      modelSettings: { temperature: 0.3 },
+      providerOptions: { google: { thinkingConfig: { thinkingBudget: 0 } } },
+    },
+    {
+      model: 'openai/gpt-5-mini',
+      maxRetries: 2,
+      modelSettings: { temperature: 0.7 },
+      providerOptions: { openai: { reasoningEffort: 'low' } },
+    },
+  ],
+});
+```
+
+**Precedence:**
+
+- `modelSettings` and `providerOptions`: per-fallback entry overrides call-time options, which override agent `defaultOptions`. `modelSettings` shallow-merges by key. `providerOptions` deep-merges recursively, so nested provider config (e.g. `google.thinkingConfig`) preserves sibling keys across layers.
+- `headers`: call-time `modelSettings.headers` overrides per-fallback `headers`, which overrides headers extracted from model-router models. Runtime headers (tracing, auth, tenancy) intentionally take precedence over model-level headers.
+
+Each field also accepts a function of `requestContext`, matching how dynamic models are resolved.
+
 ## Use local models with Mastra
 
 Mastra also supports local models like `gpt-oss`, `Qwen3`, `DeepSeek` and many more that you run on your own hardware. The application running your local model needs to provide an OpenAI-compatible API server for Mastra to connect to. We recommend using [LMStudio](https://lmstudio.ai/) (see [Running the LMStudio server](https://lmstudio.ai/docs/developer/core/server)).

package/.docs/models/providers/alibaba-cn.md

@@ -1,6 +1,6 @@
 # ![Alibaba (China) logo](https://models.dev/logos/alibaba-cn.svg)Alibaba (China)
 
-Access 75 Alibaba (China) models through Mastra's model router. Authentication is handled automatically using the `DASHSCOPE_API_KEY` environment variable.
+Access 76 Alibaba (China) models through Mastra's model router. Authentication is handled automatically using the `DASHSCOPE_API_KEY` environment variable.
 
 Learn more in the [Alibaba (China) documentation](https://www.alibabacloud.com/help/en/model-studio/models).
 
@@ -46,6 +46,7 @@ for await (const chunk of stream) {
 | `alibaba-cn/deepseek-v3-1`                      | 131K    |       |           |       |       |       | $0.57      | $2          |
 | `alibaba-cn/deepseek-v3-2-exp`                  | 131K    |       |           |       |       |       | $0.29      | $0.43       |
 | `alibaba-cn/glm-5`                              | 203K    |       |           |       |       |       | $0.86      | $3          |
+| `alibaba-cn/glm-5.1`                            | 203K    |       |           |       |       |       | $0.87      | $3          |
 | `alibaba-cn/kimi-k2-thinking`                   | 262K    |       |           |       |       |       | $0.57      | $2          |
 | `alibaba-cn/kimi-k2.5`                          | 262K    |       |           |       |       |       | $0.57      | $2          |
 | `alibaba-cn/kimi/kimi-k2.5`                     | 262K    |       |           |       |       |       | $0.60      | $3          |

package/.docs/models/providers/anthropic.md

@@ -1,6 +1,6 @@
 # ![Anthropic logo](https://models.dev/logos/anthropic.svg)Anthropic
 
-Access 22 Anthropic models through Mastra's model router. Authentication is handled automatically using the `ANTHROPIC_API_KEY` environment variable.
+Access 23 Anthropic models through Mastra's model router. Authentication is handled automatically using the `ANTHROPIC_API_KEY` environment variable.
 
 Learn more in the [Anthropic documentation](https://docs.anthropic.com/en/docs/about-claude/models).
 
@@ -49,6 +49,7 @@ for await (const chunk of stream) {
 | `anthropic/claude-opus-4-5`            | 200K    |       |           |       |       |       | $5         | $25         |
 | `anthropic/claude-opus-4-5-20251101`   | 200K    |       |           |       |       |       | $5         | $25         |
 | `anthropic/claude-opus-4-6`            | 1.0M    |       |           |       |       |       | $5         | $25         |
+| `anthropic/claude-opus-4-7`            | 1.0M    |       |           |       |       |       | $5         | $25         |
 | `anthropic/claude-sonnet-4-0`          | 200K    |       |           |       |       |       | $3         | $15         |
 | `anthropic/claude-sonnet-4-20250514`   | 200K    |       |           |       |       |       | $3         | $15         |
 | `anthropic/claude-sonnet-4-5`          | 200K    |       |           |       |       |       | $3         | $15         |