Skip to content

ci: Version Packages#670

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

ci: Version Packages#670
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot commented Jun 1, 2026 •
edited
Loading

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@tanstack/ai@0.24.0

Minor Changes

  • #666 c1ae8b9 - feat: support multimodal (image) tool results

    Tools may now return an Array<ContentPart> (e.g. a text part plus an image part) and have it transmitted to the model as structured multimodal tool output instead of a JSON.stringify'd blob. This unblocks use cases like returning a screenshot from a tool so the model can see it (issue #363).

    • Detection is structural and opt-in by shape: a tool that returns a non-empty array whose every element is a valid ContentPart is passed through unchanged; strings and all other return values are serialized exactly as before, so there are no breaking changes.
    • The OpenAI Responses, Anthropic, and Google Gemini adapters convert the content parts into their native multimodal tool-output formats (function_call_output.output, tool_result content blocks, and functionResponse.parts respectively). Providers on the Chat Completions path (Groq, Ollama, Grok, OpenRouter chat) fall back to stringifying, which their APIs require.
    • AG-UI stream events (TOOL_CALL_RESULT.content, TOOL_CALL_END.result) remain string-only per the spec; the multimodal array travels on the tool message itself.

  • #673 a452ae8 - Populate AG-UI rawEvent on RUN_ERROR events with the provider's structured error body.

    Previously, when a streaming chat call failed the RUN_ERROR event carried only an
    opaque { message, code } headline (e.g. "Provider returned error"), and no adapter
    populated AG-UI's purpose-built rawEvent field — so the upstream provider detail was
    unrecoverable.

    Adapters now forward the provider's structured error body (e.g. an SDK APIError's
    parsed .error response body, or OpenRouter's mid-stream chunk.error) as rawEvent
    on the RUN_ERROR event. The new toRunErrorRawEvent helper extracts only known
    provider-body fields — never the raw SDK exception object, which can carry request
    metadata such as auth headers. The { message, code } contract of toRunErrorPayload
    is unchanged.

    The error surfaced to consumers via the ChatClient / useChat error (and the
    onError callback) now also carries code and rawEvent when present, so the upstream
    cause is recoverable in application code.

    Note: the OpenRouter SDK parses each in-band stream chunk's error through a strict
    schema ({ code, message }), so provider metadata survives only on pre-stream HTTP
    errors (rate-limit / overload / BYOK rejection), whose typed error class exposes the
    full body via .error.

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-event-client@0.4.3

@tanstack/ai-anthropic@0.12.0

Minor Changes

  • #666 c1ae8b9 - feat: support multimodal (image) tool results

    Tools may now return an Array<ContentPart> (e.g. a text part plus an image part) and have it transmitted to the model as structured multimodal tool output instead of a JSON.stringify'd blob. This unblocks use cases like returning a screenshot from a tool so the model can see it (issue #363).

    • Detection is structural and opt-in by shape: a tool that returns a non-empty array whose every element is a valid ContentPart is passed through unchanged; strings and all other return values are serialized exactly as before, so there are no breaking changes.
    • The OpenAI Responses, Anthropic, and Google Gemini adapters convert the content parts into their native multimodal tool-output formats (function_call_output.output, tool_result content blocks, and functionResponse.parts respectively). Providers on the Chat Completions path (Groq, Ollama, Grok, OpenRouter chat) fall back to stringifying, which their APIs require.
    • AG-UI stream events (TOOL_CALL_RESULT.content, TOOL_CALL_END.result) remain string-only per the spec; the multimodal array travels on the tool message itself.

  • #673 a452ae8 - Populate AG-UI rawEvent on RUN_ERROR events with the provider's structured error body.

    Previously, when a streaming chat call failed the RUN_ERROR event carried only an
    opaque { message, code } headline (e.g. "Provider returned error"), and no adapter
    populated AG-UI's purpose-built rawEvent field — so the upstream provider detail was
    unrecoverable.

    Adapters now forward the provider's structured error body (e.g. an SDK APIError's
    parsed .error response body, or OpenRouter's mid-stream chunk.error) as rawEvent
    on the RUN_ERROR event. The new toRunErrorRawEvent helper extracts only known
    provider-body fields — never the raw SDK exception object, which can carry request
    metadata such as auth headers. The { message, code } contract of toRunErrorPayload
    is unchanged.

    The error surfaced to consumers via the ChatClient / useChat error (and the
    onError callback) now also carries code and rawEvent when present, so the upstream
    cause is recoverable in application code.

    Note: the OpenRouter SDK parses each in-band stream chunk's error through a strict
    schema ({ code, message }), so provider metadata survives only on pre-stream HTTP
    errors (rate-limit / overload / BYOK rejection), whose typed error class exposes the
    full body via .error.

