@mastra/mcp-docs-server 1.2.1 → 1.2.2-alpha.10

package/.docs/docs/agents/background-tasks.md

@@ -49,7 +49,7 @@ Once a tool has opted in, the LLM can optionally include a `_background` field i
 
 ### Tool-level
 
-Set `backgroundTasks.enabled: true` on the tool definition. Tools opted in at this layer run in the background whenever called by an agent that has the manager enabled.
+Set `background.enabled: true` on the tool definition. Tools opted in at this layer run in the background whenever called by an agent that has the manager enabled.
 
 ```typescript
 import { createTool } from '@mastra/core/tools'
@@ -59,7 +59,7 @@ export const researchTool = createTool({
   id: 'research',
   description: 'Run a long research job',
   inputSchema: z.object({ topic: z.string() }),
-  backgroundTasks: {
+  background: {
     enabled: true,
     timeoutMs: 600_000,
     maxRetries: 1,
@@ -111,7 +111,7 @@ The `_background` override is a _modifier_ on tools the developer has already op
 When a tool call is dispatched, the resolved background config is computed in this priority order:
 
 1. Agent-level `backgroundTasks.tools` entry for the tool.
-2. Tool-level `backgroundTasks` config.
+2. Tool-level `background` config.
 3. LLM `_background.enabled` override (only used to enable background dispatch when the tool was opted in at one of the layers above).
 4. Manager defaults (`defaultTimeoutMs`, `defaultRetries`).
 
@@ -200,7 +200,7 @@ const stream = await supervisor.stream('Research AI in education and write an ar
 
 ### Inheriting from the subagent
 
-If a subagent isn't listed under the supervisor's `backgroundTasks.tools` but has background-eligible tools of its own (either via tool-level `backgroundTasks.enabled: true` or its own `backgroundTasks.tools` entry) the framework still dispatches the entire subagent invocation as a background task. The supervisor inherits the subagent's intent: the subagent itself becomes the background task, and its inner tools run in the foreground inside the subagent's loop.
+If a subagent isn't listed under the supervisor's `backgroundTasks.tools` but has background-eligible tools of its own (either via tool-level `background.enabled: true` or its own `backgroundTasks.tools` entry) the framework still dispatches the entire subagent invocation as a background task. The supervisor inherits the subagent's intent: the subagent itself becomes the background task, and its inner tools run in the foreground inside the subagent's loop.
 
 The background config used for the inherited dispatch (for example `waitTimeoutMs`) is derived from the subagent's own `backgroundTasks` config.
 
@@ -285,7 +285,7 @@ The manager keeps tool executors in process memory. If the process restarts whil
 
 Each layer can register terminal-state callbacks. They don't replace one another, and success/failure hooks fire for their respective outcomes:
 
-- Tool-level `backgroundTasks.onComplete` / `onFailed`: scoped to one tool.
+- Tool-level `background.onComplete` / `onFailed`: scoped to one tool.
 - Agent-level `backgroundTasks.onTaskComplete` / `onTaskFailed`: scoped to all tasks dispatched by this agent.
 - Manager-level `onTaskComplete` / `onTaskFailed`: scoped globally.
 

package/.docs/docs/agents/code-mode.md

@@ -2,7 +2,7 @@
 
 **Added in:** `@mastra/core@1.38.0`
 
-> **Alpha:** This feature is in alpha. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
 Code mode lets an agent run multi-tool computations in an isolated sandbox and return the result as a single, more accurate response. Instead of calling tools one turn at a time, the model writes a tailored function for the user query that orchestrates your existing tools as `external_*` functions, reduces or aggregates their results, and returns one structured answer.
 

package/.docs/docs/agents/goals.md

@@ -2,7 +2,7 @@
 
 **Added in:** `@mastra/core@1.42.0`
 
-> **Alpha:** The Goals feature is in alpha stage and subject to breaking changes in minor versions until it graduates from its alpha status.
+> **Beta:** The Goals feature is in beta stage and subject to breaking changes in minor versions until it graduates from its beta status.
 
 A goal is a durable, thread-scoped objective: a standing instruction the agent keeps working toward across loop iterations until a judge model decides it is satisfied or a run budget is exhausted. The objective is persisted in thread state, so it survives reloads and is evaluated in-loop — even when a new message arrives in the middle of an already-running turn.
 

package/.docs/docs/agents/processors.md

@@ -427,7 +427,7 @@ See the [`ProviderHistoryCompat` reference](https://mastra.ai/reference/processo
 
 ## Response caching
 
-> **Alpha:** This feature is in alpha. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
 Response caching skips the LLM call and replays a previously cached response when an agent receives an identical request. Use it to reduce latency and avoid paying for repeated calls.
 

package/.docs/docs/agents/signal-providers.md

@@ -2,7 +2,7 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
-> **Alpha:** This feature is in alpha. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
 A signal provider monitors an external source, such as GitHub, Slack, continuous integration (CI), or your own API, and pushes [notification signals](https://mastra.ai/docs/agents/signals) into subscribed agent threads.
 

package/.docs/docs/agents/signals.md

@@ -2,7 +2,7 @@
 
 **Added in:** `@mastra/core@1.39.0`
 
-> **Alpha:** This feature is in alpha. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** This feature is in beta. Breaking changes may occur without a major version bump until the API is stable.
 
 Signals are a way to interact with an agent through a thread. Instead of starting every interaction with `agent.stream()`, subscribe to a thread and send messages or signals. Mastra either wakes the agent when the thread is idle, drops input into the running agent loop, or queues input for the next turn.
 

package/.docs/docs/agents/supervisor-agents.md

@@ -261,6 +261,21 @@ for await (const chunk of stream.fullStream) {
 }
 ```
 
