Skip to content

Make reasoning / thinking configuration part of top-level spec #12516

@felixarntz

Description

@felixarntz

Description

So far, we're handling all reasoning / thinking configuration via providerOptions. While this has historically made sense, over time many providers have adopted this, often in somewhat similar ways. We should consider making it part of the top-level spec.

Questions to discuss and answer:

  1. Which naming convention do we align with for our abstraction? "reasoning" or "thinking"?
  2. Which config parameters do we allow controlling, and how?
  3. How do we map our abstraction config to the individual provider requirements around this?

A good starting point is to review providers with support on how they handle these aspects. From there, we can converge towards a reasonable abstraction.

AI SDK Version

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Metadata

Metadata

Assignees

Labels

ai/corecore functions like generateText, streamText, etc. Provider utils, and provider spec.ai/providerrelated to a provider package. Must be assigned together with at least one `provider/*` labelfeatureNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions