@mastra/client-js 1.35.0 → 1.35.1-alpha.1

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # @mastra/client-js
 
+## 1.35.1-alpha.1
+
+### Patch Changes
+
+- Updated dependencies [[`ba369f2`](https://github.com/mastra-ai/mastra/commit/ba369f2a0aaf998da0d6aa033d26f64f96bef8ac), [`dcfed93`](https://github.com/mastra-ai/mastra/commit/dcfed93e1e256c6abfa792cbb7ca836f5d0e8638), [`2876e15`](https://github.com/mastra-ai/mastra/commit/2876e15b4d2f616a3bc1ed3af57d546c268384ce), [`598080f`](https://github.com/mastra-ai/mastra/commit/598080f224edb3f0f5b801035b067fac50a56a03)]:
+  - @mastra/core@1.55.0-alpha.1
+
+## 1.35.1-alpha.0
+
+### Patch Changes
+
+- Updated dependencies [[`3f472b4`](https://github.com/mastra-ai/mastra/commit/3f472b468892a1ff14ccb43cc0343b86f7d8fd7d), [`35b929b`](https://github.com/mastra-ai/mastra/commit/35b929b7abc3d20d85c7985880960ac2d04a6c86), [`9b3626a`](https://github.com/mastra-ai/mastra/commit/9b3626aeb1d16fcd34b0a8e94c114ddb80a3b240)]:
+  - @mastra/core@1.55.0-alpha.0
+
 ## 1.35.0
 
 ### Minor Changes

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-client-js
 description: Documentation for @mastra/client-js. Use when working with @mastra/client-js APIs, configuration, or implementation.
 metadata:
   package: "@mastra/client-js"
-  version: "1.35.0"
+  version: "1.35.1-alpha.1"
 ---
 
 ## When to use
@@ -34,7 +34,7 @@ Read the individual reference documents for detailed explanations and code examp
 - [Reference: toAISdkStream()](references/reference-ai-sdk-to-ai-sdk-stream.md) - API reference for toAISdkStream(), a function to convert Mastra streams to AI SDK-compatible streams.
 - [Reference: toAISdkV4Messages()](references/reference-ai-sdk-to-ai-sdk-v4-messages.md) - API reference for toAISdkV4Messages(), a function to convert Mastra messages to AI SDK v4 UI messages.
 - [Reference: toAISdkV5Messages()](references/reference-ai-sdk-to-ai-sdk-v5-messages.md) - API reference for toAISdkV5Messages(), a function to convert Mastra messages to AI SDK v5 UI messages.
-- [Reference: Agent Builder API](references/reference-client-js-agent-builder.md) - Learn how to interact with Agent Builder actions, including starting runs, streaming progress, resuming suspended steps, and observing runs using the client-js SDK.
+- [Reference: Agent Builder API](references/reference-client-js-agent-builder.md) - Learn how to interact with Agent Builder actions, including starting runs and streaming progress, plus resuming suspended steps and observing runs using the client-js SDK.
 - [Reference: Agents API](references/reference-client-js-agents.md) - Learn how to interact with Mastra AI agents, including generating responses, streaming interactions, and managing agent tools using the client-js SDK.
 - [Reference: OpenAI Responses API Conversations](references/reference-client-js-conversations.md) - API reference for the client-js helpers that call Mastra's OpenAI-compatible `/v1/conversations` routes.
 - [Reference: Error handling](references/reference-client-js-error-handling.md) - Learn about the built-in retry mechanism and error handling capabilities in the Mastra client-js SDK.

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.35.0",
+  "version": "1.35.1-alpha.1",
   "package": "@mastra/client-js",
   "exports": {},
   "modules": {}

package/dist/docs/references/docs-agents-a2a.md

@@ -53,7 +53,9 @@ An agent card includes fields like the agent name, description, endpoint URL, pr
 }
 ```
 
-A2A represents work as messages and tasks. Messages carry text, file, or structured data parts. Tasks are stateful units of work with IDs and lifecycle states, so clients can follow long-running work, send follow-up turns, cancel work, or resubscribe after a disconnect.
+A2A represents work as messages and tasks. Messages carry text, file, or structured data parts.
+
+Tasks are stateful units of work with IDs and lifecycle states. Clients can follow long-running work and send follow-up turns. They can also cancel work or resubscribe after a disconnect.
 
 ## Get started
 
@@ -83,7 +85,7 @@ export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'Support Agent',
   instructions: 'Answer user questions and delegate weather questions when needed.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   agents: {
     remoteWeatherAgent,
   },

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

@@ -14,9 +14,9 @@ The editor manages two types of resources alongside agents:
 Use the editor when you want to:
 
 - **Let non-developers iterate**: Give subject-matter experts and prompt engineers a way to tune agent behavior without touching code or waiting for deploys.
-- **Version everything**: Every save creates a snapshot so you can compare changes, roll back instantly, and audit what changed and when.
-- **Run experiments**: Route different users or requests to different agent versions for A/B testing, canary rollouts, or prompt experimentation.
-- **Target specific versions**: Pin a version per request, per user, or per environment so production stays stable while new versions are tested.
+- **Version everything**: Every save creates a snapshot so you can compare changes and roll back instantly, plus audit what changed and when.
+- **Run experiments**: Route different users or requests to different agent versions for A/B testing or canary rollouts, or alternatively prompt experimentation.
+- **Target specific versions**: Pin a version per request or per user, or alternatively per environment so production stays stable while new versions are tested.
 - **Manage tools at runtime**: Add integration tools from Composio or Arcade, or connect MCP servers, without updating code.
 - **Override code agents**: Change the instructions, tools, or variables of a code-defined agent while keeping the original code as the baseline.
 
@@ -95,7 +95,7 @@ When `source` is `'code'`, the editor writes each override to a deterministic JS
 
 The code source uses the Git history of each per-agent JSON file as its version history. Each commit that changes a file is shown as a read-only version in Studio, labeled with the commit message. Saving in Studio updates the working file in place rather than creating a database draft, so the version dropdown reflects your actual commit history.
 
-This means versions and rollbacks are managed through Git rather than through draft and publish actions.
+As a result, versions and rollbacks are managed through Git rather than through draft and publish actions.
 
 ## Studio
 
@@ -105,7 +105,7 @@ Modify the system prompt and save a new draft version. Afterwards, publish the d
 
 ## Programmatic control
 
-Everything you can do in Studio is also available programmatically through [`mastra.getEditor()`](https://mastra.ai/reference/core/getEditor). This is useful for scripting bulk updates, seeding stored configurations from code, or building automation that tunes agents based on evaluation results.
+Everything you can do in Studio is also available programmatically through [`mastra.getEditor()`](https://mastra.ai/reference/core/getEditor). This is useful for scripting bulk updates or seeding stored configurations from code, or alternatively building automation that tunes agents based on evaluation results.
 
 Call `mastra.getEditor()` from anywhere you have access to the `Mastra` instance. It returns the `MastraEditor` instance you registered, with namespaces for each resource type:
 
@@ -167,7 +167,7 @@ Because stored agents are data, you can build automation loops that tune agents
 - Re-run the experiment against the draft and compare scores to the baseline.
 - Promote the draft to the published version when the scores improve.
 
-This turns agent tuning into a closed feedback loop. One agent owns the production configuration, another agent iterates on it, and every change is versioned so you can roll back if a round of automated edits makes things worse. Combine this with [version targeting](#version-targeting-and-experimentation) to keep production traffic on the published version while the draft is being tested. See the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for the full namespace API.
+This turns agent tuning into a closed feedback loop. One agent owns the production configuration and another agent iterates on it, plus every change is versioned so you can roll back if a round of automated edits makes things worse. Combine this with [version targeting](#version-targeting-and-experimentation) to keep production traffic on the published version while the draft is being tested. See the [MastraEditor reference](https://mastra.ai/reference/editor/mastra-editor) for the full namespace API.
 
 ## What can be overridden
 
@@ -190,7 +190,7 @@ import { Agent } from '@mastra/core/agent'
 export const supportAgent = new Agent({
   id: 'support-agent',
   name: 'support-agent',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
   editor: { instructions: true, tools: { description: true } },
 })
 ```
@@ -209,7 +209,7 @@ When a field is owned by code, Studio shows it as read-only and the server strip
 
 ## Versioning
 
-Every time you save changes to an agent or prompt block, a new version snapshot is created. Versions give you a full history of your agent's configuration. You can roll back to any previous state, compare what changed between two snapshots, and target specific versions per request for A/B testing or gradual rollouts.
+Every time you save changes to an agent or prompt block, a new version snapshot is created. Versions give you a full history of your agent's configuration. You can roll back to any previous state and compare what changed between two snapshots, plus target specific versions per request for A/B testing or gradual rollouts.
 
 Version management is available through the server Studio, REST API, the Client SDK, and the React SDK. See the [Client SDK agents reference](https://mastra.ai/reference/client-js/agents) for endpoints, SDK methods, and code examples.
 
@@ -223,7 +223,9 @@ Each version has one of three statuses:
 | Published | The active version used in production. Only one version can be published at a time. |
 | Archived  | A previous version that's no longer active. You can restore any archived version.   |
 
-The typical flow is: Edit the draft, test it, then activate it to make it the published version. The previously published version becomes archived so you can restore it if needed. You can do this through Studio or programmatically through the API.
+The typical flow is: Edit the draft and test it, plus then activate it to make it the published version.
+
+The previously published version becomes archived so you can restore it if needed. You can do this through Studio or programmatically through the API.
 
 This lifecycle makes it safe to experiment. Non-technical team members can iterate on a draft without affecting production traffic, then publish when ready. If something goes wrong, restoring a previous version is a single API call.
 
@@ -240,7 +242,9 @@ Pass a `versionId` or `status` when calling the agent through the Client SDK, se
 
 ### Version selection
 
-By default, [`mastra.getAgentById()`](https://mastra.ai/reference/core/getAgentById) loads the published (active) version of the stored override. You can request a specific version, which is useful for testing a draft before publishing, running A/B experiments, or pinning a user to a known-good configuration:
+By default, [`mastra.getAgentById()`](https://mastra.ai/reference/core/getAgentById) loads the published (active) version of the stored override.
+
+Use a specific version to test a draft before publishing or run an A/B experiment. You can also pin a user to a known-good configuration:
 
 ```typescript
 // Load the published version (default)
@@ -278,9 +282,9 @@ When a [supervisor agent](https://mastra.ai/docs/agents/supervisor-agents) deleg
 
 Set version overrides at three levels, with later levels taking priority:
 
-1. **Mastra instance config** — global defaults that apply to every `generate()` and `stream()` call.
-2. **Per-invocation options** — overrides passed directly to `generate()` or `stream()`.
-3. **Server request body** — overrides sent in the `versions` field of an API request.
+1. **Mastra instance config**: global defaults that apply to every `generate()` and `stream()` call.
+2. **Per-invocation options**: overrides passed directly to `generate()` or `stream()`.
+3. **Server request body**: overrides sent in the `versions` field of an API request.
 
 Resolution order: **per-invocation > request body > Mastra instance defaults > code-defined agent**.
 

package/dist/docs/references/docs-long-running-agents-schedules.md

@@ -25,7 +25,7 @@ const pinger = new Agent({
   id: 'pinger',
   name: 'Pinger',
   instructions: 'Report the current system status in one sentence.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
 })
 
 const mastra = new Mastra({
@@ -136,7 +136,7 @@ await mastra.schedules.create({
 })
 ```
 
-Workflow schedules created this way are independent of the declarative `schedule` field on `createWorkflow` — see [scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows) for the declarative form and Studio views.
+Workflow schedules created this way are independent of the declarative `schedule` field on `createWorkflow`, see [scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows) for the declarative form and Studio views.
 
 ### Custom IDs
 
@@ -187,7 +187,7 @@ The hooks are:
 
 - `prepare`: runs before the fire. Return an object to override fire-time parameters such as `prompt` or `threadId`, `null` to skip the fire, or `undefined` to use the stored defaults.
 - `onFinish`: runs once per trigger that reached a non-error, non-abort terminal state.
-- `onError`: runs when `prepare`, the signal, or the agent run threw.
+- `onError`: runs after a failure in `prepare` or the signal. It also runs when the agent run fails.
 - `onAbort`: runs when the run was aborted mid-stream.
 
 Every hook context includes `agentId` (the agent the schedule fired for) alongside `schedule` and `trigger`.

package/dist/docs/references/docs-long-running-agents-signals.md

@@ -6,7 +6,7 @@
 
 > **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.
+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 or drops input into the running agent loop, or alternatively queues input for the next turn.
 
 Use message APIs for user-authored input. Use `sendSignal()` for lower-level system context, such as background task notifications, policy reminders, or processor-generated context.
 
@@ -29,7 +29,7 @@ const agent = new Agent({
   id: 'support-agent',
   name: 'Support Agent',
   instructions: 'Help the user compare options.',
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
 })
 
 const thread = {
@@ -143,7 +143,7 @@ The model receives the signal as context like this:
 <notification source="github" pr="123">PR #123 has a new review comment from User X about the API surface.</notification>
 ```
 
-Use XML-safe `tagName` and attribute names. They can contain letters, numbers, underscores, periods, and hyphens. They must start with a letter or underscore.
+Use XML-safe `tagName` and attribute names. They can contain letters, numbers, shows, periods, and hyphens. They must start with a letter or underscore.
 
 #### Storage support
 
@@ -320,7 +320,9 @@ Use `createNotificationInboxTool()` to give agents one tool for inbox actions in
 
 Signals coordinate runs through a pub/sub backend. When a signal arrives on a backend that implements `LeaseProvider`, Mastra acquires a lease on the target thread so a single process owns the conversation at a time, then either wakes the agent or routes the input into the running loop. Backends without leasing fall back to a no-op that always grants ownership, which is fine in a single process but not across instances.
 
-The default in-memory pub/sub can't cross instance boundaries. On serverless platforms like Vercel, or any multi-instance deployment, a follow-up signal can land on a different instance than the one running the agent. Without a shared pub/sub, that instance can't reach the active run and starts its own, leaving the original run untouched and the thread processed twice.
+The default in-memory pub/sub can't cross instance boundaries. On serverless platforms like Vercel, or any multi-instance deployment, a follow-up signal can be routed to a different instance than the one running the agent.
+
+Without a shared pub/sub, that instance can't reach the active run and starts its own, leaving the original run untouched and the thread processed twice.
 
 Configure a shared pub/sub backed by Redis Streams on the `Mastra` instance so leases and signals coordinate across instances:
 
@@ -360,7 +362,9 @@ If you call Mastra over HTTP directly, use `POST /api/agents/:agentId/send-messa
 
 ### Use the client SDK
 
-The JavaScript client exposes thread signal APIs. Use `subscribeToThread()` before sending thread input so the client can render the stream that wakes from, or receives, the input.
+The JavaScript client exposes thread signal APIs.
+
+Use `subscribeToThread()` before sending thread input so the client can render the stream that receives the input or wakes in response to it.
 
 ```typescript
 const agent = client.getAgent('supportAgent')

package/dist/docs/references/docs-server-auth-firebase.md

@@ -93,11 +93,11 @@ The `MastraAuthFirebase` class can be configured through constructor options or
 - `FIREBASE_SERVICE_ACCOUNT`: Path to Firebase service account JSON file
 - `FIRESTORE_DATABASE_ID` or `FIREBASE_DATABASE_ID`: Firestore database ID
 
-> **Note:** When constructor options aren't provided, the class automatically reads these environment variables. This means you can call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
+> **Note:** When constructor options aren't provided, the class automatically reads these environment variables. As a result, you can call `new MastraAuthFirebase()` without any arguments if your environment variables are properly configured.
 
 ### User Authorization
 
-By default, `MastraAuthFirebase` uses Firestore to manage user access. It expects a collection named `user_access` with documents keyed by user UIDs. The presence of a document in this collection determines whether a user is authorized.
+By default, `MastraAuthFirebase` uses Firestore to manage user access. It expects a `user_access` collection with documents keyed by user UIDs. The presence of a document in this collection determines whether a user is authorized.
 
 ```text
 user_access/

package/dist/docs/references/docs-server-mastra-client.md

@@ -138,7 +138,7 @@ Visit [MastraClient](https://mastra.ai/reference/client-js/mastra-client) for mo
 
 ## Credentials and session cookies
 
-**Authenticate Mastra API calls with session cookies** when your UI and Mastra API aren't on the same origin—different host, subdomain, or port (for example Mastra Studio on one port and a custom server on another). Add **`credentials: 'include'`** to `MastraClient` so each request carries the cookies the user already has after sign-in. Skip this and you will often get **`401`** responses from Mastra even though login succeeded in the browser.
+**Authenticate Mastra API calls with session cookies** when your UI and Mastra API aren't on the same origin, different host, subdomain, or port (for example Mastra Studio on one port and a custom server on another). Add **`credentials: 'include'`** to `MastraClient` so each request carries the cookies the user already has after sign-in. Skip this and you will often get **`401`** responses from Mastra even though login succeeded in the browser.
 
 ```typescript
 import { MastraClient } from '@mastra/client-js'
@@ -149,7 +149,7 @@ export const mastraClient = new MastraClient({
 })
 ```
 
-**Allow credentialed cross-origin requests on your server**—see [CORS: requests with credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#requests_with_credentials). You need a concrete `Access-Control-Allow-Origin` (not `*`) and `Access-Control-Allow-Credentials: true`, or the browser will block the call before it reaches Mastra.
+**Allow credentialed cross-origin requests on your server**, see [CORS: requests with credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#requests_with_credentials). You need a concrete `Access-Control-Allow-Origin` (not `*`) and `Access-Control-Allow-Credentials: true`, or the browser will block the call before it reaches Mastra.
 
 **Using `@mastra/react`?** Wrap your app with `MastraReactProvider`, set `baseUrl` and `apiPrefix` to match your server, and rely on the default `credentials: 'include'`. Change `credentials` only when you want `same-origin` or `omit` behavior.
 
@@ -237,7 +237,7 @@ export const colorAgent = new Agent({
   instructions: `You are a helpful CSS assistant.
   You can change the background color of web pages.
   Respond with a hex reference for the color requested by the user`,
-  model: 'openai/gpt-5.5',
+  model: 'openai/gpt-5.6-sol',
 })
 ```
 

package/dist/docs/references/reference-ai-sdk-to-ai-sdk-messages.md

@@ -2,7 +2,7 @@
 
 # toAISdkMessages()
 
-Converts messages from various input formats to AI SDK UI message format. `toAISdkMessages()` keeps the existing AI SDK v5/default behavior. If your app is typed against AI SDK v6, pass `version: 'v6'`.
+Converts messages from input formats to AI SDK UI message format. `toAISdkMessages()` keeps the existing AI SDK v5/default behavior. If your app is typed against AI SDK v6, pass `version: 'v6'`.
 
 `version: 'v6'` uses the MessageList AI SDK v6 UI output path. MessageList input detection and ingestion remain unchanged.
 

package/dist/docs/references/reference-ai-sdk-to-ai-sdk-v4-messages.md

@@ -2,7 +2,7 @@
 
 # toAISdkV4Messages()
 
-Converts messages from various input formats to AI SDK V4 UI message format. This function accepts messages in multiple formats (strings, AI SDK V4/V5 messages, Mastra DB messages, etc.) and normalizes them to the AI SDK V4 `UIMessage` format, which is suitable for use with AI SDK UI components like `useChat()`.
+Converts messages from input formats to AI SDK V4 UI message format. This function accepts messages in multiple formats (strings, AI SDK V4/V5 messages, Mastra DB messages, etc.) and normalizes them to the AI SDK V4 `UIMessage` format, which is suitable for use with AI SDK UI components like `useChat()`.
 
 ## Usage example
 

package/dist/docs/references/reference-ai-sdk-to-ai-sdk-v5-messages.md

@@ -2,7 +2,7 @@
 
 # toAISdkV5Messages()
 
-Converts messages from various input formats to AI SDK V5 (and later) UI message format. This function accepts messages in multiple formats (strings, AI SDK V4/V5 messages, Mastra DB messages, etc.) and normalizes them to the AI SDK V5+ `UIMessage` format, which is suitable for use with AI SDK UI components like `useChat()`.
+Converts messages from input formats to AI SDK V5 (and later) UI message format. This function accepts messages in multiple formats (strings, AI SDK V4/V5 messages, Mastra DB messages, etc.) and normalizes them to the AI SDK V5+ `UIMessage` format, which is suitable for use with AI SDK UI components like `useChat()`.
 
 ## Usage example
 

package/dist/docs/references/reference-client-js-agents.md

@@ -2,7 +2,7 @@
 
 # Agents API
 
-The Agents API provides methods to interact with Mastra AI agents, including generating responses, streaming interactions, and managing agent tools.
+The Agents API provides methods to interact with Mastra AI agents, including generating responses and streaming interactions. It also provides methods for managing agent tools.
 
 ## Getting all agents
 
@@ -155,7 +155,7 @@ for await (const part of uiMessageStream) {
 
 ### `sendMessage()`
 
-Send user-authored input to an active agent run or idle memory thread. Use this with `subscribeToThread()` so the client can render the stream that wakes from, or receives, the message.
+Send user-authored input to an active agent run or idle memory thread. Use this with `subscribeToThread()` so the client can render the stream that wakes from, or receives the message.
 
 ```typescript
 const agent = mastraClient.getAgent('support-agent')
@@ -285,7 +285,7 @@ await subscription.processDataStream({
 
 ### `streamUntilIdle()`
 
-Stream a response and keep the stream open until every [background task](https://mastra.ai/docs/long-running-agents/background-tasks) dispatched during the run completes. The server re-enters the agentic loop on each task completion so the LLM can react to results in the same call. Requires background tasks to be [enabled on the Mastra instance](https://mastra.ai/reference/configuration) and a memory thread; otherwise the call falls through to a plain `stream()`.
+Stream a response and keep the stream open until every [background task](https://mastra.ai/docs/long-running-agents/background-tasks) dispatched during the run completes. The server re-enters the agentic loop on each task completion so the LLM can react to results in the same call. Requires background tasks to be [enabled on the Mastra instance](https://mastra.ai/reference/configuration) and a memory thread; otherwise the call uses a plain `stream()`.
 
 ```typescript
 const response = await agent.streamUntilIdle('Research solana for me', {
@@ -307,7 +307,7 @@ response.processDataStream({
 
 ### `resumeStreamUntilIdle()`
 
-Resume a suspended agent stream with custom data and keep the stream open until every [background task](https://mastra.ai/docs/long-running-agents/background-tasks) dispatched during the run completes. Use this to continue execution after a suspension point, such as a workflow suspend within an agent. Requires background tasks to be [enabled on the Mastra instance](https://mastra.ai/reference/configuration) and a memory thread; otherwise the call falls through to a plain `resumeStream()`:
+Resume a suspended agent stream with custom data and keep the stream open until every [background task](https://mastra.ai/docs/long-running-agents/background-tasks) dispatched during the run completes. Use this to continue execution after a suspension point, such as a workflow suspend within an agent. Requires background tasks to be [enabled on the Mastra instance](https://mastra.ai/reference/configuration) and a memory thread; otherwise the call uses a plain `resumeStream()`:
 
 ```typescript
 const response = await agent.resumeStreamUntilIdle(
@@ -366,7 +366,7 @@ response.processDataStream({
 
 ### `listSuspendedRuns()`
 
-List suspended runs for the agent from storage — runs waiting on a tool-call approval or on a tool that suspended. Discovery is backed by storage, so it works after a server restart and across server instances. Pass the returned `runId` to `approveToolCall()`, `declineToolCall()`, or `resumeStream()`.
+List suspended runs for the agent from storage: runs waiting on a tool-call approval or on a tool that suspended. Discovery is backed by storage, so it works after a server restart and across server instances. Pass the returned `runId` to `approveToolCall()`, `declineToolCall()`, or `resumeStream()`.
 
 ```typescript
 const { runs, total } = await agent.listSuspendedRuns({
@@ -655,9 +655,9 @@ const screenshotTool = createTool({
 
 ### Tracing client tools
 
-When `@mastra/observability` is installed and configured on the server, a client-side tool records a `CLIENT_TOOL_CALL` span as a child of the current `AGENT_RUN` span. The server creates that span when the model emits the client tool call, injects a W3C trace carrier into the outgoing tool-call chunk, and ends the span once the tool arguments are available. Without server-side observability configured, client tool tracing is a no-op.
+When `@mastra/observability` is installed and configured on the server, a client-side tool records a `CLIENT_TOOL_CALL` span as a child of the current `AGENT_RUN` span. The server creates that span when the model emits the client tool call and injects a W3C trace carrier into the outgoing tool-call chunk. It ends the span once the tool arguments are available. Without server-side observability configured, client tool tracing is a no-op.
 
-The client SDK also measures the wall-clock duration of each client tool's `execute` function and ships it back to the server, where it's emitted as a `mastra_tool_duration_ms` metric with `toolType: "client"`.
+The client SDK also measures the wall-clock duration of each client tool's `execute` function and sends it back to the server, where it's emitted as a `mastra_tool_duration_ms` metric with `toolType: "client"`.
 
 For richer telemetry from inside your tool's `execute` function, use the `observe` helper on the execution context to add child spans and structured logs:
 
@@ -680,9 +680,9 @@ const fetchUserTool = createTool({
 })
 ```
 
-`observe` is always available — when no tracing context is active (e.g. running outside a traced agent), `span` runs the function directly and `log` is a no-op. No null-checking needed.
+`observe` is always available: when no tracing context is active (e.g. running outside a traced agent), `span` runs the function directly and `log` is a no-op. No null-checking needed.
 
-The SDK serializes everything the collector buffered as OTLP/JSON and ships it back in the next request body. The server's `@mastra/observability` package validates that the spans belong to the correct trace (preventing cross-trace injection) and forwards each span/log into the same observability bus that server-side telemetry uses. Your existing exporters pick them up automatically after observability is configured.
+The SDK serializes everything the collector buffered as OTLP/JSON and sends it back in the next request body. The server's `@mastra/observability` package validates that the spans belong to the correct trace (preventing cross-trace injection) and forwards each span/log into the same observability bus that server-side telemetry uses. Your existing exporters pick them up automatically after observability is configured.
 
 ## Stored agents
 

package/dist/docs/references/reference-client-js-memory.md

@@ -168,7 +168,7 @@ const result = await thread.listMessages({
 })
 ```
 
-Metadata filters match shallow scalar values only: `string`, finite `number`, `boolean`, and `null`. Every key-value pair must match with AND semantics. `null` matches an explicit `null` value, not a missing metadata key. Metadata keys must start with a letter or underscore, may contain only alphanumeric characters and underscores, must be 128 characters or fewer, and can't use reserved prototype keys such as `__proto__`, `constructor`, or `prototype`. Performance depends on the server storage backend, and arbitrary metadata filters may scan candidate messages.
+Metadata filters match shallow scalar values only: `string`, finite `number`, `boolean`, and `null`. Every key-value pair must match with AND semantics. `null` matches only keys explicitly set to `null`. Metadata keys must start with a letter or underscore and contain only alphanumeric or underscore characters. The limit is 128 characters. Reserved prototype keys such as `__proto__`, `constructor`, and `prototype` aren't allowed. Performance depends on the server storage backend, and arbitrary metadata filters may scan candidate messages.
 
 ### Delete Messages
 
@@ -226,7 +226,7 @@ await mastraClient.updateWorkingMemory({
 // Returns: { success: true }
 ```
 
-**Note:** For resource-scoped working memory, you must provide the `resourceId` parameter. This allows the memory to persist across all conversation threads for that user.
+For resource-scoped working memory, you must provide the `resourceId` parameter. It allows the memory to persist across all conversation threads for that user.
 
 ### Get Memory Status
 

package/dist/docs/references/reference-client-js-workflows.md

@@ -142,7 +142,7 @@ await run.resume({
 })
 ```
 
-When a [`.foreach()`](https://mastra.ai/reference/workflows/workflow-methods/foreach) step suspends across multiple iterations, pass `forEachIndex` (zero-based; `0` targets the first iteration) to resume one iteration at a time. Iterations you don't target remain suspended.
+When a [`.foreach()`](https://mastra.ai/reference/workflows/workflow-methods/foreach) step suspends across multiple iterations, pass `forEachIndex` (zero-based. `0` targets the first iteration) to resume one iteration at a time. Iterations you don't target remain suspended.
 
 ```typescript
 await run.resume({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/client-js",
-  "version": "1.35.0",
+  "version": "1.35.1-alpha.1",
   "description": "The official TypeScript library for the Mastra Client API",
   "author": "",
   "type": "module",
@@ -39,8 +39,8 @@
     "canonicalize": "^1.0.8",
     "jose": "^6.2.1",
     "json-schema": "^0.4.0",
-    "@mastra/schema-compat": "1.3.4",
-    "@mastra/core": "1.54.0"
+    "@mastra/core": "1.55.0-alpha.1",
+    "@mastra/schema-compat": "1.3.4"
   },
   "peerDependencies": {
     "zod": "^3.25.0 || ^4.0.0"
@@ -56,10 +56,10 @@
     "typescript": "^6.0.3",
     "vitest": "4.1.10",
     "zod": "^4.4.3",
-    "@internal/ai-sdk-v5": "0.0.65",
-    "@internal/lint": "0.0.118",
     "@internal/ai-sdk-v4": "0.0.65",
-    "@internal/types-builder": "0.0.93"
+    "@internal/ai-sdk-v5": "0.0.65",
+    "@internal/types-builder": "0.0.93",
+    "@internal/lint": "0.0.118"
   },
   "engines": {
     "node": ">=22.13.0"