Patch Changes

@tanstack/ai-client@0.15.0

Minor Changes

  • #666 c1ae8b9 - feat: support multimodal (image) tool results

    Tools may now return an Array<ContentPart> (e.g. a text part plus an image part) and have it transmitted to the model as structured multimodal tool output instead of a JSON.stringify'd blob. This unblocks use cases like returning a screenshot from a tool so the model can see it (issue #363).

    • Detection is structural and opt-in by shape: a tool that returns a non-empty array whose every element is a valid ContentPart is passed through unchanged; strings and all other return values are serialized exactly as before, so there are no breaking changes.
    • The OpenAI Responses, Anthropic, and Google Gemini adapters convert the content parts into their native multimodal tool-output formats (function_call_output.output, tool_result content blocks, and functionResponse.parts respectively). Providers on the Chat Completions path (Groq, Ollama, Grok, OpenRouter chat) fall back to stringifying, which their APIs require.
    • AG-UI stream events (TOOL_CALL_RESULT.content, TOOL_CALL_END.result) remain string-only per the spec; the multimodal array travels on the tool message itself.

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-code-mode@0.2.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-code-mode-skills@0.2.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-gemini@0.13.0

Minor Changes

  • #666 c1ae8b9 - feat: support multimodal (image) tool results

    Tools may now return an Array<ContentPart> (e.g. a text part plus an image part) and have it transmitted to the model as structured multimodal tool output instead of a JSON.stringify'd blob. This unblocks use cases like returning a screenshot from a tool so the model can see it (issue #363).

    • Detection is structural and opt-in by shape: a tool that returns a non-empty array whose every element is a valid ContentPart is passed through unchanged; strings and all other return values are serialized exactly as before, so there are no breaking changes.
    • The OpenAI Responses, Anthropic, and Google Gemini adapters convert the content parts into their native multimodal tool-output formats (function_call_output.output, tool_result content blocks, and functionResponse.parts respectively). Providers on the Chat Completions path (Groq, Ollama, Grok, OpenRouter chat) fall back to stringifying, which their APIs require.
    • AG-UI stream events (TOOL_CALL_RESULT.content, TOOL_CALL_END.result) remain string-only per the spec; the multimodal array travels on the tool message itself.

  • #673 a452ae8 - Populate AG-UI rawEvent on RUN_ERROR events with the provider's structured error body.

    Previously, when a streaming chat call failed the RUN_ERROR event carried only an
    opaque { message, code } headline (e.g. "Provider returned error"), and no adapter
    populated AG-UI's purpose-built rawEvent field — so the upstream provider detail was
    unrecoverable.

    Adapters now forward the provider's structured error body (e.g. an SDK APIError's
    parsed .error response body, or OpenRouter's mid-stream chunk.error) as rawEvent
    on the RUN_ERROR event. The new toRunErrorRawEvent helper extracts only known
    provider-body fields — never the raw SDK exception object, which can carry request
    metadata such as auth headers. The { message, code } contract of toRunErrorPayload
    is unchanged.

    The error surfaced to consumers via the ChatClient / useChat error (and the
    onError callback) now also carries code and rawEvent when present, so the upstream
    cause is recoverable in application code.

    Note: the OpenRouter SDK parses each in-band stream chunk's error through a strict
    schema ({ code, message }), so provider metadata survives only on pre-stream HTTP
    errors (rate-limit / overload / BYOK rejection), whose typed error class exposes the
    full body via .error.