+## Cancellation
+
+When you pass an `abortSignal` to the supervisor's [`stream()`](https://mastra.ai/reference/streaming/agents/stream) or [`generate()`](https://mastra.ai/reference/agents/generate) call, Mastra forwards that same signal to delegated subagents. Calling `AbortController.abort()` cancels in-flight subagent runs at their next step instead of letting them run to completion.
+
+```typescript
+const controller = new AbortController()
+
+const stream = await supervisor.stream('Research AI trends', {
+  abortSignal: controller.signal,
+})
+
+// Cancel the supervisor and any in-flight subagents
+controller.abort()
+```
+
 ## Task completion scoring
 
 Agents don't always produce a complete, correct output on the first try. Task completion scorers can help with that by validating whether the task is complete after each iteration. If validation fails, the supervisor continues iterating. Feedback from failed scorers is included in the conversation context so subagents can see what was missing.

package/.docs/docs/evals/built-in-scorers.md

@@ -45,4 +45,20 @@ These scorers evaluate adherence to format, style, and safety requirements:
 - [`tone-consistency`](https://mastra.ai/reference/evals/tone-consistency): Measures consistency in formality, complexity, and style (`0-1`, higher is better)
 - [`toxicity`](https://mastra.ai/reference/evals/toxicity): Detects harmful or inappropriate content (`0-1`, lower is better)
 - [`bias`](https://mastra.ai/reference/evals/bias): Detects potential biases in the output (`0-1`, lower is better)
-- [`keyword-coverage`](https://mastra.ai/reference/evals/keyword-coverage): Assesses technical terminology usage (`0-1`, higher is better)
+- [`keyword-coverage`](https://mastra.ai/reference/evals/keyword-coverage): Assesses technical terminology usage (`0-1`, higher is better)
+
+### Quick Checks
+
+Zero-LLM micro-scorers for fast, deterministic assertions. See the [Quick Checks](https://mastra.ai/docs/evals/quick-checks) guide for usage details.
+
+- [`checks.includes`](https://mastra.ai/reference/evals/checks): Scores 1 if output contains a substring (`0` or `1`)
+- [`checks.excludes`](https://mastra.ai/reference/evals/checks): Scores 1 if output does not contain a substring (`0` or `1`)
+- [`checks.equals`](https://mastra.ai/reference/evals/checks): Scores 1 if output exactly matches a string (`0` or `1`)
+- [`checks.matches`](https://mastra.ai/reference/evals/checks): Scores 1 if output matches a regex (`0` or `1`)
+- [`checks.similarity`](https://mastra.ai/reference/evals/checks): String similarity via Dice coefficient (`0-1`, or binary with threshold)
+- [`checks.calledTool`](https://mastra.ai/reference/evals/checks): Scores 1 if a tool was called at least N times (`0` or `1`)
+- [`checks.didNotCall`](https://mastra.ai/reference/evals/checks): Scores 1 if a tool was not called (`0` or `1`)
+- [`checks.toolOrder`](https://mastra.ai/reference/evals/checks): Scores 1 if tools were called in order (`0` or `1`)
+- [`checks.maxToolCalls`](https://mastra.ai/reference/evals/checks): Scores 1 if tool call count is within limit (`0` or `1`)
+- [`checks.usedNoTools`](https://mastra.ai/reference/evals/checks): Scores 1 if no tools were called (`0` or `1`)
+- [`checks.noToolErrors`](https://mastra.ai/reference/evals/checks): Scores 1 if no tool calls had errors (`0` or `1`)

package/.docs/docs/evals/gates-and-verdicts.md

@@ -0,0 +1,140 @@
+# Gates and verdicts
+
+Gates and verdicts add severity semantics to `runEvals`. Gates are scorers that must score 1.0 — hard requirements that block a run. Thresholds are minimum acceptable scores on tracked metrics. The verdict summarizes the outcome as `passed`, `scored`, or `failed`.
+
+## When to use gates and verdicts
+
+- Enforce hard requirements in CI (e.g., "agent must call the right tool")
+- Track quality metrics with minimum thresholds (e.g., "faithfulness above 0.7")
+- Get a single verdict signal (`passed`, `scored`, or `failed`) from an eval run without writing custom assertion logic
+- Separate "must pass" gates from "nice to have" tracked metrics
+
+## Quickstart
+
+```typescript
+import { runEvals } from '@mastra/core/evals'
+import { checks } from '@mastra/evals/checks'
+import { weatherAgent } from '../agents'
+import { faithfulnessScorer } from '../scorers'
+
+const result = await runEvals({
+  data: [{ input: 'What is the weather in Brooklyn?' }],
+  target: weatherAgent,
+
+  // Gates: must all score 1.0 or the run fails
+  gates: [checks.calledTool('get_weather'), checks.noToolErrors()],
+
+  // Scorers: tracked with optional thresholds
+  scorers: [
+    { scorer: faithfulnessScorer, threshold: 0.7 },
+    checks.includes('Brooklyn'), // no threshold = tracked only
+  ],
+})
+
+console.log(result.verdict) // 'passed' | 'scored' | 'failed'
+```
+
+## How verdicts work
+
+The verdict is computed from gates and thresholds after all data items are processed:
+
+- `failed`: At least one gate averaged below 1.0 across data items
+- `scored`: All gates passed, but at least one threshold scorer missed its threshold
+- `passed`: All gates scored 1.0 and all thresholds were met
+
+When no gates or threshold-bearing scorers are provided, the verdict field is omitted and `runEvals` behaves exactly as before.
+
+## Gates
+
+Gates are scorers passed via the `gates` field. They run before regular scorers on each data item. A gate must average a score of 1.0 across all data items to pass.
+
+```typescript
+import { runEvals } from '@mastra/core/evals'
+import { checks } from '@mastra/evals/checks'
+
+const result = await runEvals({
+  data: [{ input: 'What is the weather?' }],
+  target: weatherAgent,
+  gates: [checks.calledTool('get_weather')],
+  scorers: [qualityScorer],
+})
+
+// result.gateResults: [{ id: 'check-called-tool', passed: true, score: 1 }]
+```
+
+Any scorer works as a gate. Quick Checks are a natural fit because they return binary 1/0 scores.
+
+> **Note:** Visit [runEvals() reference](https://mastra.ai/reference/evals/run-evals) for the full parameter and return type documentation.
+
+## Thresholds
+
+Wrap a scorer in `{ scorer, threshold }` to set pass/fail bounds. The threshold is compared against the scorer's average score across all data items.
+
+A `threshold` can be:
+
+- **A number** — implies minimum (score at or above passes): `{ scorer, threshold: 0.7 }`
+- **An object with `min` and/or `max`** — for range-based checks: `{ scorer, threshold: { max: 0.3 } }`
+
+Use `max` for scorers where a high score is bad (e.g., hallucination, toxicity). Use `{ min, max }` when the score should fall within a specific band.
+
+```typescript
+import { runEvals } from '@mastra/core/evals'
+
+const result = await runEvals({
+  data: [{ input: 'Explain quantum computing' }],
+  target: myAgent,
+  scorers: [
+    { scorer: faithfulnessScorer, threshold: 0.7 }, // min threshold (number shorthand)
+    { scorer: hallucinationScorer, threshold: { max: 0.3 } }, // max threshold — high score = bad
+    { scorer: verbosityScorer, threshold: { min: 0.3, max: 0.8 } }, // range threshold
+    toneScorer, // bare scorer, no threshold — tracked only
+  ],
+})
+
+// result.thresholdResults:
+// [
+//   { id: 'faithfulness', passed: true, averageScore: 0.85, threshold: 0.7 },
+//   { id: 'hallucination', passed: true, averageScore: 0.1, threshold: { max: 0.3 } },
+//   { id: 'verbosity', passed: false, averageScore: 0.9, threshold: { min: 0.3, max: 0.8 } },
+// ]
+```
+
+A bare scorer (no threshold) still appears in `result.scores` but does not affect the verdict.
+
+## Using verdicts in CI
+
+The verdict gives a single signal for CI pipelines:
+
+```typescript
+import { runEvals } from '@mastra/core/evals'
+import { checks } from '@mastra/evals/checks'
+
+const result = await runEvals({
+  data: testDataset,
+  target: myAgent,
+  gates: [checks.calledTool('search'), checks.noToolErrors()],
+  scorers: [{ scorer: faithfulnessScorer, threshold: 0.7 }],
+})
+
+if (result.verdict === 'failed') {
+  console.error(
+    'Gate failures:',
+    result.gateResults?.filter(g => !g.passed),
+  )
+  process.exit(1)
+}
+
+if (result.verdict === 'scored') {
+  console.warn(
+    'Threshold misses:',
+    result.thresholdResults?.filter(t => !t.passed),
+  )
+}
+```
+
+## Related
+
+- [Quick Checks](https://mastra.ai/docs/evals/quick-checks): Zero-LLM micro-scorers that work well as gates
+- [runEvals() reference](https://mastra.ai/reference/evals/run-evals): Full API documentation
+- [Built-in scorers](https://mastra.ai/docs/evals/built-in-scorers): LLM-based and code-based scorers
+- [Running evals in CI](https://mastra.ai/docs/evals/running-in-ci): CI integration patterns

package/.docs/docs/evals/overview.md

@@ -135,6 +135,8 @@ Once registered, you can score traces interactively within Studio under the **Ob
 
 ## Next steps
 
+- Use [Quick Checks](https://mastra.ai/docs/evals/quick-checks) for fast, deterministic assertions on text and tool usage
+- Add [gates and verdicts](https://mastra.ai/docs/evals/gates-and-verdicts) to enforce hard requirements and quality thresholds
 - Learn how to create your own scorers in the [Creating Custom Scorers](https://mastra.ai/docs/evals/custom-scorers) guide
 - Explore built-in scorers in the [Built-in Scorers](https://mastra.ai/docs/evals/built-in-scorers) section
 - Test scorers with [Studio](https://mastra.ai/docs/studio/overview)

package/.docs/docs/evals/quick-checks.md

@@ -0,0 +1,136 @@
+# Quick Checks
+
+Quick Checks are composable micro-scorers for common assertions like "output contains X" or "agent called tool Y." They require no LLM, run instantly, and plug into the same `scorers: [...]` array as any other scorer.
+
+## When to use Quick Checks
+
+Use Quick Checks when you need fast, deterministic assertions:
+
+- Verify output text contains or excludes specific strings
+- Confirm an agent called (or avoided) specific tools
+- Validate tool call ordering and count limits
+- Gate CI pipelines with zero-cost binary checks
+- Combine with LLM-based scorers for layered evaluation
+
+For subjective or semantic evaluation, use [LLM-based scorers](https://mastra.ai/docs/evals/built-in-scorers) instead.
+
+## Quickstart
+
+```typescript
+import { checks } from '@mastra/evals/checks'
+import { runEvals } from '@mastra/core/evals'
+import { weatherAgent } from '../agents'
+
+const result = await runEvals({
+  data: [{ input: 'What is the weather in Brooklyn?' }],
+  target: weatherAgent,
+  scorers: [checks.includes('Brooklyn'), checks.calledTool('get_weather'), checks.noToolErrors()],
+})
+
+console.log(result.scores)
+// { 'check-includes': 1, 'check-called-tool': 1, 'check-no-tool-errors': 1 }
+```
+
+## Available checks
+
+Quick Checks fall into two categories:
+
+### Text checks
+
+These scorers evaluate the agent's text output:
+
+| Check                    | What it does                          | Score                            |
+| ------------------------ | ------------------------------------- | -------------------------------- |
+| `checks.includes(str)`   | Output contains substring             | 1 or 0                           |
+| `checks.excludes(str)`   | Output does not contain substring     | 1 or 0                           |
+| `checks.equals(str)`     | Output exactly equals string          | 1 or 0                           |
+| `checks.matches(regex)`  | Output matches regular expression     | 1 or 0                           |
+| `checks.similarity(str)` | Dice coefficient similarity to string | 0-1 (or binary with `threshold`) |
+
+### Tool call checks
+
+These scorers evaluate tool usage from the agent's run:
+
+| Check                     | What it does                     | Score  |
+| ------------------------- | -------------------------------- | ------ |
+| `checks.calledTool(name)` | Tool was called at least N times | 1 or 0 |
+| `checks.didNotCall(name)` | Tool was not called              | 1 or 0 |
+| `checks.toolOrder([...])` | Tools called in expected order   | 1 or 0 |
+| `checks.maxToolCalls(n)`  | No more than N tool calls total  | 1 or 0 |
+| `checks.usedNoTools()`    | No tools called at all           | 1 or 0 |
+| `checks.noToolErrors()`   | No tool invocations had errors   | 1 or 0 |
+
+## Combining checks with LLM scorers
+
+Checks compose with LLM-based scorers in a single `runEvals` call. Use checks for deterministic gates and LLM scorers for qualitative evaluation:
+
+```typescript
+import { checks } from '@mastra/evals/checks'
+import { createFaithfulnessScorer } from '@mastra/evals/scorers/prebuilt'
+import { runEvals } from '@mastra/core/evals'
+import { myAgent } from '../agents'
+
+const result = await runEvals({
+  data: [
+    {
+      input: 'What is the weather in Brooklyn?',
+      context: ['Brooklyn weather data: sunny, 72°F'],
+    },
+  ],
+  target: myAgent,
+  scorers: [
+    // Deterministic checks (instant, free)
+    checks.includes('Brooklyn'),
+    checks.calledTool('get_weather'),
+    checks.excludes('error'),
+    checks.noToolErrors(),
+
+    // LLM-based scorer (semantic, costs tokens)
+    createFaithfulnessScorer({ model: 'openai/gpt-5-mini' }),
+  ],
+})
+```
+
+## Using checks in live scoring
+
+Attach checks to agents for continuous monitoring:
+
+```typescript
+import { Agent } from '@mastra/core/agent'
+import { checks } from '@mastra/evals/checks'
+
+export const weatherAgent = new Agent({
+  name: 'Weather Agent',
+  instructions: 'Answer weather questions using the get_weather tool.',
+  model: 'openai/gpt-5.5',
+  tools: { get_weather: weatherTool },
+  scorers: {
+    noErrors: {
+      scorer: checks.noToolErrors(),
+      sampling: { type: 'ratio', rate: 1 },
+    },
+    mentionCity: {
+      scorer: checks.includes('Brooklyn'),
+      sampling: { type: 'ratio', rate: 0.5 },
+    },
+  },
+})
+```
+
+## How checks work
+
+Each check is a standard `createScorer()` instance with a `preprocess` step and a `generateScore` step. They follow the same [four-step pipeline](https://mastra.ai/docs/evals/custom-scorers) as any other scorer:
+
+1. **preprocess**: Extracts and normalizes relevant data from the agent run (text content, tool calls)
+2. **generateScore**: Converts the preprocessed result into a score (typically binary 1 or 0)
+
+Because checks skip the `analyze` and `generateReason` steps and make no LLM calls, they run in microseconds.
+
+> **Note:** Visit the [Quick Checks reference](https://mastra.ai/reference/evals/checks) for the full API, including all parameters and options for each check.
+
+## Related
+
+- [Quick Checks reference](https://mastra.ai/reference/evals/checks)
+- [Built-in Scorers](https://mastra.ai/docs/evals/built-in-scorers)
+- [Custom Scorers](https://mastra.ai/docs/evals/custom-scorers)
+- [`runEvals()` reference](https://mastra.ai/reference/evals/run-evals)

package/.docs/docs/harness/modes.md

@@ -79,6 +79,27 @@ const buildMode = { id: 'build', additionalTools: { deployTool } }
 
 You can't set both `tools` and `additionalTools` on the same mode.
 
+### Restricting tool visibility
+
+`tools` and `additionalTools` control which tools are **added** to a mode's run — they don't hide the backing agent's own tools. To restrict which of those tools the model can actually see and call, set `availableTools`:
+
+```typescript
+const reviewMode = {
+  id: 'review',
+  name: 'Review',
+  // Only these tools are visible to the model in this mode.
+  availableTools: ['view', 'find_files', 'search_content'],
+}
+```
+
+`availableTools` is a per-mode visibility allowlist that matches each tool by its final exposed name:
+
+- **`undefined`** (default): no mode-level restriction — every tool is visible.
+- **`[]`**: no tools are available for this mode.
+- A denied tool stays hidden even if it appears in the list. Per-tool and per-category `deny` rules in your permission config always take precedence.
+
+Workspace tools use the same list as every other tool — reference them by their exposed names (`view`, `write_file`, `find_files`, etc.). Visibility is enforced at LLM-call time, so the model never sees — and can't attempt to call — a tool outside the allowlist.
+
 ### Mode transitions
 
 A mode can declare a `transitionsTo` target. When the `submit_plan` built-in tool runs in that mode, the Harness transitions to the target mode on approval:

package/.docs/docs/harness/overview.md

@@ -1,6 +1,6 @@
 # Harness overview
 
-> **Alpha:** The `Harness` feature is in alpha stage and subject to breaking changes in minor versions until it graduates from its alpha status.
+> **Beta:** The `Harness` feature is in beta stage and subject to breaking changes in minor versions until it graduates from its beta status.
 
 The Harness is a session controller for building interactive agent applications. It handles the runtime concerns that sit between your UI and the agent loop: managing conversation threads, switching between agent modes, persisting state, gating tool execution with approvals, and coordinating subagents. You can focus on what your agent does rather than how to wire it together.
 

package/.docs/docs/harness/session.md

@@ -10,7 +10,7 @@ Because each session has its own identity and state, one Harness can serve many
 
 The rest of this page walks through the Session's state. Each part is a focused sub-object on `harness.session`:
 
-- **Who and where**: [Identity](#identity) sets the resource the session belongs to, and [Thread](#thread) tracks the currently bound thread.
+- **Who and where**: [Identity](#identity) sets the stable session `id`, `ownerId`, and resource the session belongs to, and [Thread](#thread) tracks the currently bound thread.
 - **How the agent behaves**: [Mode and model](#mode-and-model) controls which agent profile and model are active, and [Permission grants](#permission-grants) records what the user has approved to run without prompting.
 - **What's happening right now**: [Run state](#run-state) reflects the in-flight generation, and [Follow-ups](#follow-ups) holds messages queued to send when it finishes.
 - **What you store and render**: [State](#state) holds your application's structured data, and [Display state](#display-state) is the single snapshot your UI renders from.
@@ -19,14 +19,18 @@ The Harness performs actions that change this state — switching threads, modes
 
 ## Identity
 
-`session.identity` holds the resource ID the conversation belongs to and the currently bound thread ID. Threads are scoped to a resource ID, so this is what groups a conversation's threads together:
+`session.identity` holds three stable identifiers for the conversation: a session `id`, an `ownerId`, and the resource ID. Threads are scoped to a resource ID, so this is what groups a conversation's threads together:
 
 ```typescript
+const sessionId = harness.session.identity.getId()
+const ownerId = harness.session.identity.getOwnerId()
 const resourceId = harness.session.identity.getResourceId()
 const threadId = harness.session.thread.getId()
 ```
 
-The resource ID is set on the Harness constructor and defaults to the harness `id`. See [Resource IDs](https://mastra.ai/docs/harness/threads-and-state) for how it scopes threads.
+The session `id` and `ownerId` are stable for the life of the session — they don't change when the resource ID is switched. They mirror the `id` and `ownerId` fields on `SessionRecord` in storage, so storage layers can key sessions by a stable identifier rather than the mutable resource ID.
+
+The resource ID is set when creating a session via [`harness.createSession()`](https://mastra.ai/reference/harness/harness-class) and defaults to the harness `id`. See [Resource IDs](https://mastra.ai/docs/harness/threads-and-state) for how it scopes threads.
 
 ## Thread
 

package/.docs/docs/harness/threads-and-state.md

@@ -131,6 +131,8 @@ The resource ID is part of a conversation's identity, so you read it from the Se
 const resourceId = harness.session.identity.getResourceId()
 ```
 
+The session also has a stable `id` and `ownerId` (read with `session.identity.getId()` and `session.identity.getOwnerId()`). Unlike the resource ID, these don't change when you switch resources — see [Session identity](https://mastra.ai/docs/harness/session) for details.
+
 ## Related
 
 - [Harness overview](https://mastra.ai/docs/harness/overview)

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

@@ -210,9 +210,7 @@ The result is a three-tier system:
 2. **Observations**: A log of what the Observer has seen
 3. **Reflections**: Condensed observations when memory becomes too long
 
-### Retrieval mode (experimental)
-
-> **Note:** Retrieval mode is experimental. The API may change in future releases.
+### Retrieval mode
 
 Normal OM compresses messages into observations, which is great for staying on task, but the original wording is gone. Retrieval mode fixes this by keeping each observation group linked to the raw messages that produced it. When the agent needs exact wording, tool output, or chronology that the summary compressed away, it can call a `recall` tool to page through the source messages.
 

package/.docs/guides/guide/signal-provider.md

@@ -4,7 +4,7 @@ In this guide, you'll build a signal provider that polls an external service on
 
 The example watches build pipelines in a fake CI service, but the pattern applies to any pull-based source: an issue tracker, a status API, a queue, or your own backend.
 
-> **Alpha:** Signal providers are in alpha. Breaking changes may occur without a major version bump until the API is stable.
+> **Beta:** Signal providers are in beta. Breaking changes may occur without a major version bump until the API is stable.
 
 ## Prerequisites
 

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 66 models through Mastra's model router.
+Netlify AI Gateway provides unified access to multiple providers with built-in caching and observability. Access 64 models through Mastra's model router.
 
 Learn more in the [Netlify documentation](https://docs.netlify.com/build/ai-gateway/overview/).
 
@@ -52,9 +52,7 @@ ANTHROPIC_API_KEY=ant-...
 | `gemini/gemini-2.5-pro`                     |
 | `gemini/gemini-3-flash-preview`             |
 | `gemini/gemini-3-pro-image`                 |
-| `gemini/gemini-3-pro-image-preview`         |
 | `gemini/gemini-3.1-flash-image`             |
-| `gemini/gemini-3.1-flash-image-preview`     |
 | `gemini/gemini-3.1-flash-lite`              |
 | `gemini/gemini-3.1-pro-preview`             |
 | `gemini/gemini-3.1-pro-preview-customtools` |

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 336 models through Mastra's model router.
+OpenRouter aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 337 models through Mastra's model router.
 
 Learn more in the [OpenRouter documentation](https://openrouter.ai/models).
 
@@ -336,6 +336,7 @@ ANTHROPIC_API_KEY=ant-...
 | `rekaai/reka-flash-3`                                           |
 | `relace/relace-apply-3`                                         |
 | `relace/relace-search`                                          |
+| `sakana/fugu-ultra`                                             |
 | `sao10k/l3-lunaris-8b`                                          |
 | `sao10k/l3.1-70b-hanami-x1`                                     |
 | `sao10k/l3.1-euryale-70b`                                       |

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 290 models through Mastra's model router.
+Vercel aggregates models from multiple providers with enhanced features like rate limiting and failover. Access 292 models through Mastra's model router.
 
 Learn more in the [Vercel documentation](https://ai-sdk.dev/providers/ai-sdk-providers).
 
@@ -302,6 +302,7 @@ ANTHROPIC_API_KEY=ant-...
 | `xai/grok-build-0.1`                     |
 | `xai/grok-imagine-image`                 |
 | `xai/grok-imagine-video`                 |
+| `xai/grok-imagine-video-1.5`             |
 | `xai/grok-imagine-video-1.5-preview`     |
 | `xai/grok-stt`                           |
 | `xai/grok-tts`                           |
@@ -323,4 +324,5 @@ ANTHROPIC_API_KEY=ant-...
 | `zai/glm-5-turbo`                        |
 | `zai/glm-5.1`                            |
 | `zai/glm-5.2`                            |
+| `zai/glm-5.2-fast`                       |
 | `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 4550 models from 133 providers through a single API.
+Mastra provides a unified interface for working with LLMs across multiple providers, giving you access to 4544 models from 133 providers through a single API.
 
 ## Features
 

package/.docs/models/providers/baseten.md

@@ -34,7 +34,7 @@ for await (const chunk of stream) {
 
 | Model                                              | Context | Tools | Reasoning | Image | Audio | Video | Input $/1M | Output $/1M |
 | -------------------------------------------------- | ------- | ----- | --------- | ----- | ----- | ----- | ---------- | ----------- |
-| `baseten/deepseek-ai/DeepSeek-V4-Pro`              | 131K    |       |           |       |       |       | $2         | $3          |
+| `baseten/deepseek-ai/DeepSeek-V4-Pro`              | 262K    |       |           |       |       |       | $2         | $3          |
 | `baseten/moonshotai/Kimi-K2.5`                     | 262K    |       |           |       |       |       | $0.60      | $3          |
 | `baseten/moonshotai/Kimi-K2.6`                     | 262K    |       |           |       |       |       | $0.95      | $4          |
 | `baseten/moonshotai/Kimi-K2.7-Code`                | 262K    |       |           |       |       |       | $0.95      | $4          |
@@ -44,7 +44,7 @@ for await (const chunk of stream) {
 | `baseten/zai-org/GLM-4.7`                          | 200K    |       |           |       |       |       | $0.60      | $2          |
 | `baseten/zai-org/GLM-5`                            | 203K    |       |           |       |       |       | $0.95      | $3          |
 | `baseten/zai-org/GLM-5.1`                          | 203K    |       |           |       |       |       | $1         | $4          |
-| `baseten/zai-org/GLM-5.2`                          | 262K    |       |           |       |       |       | $1         | $4          |
+| `baseten/zai-org/GLM-5.2`                          | 203K    |       |           |       |       |       | $1         | $4          |
 
 ## Advanced configuration