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

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # @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

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.1-alpha.0"
+  version: "1.35.1-alpha.1"
 ---
 
 ## When to use

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.35.1-alpha.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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mastra/client-js",
-  "version": "1.35.1-alpha.0",
+  "version": "1.35.1-alpha.1",
   "description": "The official TypeScript library for the Mastra Client API",
   "author": "",
   "type": "module",
@@ -39,7 +39,7 @@
     "canonicalize": "^1.0.8",
     "jose": "^6.2.1",
     "json-schema": "^0.4.0",
-    "@mastra/core": "1.55.0-alpha.0",
+    "@mastra/core": "1.55.0-alpha.1",
     "@mastra/schema-compat": "1.3.4"
   },
   "peerDependencies": {