TanStack AI 1.0 reaches stable release

• TanStack AI’s core APIs are stable at 1.0, covering chat, voice, image generation and tools, according to TanStack’s announcement.
• Persistent agent sessions remain experimental: TanStack’s harness announcement describes sessions that survive between requests and accept instructions while working.
• Stable packages require coordinated upgrades, while harness packages stay on 0.x, as TanStack’s upgrade notice explains.

The migration guide makes threadId mandatory even for image-generation calls. The coding-agent recipe wires up /undo and /compact, while the launch post specifies exactly when a mid-run instruction reaches the model.

TanStack AI now has 23 provider adapters plus an OpenAI-compatible adapter, and 11 sandbox providers. TanStack groups the additions since its August release candidate into six areas in its release rundown:

• Agents: named, typed subagents in chat() and useChat; typed decisions through decide(); portable SKILL.md skills; context compaction; computer use across OpenAI and Anthropic.
• Models: model-typed reasoning, automatic prompt caching, rate-limit retries, cross-model conversation replay and a unified provider Files API.
• Authentication: defineByok, keyed adapters, sign-in through ChatGPT, GitHub Copilot or OpenRouter, and Claude OAuth tokens.
• MCP: createMCPServer, client-side tool filters and approvals, task-based tools, and bidirectional WebMCP.
• Integrations: new provider adapters, Remix 3 support, Svelte devtools and five additional sandbox providers.
• Building and testing: typed headless chat UI factories, offline fakeText() fixtures and coding-assistant skills matched to the installed version.

The client uses AG-UI requests and events, allowing the same frontend to connect to a compatible Python, Go or PHP backend.

The experimental @tanstack/ai-harness adds defineHarness(), createHarnessHost() and a session opened for each threadId. Its events use standard AG-UI.

The launch post describes six session capabilities:

1. Durable sessions: a per-thread log and restart recovery with a durable store; one host owns a thread at a time.
2. Durable waits: approvals, questions and sign-in requests remain in the log, with answers accepted by another server after a restart.
3. Typed agents: serial or parallel execution with budgets and timeouts, callable from code or as model tools.
4. Plugins: reusable bundles of tools, prompts, middleware, commands and state.
5. Multiple users: access rules, shared threads and per-user provider credentials through /connect.
6. Background work: schedules, server-originated inputs and tools that wait for hours.

A session.send(message, { mode: 'steer' }) joins the running turn before its next model call. If that turn has finished, it starts another; a follow-up waits for current work to finish.

The example’s memoryPersistence() does not survive a restart. Recovery also has limits: in-memory child-agent waits do not resume across hosts.

@tanstack/ai-harness, @tanstack/ai-harness-cli and harness entry points in other packages remain experimental and can change in minor releases.

Release coauthor Alem Tuzlak described v1 as almost a year of work, following his prelaunch joke about understanding Frankenstein.

The coding-agent recipe combines first-party plugins for:

• File and command execution through workspaceTools().
• Approval controls through permissions().
• Turn snapshots and /undo.
• Todo tracking and project instructions.
• Context compaction and usage reporting through /compact and /usage.

One harness definition runs through runCli() on five surfaces:

• Terminal: interactive chat.
• Scripts and CI: -p "Fix the failing test".
• HTTP: --serve exposes the session protocol.
• Editors: --acp exposes an ACP agent.
• MCP hosts: --mcp exposes an MCP server.

For web apps, createHarnessHandler serves HTTP sessions and handleHarnessSocket serves WebSockets. useChat can reconnect after a page reload and join the running turn.

The migration’s sharpest edge is saved state: passing a type check does not make old records readable. The upgrade guide separates source changes from stored-data changes.

Source and protocol changes

• A 1.0 client requires a 1.0 server. Stable packages move together; experimental harness packages remain on 0.x.
• Chat-level body becomes forwardedProps; conversationId becomes threadId. The codemod handles common renames but cannot supply application-specific IDs or follow barrel-file re-exports.
• threadId is required on both client and server, including generation APIs. Neither side generates it automatically.
• addToolApprovalResponse() is removed. Approval now resolves through the bound interrupt’s resolveInterrupt() method.
• Custom streaming servers end runs with RUN_FINISHED; the client rejects the old data: [DONE] line.
• ai-react-ui, ai-solid-ui and ai-vue-ui have no 1.0 release. Their replacements use createChatHook from the corresponding framework package’s /ui entry point.

Saved-data changes

• Old Cloudflare sandbox run-log records are no longer readable.
• Pending interrupts saved before interrupt bindings existed cannot resume.
• Artifact records require blobKey to load.
• Client persistence returns { messages, resume? }; a bare UIMessage[] no longer loads.

The @tanstack/ai-sandbox harness tool bridge and executeHostTool() now refuse tools marked needsApproval, according to the official release notes. Previously, those paths executed the tools without approval. The notes identify an HTTP adapter as the supported execution path for approval-required tools.

The coding-agent permissions plugin supplies approval controls, but tools still execute on the host with its permissions. TanStack explicitly warns that the plugin provides no sandbox isolation.