Patch Changes

@tanstack/ai-openrouter@0.11.0

Minor Changes

  • #673 a452ae8 - Populate AG-UI rawEvent on RUN_ERROR events with the provider's structured error body.

    Previously, when a streaming chat call failed the RUN_ERROR event carried only an
    opaque { message, code } headline (e.g. "Provider returned error"), and no adapter
    populated AG-UI's purpose-built rawEvent field — so the upstream provider detail was
    unrecoverable.

    Adapters now forward the provider's structured error body (e.g. an SDK APIError's
    parsed .error response body, or OpenRouter's mid-stream chunk.error) as rawEvent
    on the RUN_ERROR event. The new toRunErrorRawEvent helper extracts only known
    provider-body fields — never the raw SDK exception object, which can carry request
    metadata such as auth headers. The { message, code } contract of toRunErrorPayload
    is unchanged.

    The error surfaced to consumers via the ChatClient / useChat error (and the
    onError callback) now also carries code and rawEvent when present, so the upstream
    cause is recoverable in application code.

    Note: the OpenRouter SDK parses each in-band stream chunk's error through a strict
    schema ({ code, message }), so provider metadata survives only on pre-stream HTTP
    errors (rate-limit / overload / BYOK rejection), whose typed error class exposes the
    full body via .error.

Patch Changes

@tanstack/ai-preact@0.8.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-react@0.14.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-solid@0.12.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-svelte@0.12.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/ai-vue@0.12.0

Minor Changes

  • #628 8036b50 - Add typed runtime context for tools and middleware.

    Tools and middleware can now declare the runtime context shape they require, and
    chat(), ChatClient, and the framework useChat / createChat hooks infer
    the merged requirement and type-check the context option you pass against it.

    type AppContext = { userId: string; db: Db }

const listNotes = toolDefinition({
  name: 'list_notes' /* ... */,
}).server<AppContext>((_input, ctx) =>
  ctx.context.db.notes.findMany({ userId: ctx.context.userId }),
)

chat({
  adapter,
  messages,
  tools: [listNotes],
  context: { userId, db }, // required and type-checked because listNotes declares AppContext
})

    Runtime context is request-local application state for tool and middleware
    implementations (authenticated users, database clients, tenancy, feature flags,
    loggers, browser services). It is never sent to the model and is distinct from
    the AG-UI RunAgentInput.context protocol field.

    Untyped tools and middleware continue to receive unknown context and do not
    force a context option. Client tools receive client-local context via
    ChatClient / useChat; use forwardedProps to hand serializable client data
    to the server and map it into server context explicitly. See the new Runtime
    Context guide for details.

    Behavior change: tool output validation now also runs when a tool returns
    undefined or null. Previously these values bypassed outputSchema
    validation entirely; now the schema decides whether they are valid, so a tool
    whose schema forbids undefined/null surfaces a validation error
    (output-error) instead of silently passing. Tools whose schema permits
    null/undefined (e.g. nullable or void outputs) are unaffected.

Patch Changes

@tanstack/openai-base@0.5.0

