Skip to content

docs: @ai-sdk/openai does read OPENAI_BASE_URL, so the Vercel AI SDK and Mastra sections state the opposite of the measured behaviour #80

Description

@xizhuomengcontin

What the docs say

docs/integrations.md, "Vercel AI SDK, and anything with its origin compiled in":

@ai-sdk/openai takes its origin as a constructor argument and reads nothing from the environment. The node adapter installs a preload through NODE_OPTIONS that redirects at globalThis.fetch — the one place every JS client agrees on.

The Mastra section inherits the same claim ("the origin is a constructor argument and the environment is not consulted"), and the README support table repeats it for both rows.

What I measured

@ai-sdk/openai 3.0.112 reads OPENAI_BASE_URL. Three construction paths, OPENAI_API_BASE unset, OPENAI_BASE_URL=http://127.0.0.1:9/v1, each probed by letting the request fail and reading the URL it tried:

createOpenAI({apiKey})  -> tried: http://127.0.0.1:9/v1/responses
bare openai provider    -> tried: http://127.0.0.1:9/v1/responses
explicit baseURL arg    -> tried: http://127.0.0.1:11/v1/responses

So: the environment is consulted, and an explicit baseURL argument wins over it — the ordinary precedence, not "nothing from the environment".

Why it matters

Three places are affected, and the error runs in the direction of making orca look more necessary than it is:

  1. docs/integrations.md § Vercel AI SDK — the premise of the section.
  2. docs/integrations.md § Mastra — "inherits that provider's behaviour exactly" is still true, but the behaviour it inherits is the opposite of what is written.
  3. README support table — both rows point at orca record node -- and the fetch preload as the route. If OPENAI_BASE_URL works, orca record generic-openai -- is the simpler route for these two, and the preload is the fallback rather than the requirement.

The hardcoded_origin.mjs check is unaffected — an origin compiled into source genuinely does read nothing, and the preload is the right answer there. It is the attribution of that property to @ai-sdk/openai that looks wrong.

Possible explanations, in order of likelihood

  • The SDK changed. @ai-sdk/openai 3.x may have added the env fallback after the check was written. If so the fix is a version note plus updating the route, not a retraction.
  • The check measures something narrower than the doc claims. mastra_agent.mjs and the Vercel check both pass under the preload, which they would whether or not the env var also works — a preload that redirects fetch catches the request regardless of how the URL was resolved. So a green check does not discriminate between the two explanations.

Worth adding a check that pins the actual behaviour: set OPENAI_BASE_URL with no preload and assert the request lands on the stub. That is the assertion that would have caught this, and it would catch a future regression in either direction.

Environment

@ai-sdk/openai 3.0.112, Node 22.23.2, Windows. No preload, no proxy — just the provider and a dead port to read the URL off the error.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions