Skip to content

fix(google-vertex): allow 'vertex' as a key for providerOptions#10983

Merged
aayush-kapoor merged 14 commits intomainfrom
aayush/7783-bug
Dec 11, 2025
Merged

fix(google-vertex): allow 'vertex' as a key for providerOptions#10983
aayush-kapoor merged 14 commits intomainfrom
aayush/7783-bug

Conversation

@aayush-kapoor
Copy link
Copy Markdown
Collaborator

@aayush-kapoor aayush-kapoor commented Dec 8, 2025

Background

#7783

When providerOptions are defined in the vertex provider with the key vertex, they are ignored and not sent in the request to the model; they only work with google key.

Summary

Allow the vertex to be a valid key for setting providerOptions for vertex provider for consistency sake

Manual Verification

test cases added

Checklist

  • Tests have been added / updated (for bug fixes / features)
  • Documentation has been added / updated (for bug fixes / features)
  • A patch changeset for relevant packages has been added (for bug fixes / features - run pnpm changeset in the project root)

Future Work

Need to add codemods for the changes in the migration guide

Related Issues

Fixes #7783

@aayush-kapoor aayush-kapoor marked this pull request as ready for review December 8, 2025 18:24
@vercel-ai-sdk vercel-ai-sdk bot added ai/provider related to a provider package. Must be assigned together with at least one `provider/*` label bug Something isn't working as documented labels Dec 8, 2025
@lgrammel
Copy link
Copy Markdown
Collaborator

Please add to migration guide. Are any changes to the google vertex provider docs necessary?

@aayush-kapoor
Copy link
Copy Markdown
Collaborator Author

added a migration guide - will be adding codemods in a follow up PR once this lands

@aayush-kapoor aayush-kapoor merged commit ee8cd23 into main Dec 11, 2025
18 checks passed
@aayush-kapoor aayush-kapoor deleted the aayush/7783-bug branch December 11, 2025 18:29
aayush-kapoor added a commit that referenced this pull request Dec 11, 2025
…e-vertex (#11049)

## Background

Follow up to PR #10983 

## Summary

Added codemods for the breaking change highlighted in the migration
guide of the PR.

## Manual Verification

Tests and fixtures were added

## Checklist

- [x] Tests have been added / updated (for bug fixes / features)
- [x] Documentation has been added / updated (for bug fixes / features)
- [x] A _patch_ changeset for relevant packages has been added (for bug
fixes / features - run `pnpm changeset` in the project root)
lgrammel pushed a commit that referenced this pull request Jan 5, 2026
…11073)

## Background

When using Azure OpenAI reasoning models via the Responses API, the SDK
currently only handles reasoning parts when their `providerOptions` live
under the `openai` key. Azure Responses, however, expose reasoning parts
and `providerMetadata` under the `azure` namespace. This mismatch causes
the SDK to log a warning about "non-OpenAI reasoning parts" and drop
encrypted reasoning traces instead of passing them through to the
client. See #10917.

## Summary

This PR makes the Responses provider options handling in
`@ai-sdk/openai` configurable and switches Azure Responses to use
`providerOptions.azure` so that reasoning parts and `providerMetadata`
stay in sync.

Concretely:

- **OpenAI provider**
Extend the Responses input conversion so that the provider options key
(`openai`, `azure`, etc.) is configurable instead of being hard-coded to
`openai`.
Keep the existing OpenAI behavior unchanged by continuing to use the
`openai` key by default.

- **Azure provider**
Update the Azure Responses integration to use the `azure` provider key
when reading/writing Responses `providerOptions`.
However, to maintain backward compatibility, `providerOptions.openai`
remains available.
This makes Azure reasoning parts and `providerMetadata.azure` consistent
and prevents encrypted reasoning traces from being treated as
unsupported "non-OpenAI reasoning".

- **Docs & migration**
Update the Azure provider docs to explain that the Responses API now
available `providerOptions.azure` `providerOptions.openai` and returns
`providerMetadata.azure`.
Add a migration note to the 6.0 migration guide describing the change
from `openai` → `azure` for Azure Responses.
  - `content/providers/01-ai-sdk-providers/04-azure.mdx`
  - `content/docs/08-migration-guides/24-migration-guide-6-0.mdx`

- **Examples & tests**
- Add ai-core examples for `reasoning.encrypted_content` for both OpenAI
and Azure Responses.
- Update existing Azure examples to use `providerOptions.azure` for
Responses.
- Add fixtures and tests to cover Azure/OpenAI Responses with encrypted
reasoning, ensuring we don’t regress on this behavior.
-
`packages/azure/src/__fixtures__/azure-reasoning-encrypted-content.1.chunks.txt`
-
`packages/azure/src/__fixtures__/azure-reasoning-encrypted-content.1.json`
-
`packages/openai/src/responses/__fixtures__/openai-reasoning-encrypted-content.1.chunks.txt`
-
`packages/openai/src/responses/__fixtures__/openai-reasoning-encrypted-content.1.json`
  - add test case.
- `packages/openai/src/responses/convert-to-openai-responses-input.ts`
-
`packages/openai/src/responses/openai-responses-language-model.test.ts`

## Manual Verification

- new tests in `examples/ai-core`
  -  `pnpm tsx src/generate-text/azure-reasoning-encrypted-content.ts`
  -  `pnpm tsx src/generate-text/openai-reasoning-encrypted-content.ts`
- `pnpm tsx
src/generate-text/azure-provider-options-name-openai-compatible.ts`
  -  `pnpm tsx src/stream-text/azure-reasoning-encrypted-content.ts`
  -  `pnpm tsx src/stream-text/openai-reasoning-encrypted-content.ts`
- `pnpm tsx
src/stream-text/azure-provider-options-name-openai-compatible.ts`


- fix existing tests and re-try in `examples/ai-core`.
  -  `pnpm tsx src/generate-text/azure-image.ts `
  -  `pnpm tsx src/generate-text/azure-responses-reasoning-summary.ts`
  -  `pnpm tsx src/stream-text/azure-fullstream-logprobs.ts`
  -  `pnpm tsx src/stream-text/azure-responses-reasoning-summary.ts`

- fix existing tests and re-try in `examples/next-openai`.
- `pnpm run dev` &
`http://localhost:3000/test-azure-code-interpreter-annotation-download`
(fix
examples/next-openai/app/api/chat-azure-code-interpreter-annotation-download/route.ts)

## Related Issues

Fixes #10917.

Reference #10983.
fix(google-vertex): allow 'vertex' as a key for providerOptions

---------

Co-authored-by: tsuzaki430 <tsuzaki430@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai/provider related to a provider package. Must be assigned together with at least one `provider/*` label bug Something isn't working as documented

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unexpected behavior when passing providerOptions to vertex/google provider

2 participants