feat: migrate to Vercel AI SDK v6

[bjcoombs]

Problem

Task Master is currently on Vercel AI SDK v5 (ai@^5.0.51). The wider ecosystem, including all of the community CLI-backed provider SDKs this repo depends on (authored by @ben-vargas), has moved to AI SDK v6 as latest. The v5-compatible lines are frozen for bug-fix-only maintenance, with fixes for new model/routing issues landing on the v6 line only.

This creates two pressures:

1. New bugs in the v5-line providers will not be fixed upstream. Ben stated this explicitly on ben-vargas/ai-sdk-provider-opencode-sdk#21: "I'm not planning to put much (any?) effort into maintaining ai sdk v5 compatible providers given v6 is latest and v7 is in beta."
2. Known issues may already be fixed on v6 but inaccessible from v5. Candidates include bug: 301-Second Timeout on Large PRD Parsing (Client Disconnect) #1497 (301-second timeout on large PRD parsing) and the "terminated" / "Unexpected end of JSON input" failure modes documented in feat: add OpenCode as an AI provider #1685 for the OpenCode provider.

Technical Context

All four community CLI provider SDKs this repo depends on already publish a v6-compatible latest tag:

Package	v5 line (current)	v6 line (latest)
ai-sdk-provider-claude-code	2.2.4	3.4.4
ai-sdk-provider-codex-cli	0.7.0	1.1.0
ai-sdk-provider-gemini-cli	1.4.0	2.0.1
ai-sdk-provider-opencode-sdk	0.0.3	3.0.2

Zod is already at ^4.1.12, which satisfies every v6-line peer range.

The main-SDK surface to touch:

