TanStack AI 1.0 stabilizes core APIs and ships an experimental harness

TanStack AI 1.0 draws a line between what app teams can treat as stable and what is still moving. Core APIs are stable and ready for production. The new agent harness is experimental, ships on 0.x, and can change in a minor release.

The project places 1.0 in October 2026. Less than a year earlier it was a chat() function, four providers, and a promise of no lock-in. The 1.0 post says that promise held: provider, framework, sandbox, and the wire protocol between them are still yours to pick. On October 23, 2026, the TanStack account described the addition as an agent harness that keeps its session between requests, takes new instructions while it works, and runs in a terminal, web app, or editor. The same post says the harness APIs are experimental.

What 1.0 commits to

1.0 is TanStack's formal commitment to the APIs you build on. The post also says 1.0 has no new concepts. Every API that 0.x marked deprecated was removed, and every replacement had already shipped in 0.x. An app that kept up with deprecation warnings is most of the way there.

The upgrade is joint, not piecemeal. A 1.0 client needs a 1.0 server, so stable @tanstack/ai* packages move at the same time. Experimental harness packages stay on 0.x. @tanstack/ai-harness and @tanstack/ai-harness-cli ship as 0.x. Harness entry points in other packages, including @tanstack/ai-skills/harness and @tanstack/ai-acp/agent, are experimental too. TanStack wanted the harness in people's hands before locking its APIs. It is separate from the stable 1.0 core.

The toolkit that became stable

The post's alpha-to-1.0 table is the inventory:

Provider adapters grew from 4 to 23, plus an openaiCompatible adapter for any OpenAI-style API.
UI coverage at alpha was React, Solid, and vanilla JS. The 1.0 column lists React, Vue, Solid, Svelte, Preact, Angular, Octane, Remix, and vanilla JS. The introduction counts eight UI frameworks beside the 23 provider adapters; the table is the fuller list, and it includes vanilla JS.
Coding-agent adapters went from none to Claude Code, Codex, OpenCode, Grok Build, and any ACP agent.
Sandbox providers went from none to 11.

More than 140 people helped build the toolkit. Later in the same post, TanStack thanks 143 people who contributed code, and notes that three maintainers still run the project. End-to-end tests run on every pull request, checking provider adapters and tool execution against deterministic model fixtures, without live API calls.

Since the August 2026 release candidate, stable additions include subagents in chat() and useChat, a typed decide() helper, portable Agent Skills, compaction for long chats, and computer use that runs the same code on OpenAI and Anthropic. Adapters named in that section include Cloudflare Workers AI and AI Gateway, Lovable AI Gateway, Azure OpenAI, World Labs Marble, TypeSafe, and Ollaya. Five new sandbox providers are listed there: Blaxel, Upstash Box, E2B, boxd, and Railway. Every hand-written docs page was rewritten for 1.0.

Upgrade rules, not a walkthrough

For most apps, TanStack says the move is one published jscodeshift codemod and a type check. The codemod covers common renames: body becomes forwardedProps, and conversationId becomes threadId.

threadId is now required in the browser and on the server. Neither side creates one. The codemod cannot add it, because it does not know your ids. addToolApprovalResponse() is gone; the replacement is to resolve the tool-approval interrupt. @tanstack/ai-react-ui, @tanstack/ai-solid-ui, and @tanstack/ai-vue-ui have no 1.0 releases and should be removed if you use them. A custom server that streams to a TanStack AI client should stop sending data: [DONE] and end the run with a RUN_FINISHED event.

A passing type check does not migrate stored chats, runs, or files. The post says to follow the saved-data steps in the upgrade guide before deploy.

An experimental session, not a finished runtime

chat() answers one request. TanStack's case for the harness is the workload that needs more: a coding agent, a support bot, or a media studio with one conversation that stays open, takes new messages while it works, runs other agents, and survives a deploy.

@tanstack/ai-harness is that layer. You define a harness once, with the same options as chat(), and open a session for each thread. session.send starts work, and the events on that plan are standard AG-UI events. A later session.send with mode set to steer joins the running turn before its next model call, or starts the next turn if the current one has already finished. A follow-up waits until the current work is done.

Resume across a restart is conditional. The post's example uses in-memory persistence and says a durable store is required to recover after a restart. With a store that survives restarts, every thread has a session log, a turn cut by a crash or a deploy continues on the next host, and one host owns a thread at a time. An approval, a question, or a sign-in can stop the run and wait in the log so any server can take the answer after a restart. Recovery is not complete. TanStack cites remaining limits, including in-memory child-agent waits that do not resume across hosts.

A session can also run typed agents from code, in parallel or in series, with budgets and timeouts, or let the model call them as tools. Plugins package tools, prompts, middleware, commands, and state. The same definition can run in a terminal, as a one-shot prompt for scripts and CI, over HTTP, as an ACP agent for editors, or as an MCP server. In a web app, useChat can speak AG-UI to a harness, including approvals and a page reload that joins the running turn.

The coding-agent plugins are a starting point, not a sealed runtime. TanStack says the permissions plugin is not a sandbox: those tools run on the host with its permissions. A harness can also hand coding work to Claude Code, Codex, Grok Build, or any ACP agent, each in its own sandbox.

What to read next

If you already run TanStack AI, read the upgrade section of the 1.0 post and move the stable packages together before you treat a type check as a migration. If you want the session behavior, start from the harness overview the post points to, keep those APIs marked experimental, and put a durable store behind any thread that has to survive a restart. The account asked people to try the harness. The blog asks them to report what breaks.