@ai-sdk/togetherai 3.0.87: Model Catalog Refactor

In Vercel's AI SDK ecosystem, @ai-sdk/togetherai is the official provider package for connecting to Together AI's inference services. Version 3.0.87 appears on the surface to be just a dependency sync, but the actual changes center on how model ID logic is organized—consolidating scattered model identifiers into a declarative model catalog.

A Structural Adjustment Hidden in a Patch Release

This version number is at the patch level, which by semantic versioning convention should not introduce behavioral changes. The release notes also explicitly state "Request behavior is unchanged."

The change itself refactors Together AI's model ID logic into a model catalog, where the catalog uniformly declares each model's capabilities and provider options, and provider capability documentation is automatically generated from the catalog.

For users, the model IDs called after upgrading, the way parameters are passed, and the response structure will not change. The changes occur in the package's internal organization and documentation generation workflow.

Semantic Versioning (SemVer) is the versioning convention commonly used in the npm ecosystem, with the format MAJOR.MINOR.PATCH. An increment in the patch number (PATCH) indicates only backward-compatible bug fixes or internal adjustments, and should not introduce behavioral changes; an increment in the minor version (MINOR) indicates new backward-compatible functionality; an increment in the major version (MAJOR) indicates incompatible API changes. Therefore, the "Request behavior is unchanged" note in the release notes is a clear confirmation of the SemVer contract—package users can automatically upgrade within ranges like ^3.0.87 without worrying about breaking their calling code. Understanding this makes it clear why a structural internal refactor would be released as a patch version: the refactor did not change externally observable behavior, only reorganized the package's internal implementation.

What Problem Does the Model Catalog Solve

The long-standing pain point for multi-model provider packages is the fragmentation of model metadata. Which models support tool calling, which support structured output, how large the context window is, what provider-specific parameters exist—this kind of information was often scattered across conditional branches, hardcoded lists, and hand-written documentation.

The model catalog separates "what a model is" from "how to call a model." The catalog is responsible for declaring capabilities and options, the calling logic reads from the catalog, and documentation is generated from the same data. The benefit is that the three cannot drift apart: the supported capabilities written in the documentation are the same declarations read by the code at execution time.

This pattern has precedent in other AI SDK providers. Aligning Together AI to the same structure means lower cross-provider maintenance costs—adding a new model only requires adding one declaration to the catalog.

Declarative and imperative are two opposing organizational paradigms. The imperative approach uses conditional branches and procedural code to describe "how to do it" step by step: for example, if (model === 'x') return { tools: true }. The declarative approach uses data structures to directly describe "what it is": a model table lists each model's capability fields, and generic logic reads from this table. The advantage of declarative is the decoupling of data and logic—adding a new model only changes data, not code; capability information can be shared by multiple consumers such as calling logic, documentation generation, and validators, avoiding drift caused by the same fact being duplicated in multiple places. The model catalog is precisely the convergence of the fact "model ID and its capabilities" into a single source of truth, which is the fundamental reason it is easier to maintain than scattered hardcoded lists.

The Significance of Auto-Generated Capability Documentation

The release notes specifically mention "generate provider capability documentation from it." Documentation is generated from a code data source rather than maintained manually, which directly eliminates a common class of problems: a model gains support for a new capability but the documentation doesn't keep up; or a model is discontinued but the documentation still lists it.

For developers, this means the capability matrix seen when consulting documentation is more trustworthy. For provider maintainers, it reduces the burden of keeping a separate document in sync.

Dependency Sync and Upgrade Recommendations

This release also updates dependencies, including @ai-sdk/openai-compatible@3.0.86. The Together AI provider is built on the OpenAI-compatible layer, and aligning this dependency's version is routine maintenance.

Since request behavior is unchanged, upgrade risk is very low. If your project pins the provider version, you can handle it according to the normal patch upgrade cadence. If you are maintaining your own model capability lists or documentation, this refactor provides a reference sample: extract model metadata into a declarative catalog so that code and documentation share the same data source.

It's worth noting that the introduction of a model catalog is usually followed by feature expansion in subsequent versions—once capability declarations are centralized, features like filtering models by capability and dynamically validating parameters have a foundation to build on. This patch version itself doesn't include these features, but the structural preparation is complete.

One-line Summary

AI SDK's Together AI provider patch refactors model ID logic into a declarative model catalog, with request behavior unchanged.

Paragraph Summary

In the Vercel AI SDK ecosystem, the @ai-sdk/togetherai package has released patch version 3.0.87. The version number is at the patch level and request behavior is unchanged; the substantive changes center on internal structure: consolidating previously scattered model ID logic into a unified declarative model catalog, where the catalog centrally declares each model's capabilities and provider options, and provider capability documentation is automatically generated from the same data. This adjustment solves the problem of fragmented model metadata in multi-model provider packages and the tendency for documentation to become disconnected from code, aligns with the structure of other AI SDK providers, and lowers cross-provider maintenance costs. The version also syncs dependencies including @ai-sdk/openai-compatible@3.0.86. Upgrade risk is very low, and the centralized capability declarations also lay the groundwork for future features such as filtering models by capability and dynamically validating parameters.