AI SDK compatibility inventory

[dremnik]

AI SDK compatibility inventory (for @kernl-sdk/ai)

• Supported / intended (today): AI SDK “v3 beta” line

  • Must have: @ai-sdk/provider@3.0.0-beta.* (this is what @kernl-sdk/ai peers on)
  • Use with: @ai-sdk/openai@3.0.0-beta.*, @ai-sdk/anthropic@3.0.0-beta.*, etc.
  • Zod: those v3 beta provider packages accept zod ^3.25.76 || ^4.1.8 → Zod v4 is fine

• Not supported: AI SDK “v1” line (e.g. @ai-sdk/openai@1.x, @ai-sdk/anthropic@1.x)

  • These depend on @ai-sdk/provider@1.1.3 and peer zod@^3.0.0
  • Failure modes:
    • Install: peer warnings/errors (Zod v3 vs v4)
    • TypeScript: huge duplicated type graphs when v1 + v3 beta coexist → tsserver hangs / TS2589 / tsc OOM
    • Runtime: adapter expects v3-shape prompts/streams/tools; v1 providers can mismatch

• Not supported (today): AI SDK “v2” line (@ai-sdk/provider@2.x + provider packages @ai-sdk/*@2.x)

  • Our adapter code is explicitly written against LanguageModelV3* message/stream/tool types and conversions, so v2 won’t line up cleanly.
  • Failure modes: peer conflicts (provider major), TS errors/instability, runtime shape mismatches.

Could we support both v2 and v3 in one adapter?

• At runtime: yes in principle (branch on model.specificationVersion and implement two conversion pipelines: v2 + v3).
• In practice (types + packaging): it’s messy to do in a single TS surface area because importing v3 types breaks v2 installs and vice‑versa. The clean approach is separate adapters/entrypoints (e.g. @kernl-sdk/ai/v2/* and @kernl-sdk/ai/v3/*, or separate packages) so users pick one AI SDK major line and don’t accidentally mix them.

[404UID4]

This project is amazing!

Please consider adjusting this project's philopolicy to fully deprecate support for outdated dependency versions (whether it's AI SDK v_, Zod v_, etc...), the cons outweigh the pros.
Typically, introducing backwards compatibility is unintentional poison to the project's longevity (due to maintainability aspects like cleanliness, simplicity, and readability/interpretability w/o docs)

@dremnik

[dremnik]

Did you have experience with previous projects where this didn't work well? What was the result?