Patch Changes

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

Patch Changes

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

Patch Changes

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

Patch Changes

• #933 fbfd4be - Fall back to non-strict function tools for free-form map schemas so OpenAI requests preserve dynamic keys and avoid strict-schema validation errors.

• Updated dependencies [5fcaf90, 2665085, e0bbbdd, f830d9e, f830d9e, de5fbb5]:

  • @tanstack/ai@0.41.0

Minor Changes

• #405 2665085 - Added Gemini Realtime Adapter

• #918 f830d9e - Gate the tool-call part's approval field on the tool's needsApproval flag.
  Previously approval? was declared on every typed tool-call part regardless of
  whether the tool could ever request approval. Now the flag is captured as a
  literal type (toolDefinition({ needsApproval: true }) → true) and threaded
  through ClientTool / ToolDefinitionInstance / ToolDefinition, and
  ToolCallPartForTool only includes approval for tools defined with
  needsApproval: true:

  const { messages } = useChat({ tools: [getGuitars, addToCart] }) // addToCart: needsApproval: true
  for (const part of message.parts) {
    if (part.type !== 'tool-call') continue
    if (part.name === 'addToCart') part.approval?.id // ✅ typed
    if (part.name === 'getGuitars') part.approval // ✅ compile error — no such field
  }

  ⚠️ Breaking change (types only)

  This is the primary migration surface for this release. When you pass a typed
  tools array to useChat / createChat / injectChat, reading part.approval
  on a mixed tool-call union without first narrowing by part.name no longer
  compiles. Code that previously did part.approval?.id in a generic handler over
  all tool-call parts must be updated:

  // ❌ No longer compiles on a typed mixed union
  part.approval?.id
  
  // ✅ Narrow to an approval-required tool first
  if (part.name === 'deleteAccount') part.approval?.id
  
  // ✅ Or guard with `in`
  if ('approval' in part) part.approval?.id
  
  // ✅ Or type the handler against the base (untyped) ToolCallPart
  function handleApproval(part: ToolCallPart) {
    return part.approval?.id
  }

  Untyped useChat() (no inferred tools generic) and the base ToolCallPart
  type are unaffected: approval stays available on every tool-call part there.
  Runtime behavior is unchanged — only TypeScript narrowing is stricter.

  Adds a TNeedsApproval extends boolean type parameter (defaulting to false)
  to the client tool types; existing explicit type arguments keep working via the
  default. Literal capture requires toolDefinition({ needsApproval: true }) at
  the call site — a dynamic needsApproval: boolean variable will not gate the
  type.

• #918 f830d9e - Populate the parsed input on tool-call message parts. ToolCallPart already
  declared a typed input? field, but it was never written at runtime — only the
  raw arguments string (and output) were set, so part.input was always
  undefined and consumers had to fall back to part.input ?? JSON.parse(part.arguments).

  input is now set from the parsed arguments once they are complete
  (state: 'input-complete' and later, including approval-requested), in the
  streaming processor, the TOOL_CALL_END-with-parsed-input path, and when
  hydrating history via modelMessagesToUIMessages. While arguments are still
  streaming, input stays undefined and the raw arguments string remains the
  live source. A tool call that terminates in an error state may also keep input
  unset. arguments is unchanged, always present, and not deprecated.

  With typed tools (useChat({ tools })), part.input is fully typed per tool
  via the part.name discriminant — matching part.output.

Patch Changes

• #924 5fcaf90 - fix: resolve directory-barrel imports in published .d.ts files. Bare imports of utils/tools/middleware barrels were emitted as ../utils.js (etc.), which do not resolve under bundler/node16/nodenext (no /index fallback for explicit .js). With consumer skipLibCheck: true those symbols silently became any. Imports now target concrete modules (e.g. utils/client, middleware/types) or explicit /index paths so public types resolve correctly.

• #922 e0bbbdd - fix: resolve dangling relative imports in published declaration files

  Switch directory-barrel imports (../utils, ../tools, ../middleware) to
  concrete module paths so emitted .d.ts specifiers resolve under
  bundler/node16/nodenext resolution. Adds a test:dts scanner guardrail.

  Fixes #920

• #886 de5fbb5 - Fix generateVideo / getVideoJobStatus rejecting video adapters that declare a narrowed per-model duration union (e.g. Gemini's 4 | 6 | 8 for Veo or 10 for Omni Flash) at the type level. The activity's TAdapter extends VideoAdapter<string, any, any, any> constraints left the input-modality and duration generics at their defaults, so duration?: number failed contravariance against the adapter's literal union. All video-activity constraints and helper conditionals now span all six VideoAdapter generics.

Patch Changes

• #918 f830d9e - Add the const modifier to the TTools type parameter of useChat
  (createChat in Svelte, injectChat in Angular) so a plain inline tools array
  now yields full type-safe message chunks. Previously the array widened to
  Array<Union> and lost the literal tool names that drive the
  discriminated tool-call part union, so callers had to wrap their tools in
  clientTools(...) (or add as const) to get narrowing. That wrapper is now
  optional — tools: [toolA, toolB] narrows part.name, part.input, and
  part.output on its own. clientTools(...) still works and remains useful
  for defining a shared tuple outside the hook call.
• Updated dependencies [5fcaf90, 2665085, e0bbbdd, f830d9e, f830d9e, de5fbb5]:
  • @tanstack/ai@0.41.0
  • @tanstack/ai-client@0.21.0

Patch Changes

• Updated dependencies [f830d9e]:
  • @tanstack/ai-vue@0.14.4

Patch Changes

• #918 f830d9e - Add the const modifier to the TTools type parameter of useChat
  (createChat in Svelte, injectChat in Angular) so a plain inline tools array
  now yields full type-safe message chunks. Previously the array widened to
  Array<Union> and lost the literal tool names that drive the
  discriminated tool-call part union, so callers had to wrap their tools in
  clientTools(...) (or add as const) to get narrowing. That wrapper is now
  optional — tools: [toolA, toolB] narrows part.name, part.input, and
  part.output on its own. clientTools(...) still works and remains useful
  for defining a shared tuple outside the hook call.
• Updated dependencies [5fcaf90, 2665085, e0bbbdd, f830d9e, f830d9e, de5fbb5]:
  • @tanstack/ai@0.41.0
  • @tanstack/ai-client@0.21.0

Patch Changes

• #918 f830d9e - Add the const modifier to the TTools type parameter of useChat
  (createChat in Svelte, injectChat in Angular) so a plain inline tools array
  now yields full type-safe message chunks. Previously the array widened to
  Array<Union> and lost the literal tool names that drive the
  discriminated tool-call part union, so callers had to wrap their tools in
  clientTools(...) (or add as const) to get narrowing. That wrapper is now
  optional — tools: [toolA, toolB] narrows part.name, part.input, and
  part.output on its own. clientTools(...) still works and remains useful
  for defining a shared tuple outside the hook call.
• Updated dependencies [5fcaf90, 2665085, e0bbbdd, f830d9e, f830d9e, de5fbb5]:
  • @tanstack/ai@0.41.0
  • @tanstack/ai-client@0.21.0

Patch Changes

• Updated dependencies [2665085, f830d9e, f830d9e]:
  • @tanstack/ai-client@0.21.0
  • @tanstack/ai-solid@0.14.4