• ai@^5.0.51 → ai@^6.x
• 9x @ai-sdk/*@^2.x packages (anthropic, openai, google, groq, mistral, perplexity, xai, azure, openai-compatible) → their v6-compatible majors
• @ai-sdk/amazon-bedrock@^3.0.23 and @ai-sdk/google-vertex@^3.0.86 - verify v6 majors
• @ai-sdk/provider@^2.0.0 and @ai-sdk/provider-utils@^3.0.10 - bump to match

Impact

• Unblocks upstream bug fixes on all 4 community provider SDKs
• May resolve bug: 301-Second Timeout on Large PRD Parsing (Client Disconnect) #1497 (large-PRD timeout) and the reasoning-model timeouts documented in feat: add OpenCode as an AI provider #1685
• Keeps the codebase within the supported window (v7 is already in beta per Ben's comment)

Not covered by this work:

• The MCP sampling provider work being done in bug: AI SDK 5 only supports models that implement specification version "v2" #1449 (staying on v5 internally for spec v2 compliance - separate track)

Scope

In:

1. Bump ai to v6 and audit call-sites for v5→v6 breaking API changes (return-shape changes on generateText / streamText / generateObject, provider factory signatures, middleware changes)
2. Bump all @ai-sdk/* Vercel packages to v6-compatible majors
3. Bump Ben's 4 community provider SDKs to their latest (v6) tag
4. Update provider files in src/ai-providers/ that touch the changed APIs
5. Update tests and mocks affected by the SDK surface changes
6. Changeset (likely major bump given the dep churn)

Out:

• No behavioural changes beyond the minimum needed to keep existing flows green
• No new providers, no feature work
• No rewrite of the MCP sampling internal package (tracked in bug: AI SDK 5 only supports models that implement specification version "v2" #1449)

Success Criteria

1. ai@^6 and all compatible @ai-sdk/* / community providers installed
2. Full test suite passes
3. All 21 registered providers continue to work for generateText, streamText, generateObject
4. Live E2E sanity check against at least one Anthropic/OpenAI/Copilot/local model
5. Changeset entry

Ask

Would maintainers welcome a migration PR? If green-lit, I'll inventory the exact breaking API surface across the 13+ dep bumps, propose a sequenced plan before writing code, and keep the diff tight (dep bumps + the minimum call-site adjustments to keep the suite green).

Happy to land this after #1685 merges to avoid overlapping changes.

[bjcoombs]

The Vercel AI SDK has evolved from v5 to v6, with v6 representing a significant update that introduces breaking changes and shifts the development focus ¹ . While both versions aim to simplify AI integration, v6 offers enhanced features and a more unified approach ² .

Here's a comparison of key aspects:

• Unified API: Both v5 and v6 provide a unified API for integrating with various AI providers and language models ^{2 3} . This allows developers to build applications like chatbots and agents using frameworks such as Next.js, React, Svelte, Vue, and Node.js ^{2 4} .
• Features and Improvements in v6: Vercel AI SDK v6 focuses on unified model access, streaming APIs, caching, and observability ⁵ . It is designed to facilitate the creation of high-performance AI applications ⁵ .
• Migration and Support: The transition to v6 signifies that v5.x is no longer the priority for Vercel, with support shifting and new features exclusively targeting v6.0 ¹ . Migration guides are available for moving from v4 to v5 ⁶ , and v6 builds upon the foundation laid by previous versions.
• AI Gateway Compatibility: Vercel's AI Gateway, which offers features like budget setting, usage monitoring, load balancing, and fallback management, is compatible with both AI SDK v5 and v6 ⁷ .
• Core Components: The AI SDK Core provides a unified API for generating text, structured objects, tool calls, and building agents. Additionally, the AI SDK UI offers framework-agnostic hooks for building chat and generative user interfaces ⁸ .
• Previous Advancements: The migration from v4 to v5, for instance, was motivated by features like tool streaming, enabling users to see agent actions in real-time, and expanded provider options for caching ⁹ . V6 continues this trend of innovation.

Footnotes

1. Vercel AI SDK v6.0: What Changed and Why It Matters for Your Stack (20%) ↩ ↩²

2. AI SDK 6 - Vercel (23%) ↩ ↩² ↩³

3. AI SDK 5 - Vercel (< 1%) ↩

4. AI SDK - Vercel (< 1%) ↩

5. Mastering Vercel AI SDK v6: Building Smarter, Scalable AI Apps (13%) ↩ ↩²

6. Vercel AI SDK 5 Migration Guide 2026 — PkgPulse Blog (4%) ↩

7. AI Gateway - Vercel (12%) ↩

8. AI SDK by Vercel (15%) ↩

9. A lot of folks are starting to think about v6, but if you haven't migrated ... (13%) ↩

[bjcoombs]

The official migration guide for upgrading from Vercel AI SDK v5 to v6 is available on the Vercel AI SDK documentation website.

You can find the guide here: Migrate AI SDK 5.x to 6.0 ¹.

This guide provides a recommended process, including backing up your project, upgrading to AI SDK 6.0, and following the breaking changes ¹. The update introduces significant new features such as the v3 Language Model Specification, a new Agent abstraction, and a unified structured output API ².

Additional community migration reports, like one from Cloudflare, also confirm that the process should be straightforward for most users ³. The main documentation site for all migration guides is ai-sdk.dev/docs/migration-guides ⁴.

Footnotes

1. Migration Guides: Migrate AI SDK 5.x to 6.0 (38%) ↩ ↩²

2. 2026-02-19-vercel-ai-sdk-5-to-6-migration.md - GitHub (22%) ↩

3. agents/docs/migration-to-ai-sdk-v6.md at main · cloudflare/agents (20%) ↩

4. Migration Guides - ai-sdk.dev (20%) ↩

[bjcoombs]

Following the migration guide research you linked, the actual breaking-change surface for task-master is bigger than "bump deps". Documenting it here so the scope is realistic before anyone starts coding.

What changes in task-master code

1. Structured output API - the biggest change

generateObject and streamObject are deprecated in v6. Task Master uses generateObject heavily (PRD parsing, task expansion, complexity analysis, update-task, update-subtask, research mode, cluster generation). Every call-site migrates:

// v5
const { object } = await generateObject({
  model,
  schema: taskSchema,
  prompt: '...',
});

// v6
import { Output } from 'ai';
const { experimental_output } = await generateText({
  model,
  experimental_output: Output.object({ schema: taskSchema }),
  prompt: '...',
});

Call-sites to touch (rough grep): scripts/modules/task-manager/*.js, packages/tm-core/src/modules/ai/**, anywhere generateObject is imported from ai.

2. convertToModelMessages is async

Every call needs await added. CoreMessage → ModelMessage.

3. Tool definitions

• toModelOutput: (output) => ... → toModelOutput: ({ output }) => ...
• providerOptions.openai.strictJsonSchema → per-tool strict: true
• ToolCallOptions type → ToolExecutionOptions

4. Provider-specific defaults that can silently change behaviour

• OpenAI: strictJsonSchema now defaults true - may reject previously-accepted schemas
• Azure: azure('model') now routes to Responses API. Existing chat-completions usage needs azure.chat()
• Google Vertex: metadata key renames google → vertex

5. Usage token shape

• cachedInputTokens → inputTokenDetails.cacheReadTokens
• reasoningTokens → outputTokenDetails.reasoningTokens

Task Master surfaces usage in telemetry (the "Est. Cost" panel in CLI output). Those paths need updating.

6. Finish reason

• "unknown" → "other" on unknown finish. Any conditional on finishReason === "unknown" breaks silently.

7. Test mocks

• MockLanguageModelV2 / MockEmbeddingModelV2 → V3
• Every test that constructs a mock model gets touched. Task Master's AI provider tests all use these.

Revised effort estimate

Original issue suggested this could be done tight. After reading the migration guide and Cloudflare's report, a realistic estimate is more like:

• Dep bumps + provider-SDK version bumps: 3 points
• generateObject → generateText + Output.object migration across all call-sites: 8 points
• convertToModelMessages async propagation: 3 points
• Tool definition updates: 3 points
• Usage shape updates in telemetry: 3 points
• Provider-specific default audits (OpenAI strict, Azure route, Vertex metadata): 3 points
• Test-mock rewrites (V2 → V3): 5 points
• Full suite + E2E regression pass: 3 points

~30 points total.

Suggested sequencing

Given the scope, a single PR is likely too large to review. Proposed split if this gets greenlit:

1. Provider SDK bumps only - Ben's 4 community providers to v6 line, verify imports still resolve (safe, small)
2. generateObject → Output.object migration - biggest behavioural surface, own PR for clear review
3. convertToModelMessages async + tool definition updates
4. Provider-specific default audit + usage-shape updates + test-mock V3

PRs 2-4 could happen behind a feature flag / branch-stacked on top of 1.

Ask (updated)

Given the real scope, two questions for maintainers before any code:

1. Is the team aligned that v6 is worth the migration cost right now? (v7 is in beta, so there's a "wait for v7?" case to consider)
2. If yes, is the 4-PR split above reasonable, or would a single migration branch be preferred?