chore(deps): bump @ai-sdk/openai from 3.0.90 to 4.0.25

[dependabot]

Bumps @ai-sdk/openai from 3.0.90 to 4.0.25.

Release notes

Sourced from @​ai-sdk/openai's releases.

@​ai-sdk/xai@​4.0.25

Patch Changes

• 93b2acd: chore: centralize response metadata conversion
• Updated dependencies [5fc7da5]
• Updated dependencies [93b2acd]
  • @​ai-sdk/provider-utils@​5.0.18
  • @​ai-sdk/openai-compatible@​3.0.20

@​ai-sdk/xai@​4.0.24

Patch Changes

• Updated dependencies [fa95504]
  • @​ai-sdk/provider-utils@​5.0.17
  • @​ai-sdk/openai-compatible@​3.0.19

@​ai-sdk/react@​3.0.242

Patch Changes

• ai@6.0.240

@​ai-sdk/vue@​3.0.240

Patch Changes

• ai@6.0.240

@​ai-sdk/vue@​3.0.239

Patch Changes

• ai@6.0.239

@​ai-sdk/svelte@​3.0.225

Patch Changes

• ai@5.0.225

@​ai-sdk/svelte@​3.0.224

Patch Changes

• ai@5.0.224

@​ai-sdk/gateway@​3.0.162

Patch Changes

• b28367e: feat(provider/gateway): add has provider option for model capability filtering, supporting 'implicit-caching' and 'vision' (image input)

Changelog

Sourced from @​ai-sdk/openai's changelog.

4.0.25

Patch Changes

• beaecb3: fix(provider/openai): resolve responses doStream at response.in_progress instead of first output token

  The early-stream-error peek treated response.in_progress as an unknown chunk, so doStream did not resolve until the first output item arrived — delaying stream availability (and downstream TTFB for proxies/gateways) by the model's full time-to-first-token. response.in_progress is now modeled in the chunk schema and marks the request as accepted: the peek keeps watching for error frames for a short grace window (50ms) so quota/rate-limit errors flushed alongside response.in_progress still throw as retryable APICallErrors, while healthy streams become available right after upstream acknowledges the request.

• b192878: feat: add experimental_toolCaller routing to generateText for code mode

• Updated dependencies [d8210b6]

• Updated dependencies [b192878]

  • @​ai-sdk/provider-utils@​5.0.16

4.0.24

Patch Changes

• Updated dependencies [1659cd5]
• Updated dependencies [6a5bdff]
  • @​ai-sdk/provider-utils@​5.0.15

4.0.23

Patch Changes

• 96a237d: Add blocked domain filters to the OpenAI and Azure Responses API web search tools.

4.0.22

Patch Changes

• c49380c: feat: add experimental streaming speech translation models (openai.translation('gpt-realtime-translate') over the OpenAI Realtime translations WebSocket and google.translation('gemini-3.5-live-translate-preview') over the Gemini Live API). connectToWebSocket in @ai-sdk/provider-utils now passes close code and reason to onClose (additive, optional parameter).
• Updated dependencies [0c464d9]
• Updated dependencies [c49380c]
  • @​ai-sdk/provider-utils@​5.0.14

4.0.21

Patch Changes

• Updated dependencies [1e2f324]
  • @​ai-sdk/provider@​4.0.4
  • @​ai-sdk/provider-utils@​5.0.13

4.0.20

Patch Changes

• 1f6dd3a: Add OpenAI Responses Programmatic Tool Calling with hosted program tools, function caller controls, structured output schemas, and multi-step continuation support.

... (truncated)

Commits

• eb3d1af Version Packages (#18208)
• b192878 feat: add experimental_toolCaller routing to generateText for code mode (#18219)
• beaecb3 fix(provider/openai): resolve responses doStream at response.in_progress inst...
• a56fbc0 Version Packages (#18083)
• 2ab3f34 Version Packages (#18023)
• 96a237d feat: support blocked domains in OpenAI web search (#18033)
• 232a45a Version Packages (#18004)
• c49380c feat(openai,google): realtime translation providers (#17543)
• 8fd84f0 Version Packages (#17983)
• 3c98985 Version Packages (#17868)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2f6246b906

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Commit the matching Bun lockfile

This manifest bump leaves bun.lock pinned to @ai-sdk/openai ~3.0.74 / 3.0.74 (bun.lock:11, bun.lock:240). The repo's CI and Docker build install with bun install --frozen-lockfile (for example .github/workflows/ci.yml:36-37 and Dockerfile:15-21), so those installs cannot update the lockfile to satisfy this changed range and will fail before lint/build/deploy. Please regenerate and commit bun.lock with the dependency bump.

Useful? React with 👍 / 👎.

[krishagel]

🤖 pr-fix routine: blocked — same bun.lock root cause as #1575

The 4 failing checks

Test, Lint, and Type Check, Validate CDK Infrastructure, Auth Edge Production Artifact, and Unified Content PostgreSQL Lifecycle all die within ~12s at the identical step:

bun install --frozen-lockfile
error: lockfile had changes, but lockfile is frozen
note: try re-running without --frozen-lockfile and commit the updated lockfile

This PR changes exactly one line of package.json (@ai-sdk/openai ~3.0.74 → ~4.0.25) and nothing else — bun.lock was not regenerated. Nothing about the four failures is specific to this dependency; they are a lockfile-drift signature.

Why this routine still can't fix it (re-verified this fire)

The fix is mechanical — bun install, commit bun.lock — but remains impossible from the routine sandbox. Re-checked just now rather than assumed:

• registry.npmjs.org returns 403 for every request, metadata and tarballs alike, both direct and forced through the agent proxy. The proxy README classifies this as an organization egress-policy denial and directs that it be reported, not routed around — so no mirror workaround.
• The local Bun cache is empty (0 entries) and there is no node_modules, so nothing can be resolved offline either.

Regenerating the lockfile would require fabricating integrity hashes, which I won't do.

Scope — this is a backlog, not one PR

Every currently-open Dependabot PR that touches the root package.json carries this same failure: #1568, #1569, #1570, #1571, #1572, #1573, #1574, plus #1575 and #1576 already marked stuck. That's 9 PRs blocked on one mechanical step.

PRs scoped to /infra (#1566, #1567) and to .github/workflows (#1562, #1564) are unaffected, because they never touch the root lockfile.

What a human needs to do

• Per PR (works today): check out the branch, run bun install, commit and push the updated bun.lock.
• Systemic (recommended, clears all 9): have CI regenerate and commit bun.lock on Dependabot branches, or relax --frozen-lockfile for Dependabot-authored branches. ⚠️ Both live under .github/workflows/**, which this routine is forbidden from editing — autonomous runs cannot approve workflow-file changes.

Separate concern once the lockfile is valid

@ai-sdk/openai 3.0.90 → 4.0.25 is a major bump and the repo is on ai@6.0.240, with #1570 separately proposing ai 6 → 7. Green CI here should not be read as an automatic merge signal; this wants a compatibility review sequenced against #1570.

The routine will not pick this PR up again until someone removes the pr-fix-stuck label.

---

Generated by Claude Code