Minor Changes

  • #666 c1ae8b9 - feat: support multimodal (image) tool results

    Tools may now return an Array<ContentPart> (e.g. a text part plus an image part) and have it transmitted to the model as structured multimodal tool output instead of a JSON.stringify'd blob. This unblocks use cases like returning a screenshot from a tool so the model can see it (issue #363).

    • Detection is structural and opt-in by shape: a tool that returns a non-empty array whose every element is a valid ContentPart is passed through unchanged; strings and all other return values are serialized exactly as before, so there are no breaking changes.
    • The OpenAI Responses, Anthropic, and Google Gemini adapters convert the content parts into their native multimodal tool-output formats (function_call_output.output, tool_result content blocks, and functionResponse.parts respectively). Providers on the Chat Completions path (Groq, Ollama, Grok, OpenRouter chat) fall back to stringifying, which their APIs require.
    • AG-UI stream events (TOOL_CALL_RESULT.content, TOOL_CALL_END.result) remain string-only per the spec; the multimodal array travels on the tool message itself.

  • #673 a452ae8 - Populate AG-UI rawEvent on RUN_ERROR events with the provider's structured error body.

    Previously, when a streaming chat call failed the RUN_ERROR event carried only an
    opaque { message, code } headline (e.g. "Provider returned error"), and no adapter
    populated AG-UI's purpose-built rawEvent field — so the upstream provider detail was
    unrecoverable.

    Adapters now forward the provider's structured error body (e.g. an SDK APIError's
    parsed .error response body, or OpenRouter's mid-stream chunk.error) as rawEvent
    on the RUN_ERROR event. The new toRunErrorRawEvent helper extracts only known
    provider-body fields — never the raw SDK exception object, which can carry request
    metadata such as auth headers. The { message, code } contract of toRunErrorPayload
    is unchanged.

    The error surfaced to consumers via the ChatClient / useChat error (and the
    onError callback) now also carries code and rawEvent when present, so the upstream
    cause is recoverable in application code.

    Note: the OpenRouter SDK parses each in-band stream chunk's error through a strict
    schema ({ code, message }), so provider metadata survives only on pre-stream HTTP
    errors (rate-limit / overload / BYOK rejection), whose typed error class exposes the
    full body via .error.

Patch Changes

@tanstack/ai-devtools-core@0.4.3

Patch Changes

@tanstack/ai-elevenlabs@0.2.15

Patch Changes

@tanstack/ai-event-client@0.4.3

Patch Changes

@tanstack/ai-fal@0.7.18

Patch Changes

@tanstack/ai-grok@0.9.2

Patch Changes

@tanstack/ai-groq@0.2.9

Patch Changes

@tanstack/ai-isolate-cloudflare@0.2.16

Patch Changes

  • Updated dependencies [8036b50]:
    • @tanstack/ai-code-mode@0.2.0

@tanstack/ai-isolate-node@0.1.25

Patch Changes

  • Updated dependencies [8036b50]:
    • @tanstack/ai-code-mode@0.2.0

@tanstack/ai-isolate-quickjs@0.1.25

Patch Changes

  • Updated dependencies [8036b50]:
    • @tanstack/ai-code-mode@0.2.0

@tanstack/ai-ollama@0.6.24

Patch Changes

@tanstack/ai-openai@0.10.5

Patch Changes

  • Updated dependencies [c1ae8b9, a452ae8, 8036b50]:
    • @tanstack/ai@0.24.0
    • @tanstack/ai-client@0.15.0
    • @tanstack/openai-base@0.5.0

@tanstack/ai-react-ui@0.8.5

Patch Changes

  • Updated dependencies [c1ae8b9, 8036b50]:
    • @tanstack/ai-client@0.15.0
    • @tanstack/ai-react@0.14.0

@tanstack/ai-solid-ui@0.7.5

Patch Changes

  • Updated dependencies [c1ae8b9, 8036b50]:
    • @tanstack/ai-client@0.15.0
    • @tanstack/ai-solid@0.12.0

@tanstack/ai-vue-ui@0.2.9

Patch Changes

  • Updated dependencies [8036b50]:
    • @tanstack/ai-vue@0.12.0

@tanstack/preact-ai-devtools@0.1.46

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.3

@tanstack/react-ai-devtools@0.2.46

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.3

@tanstack/solid-ai-devtools@0.2.46

Patch Changes

  • Updated dependencies []:
    • @tanstack/ai-devtools-core@0.4.3

@github-actions github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from dcf7204 to a5c7e8e Compare June 1, 2026 06:29
@github-actions github-actions Bot force-pushed the changeset-release/main branch from a5c7e8e to f23c052 Compare June 1, 2026 07:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants