fix(adapters): route azure-foundry through apiBase without /openai/deployments/{deployment} (#13114) - #13161
Open
santhiprakash wants to merge 3 commits into
Open
Conversation
…ate (continuedev#13104) calculateOpenAICost() previously billed every prompt token at the standard input rate, ignoring usage.promptTokensDetails.cached_tokens. For OpenAI requests that hit the prompt cache (gpt-4o / gpt-4o-mini with stable system prompts), this over-reported costs by the cache-read discount. Add cachedInput to the pricing table for the families that document a cache rate (gpt-4o, gpt-4o-mini), split prompt tokens into uncached and cached portions, and bill each at its own rate. Models without a documented cachedInput rate keep their existing behavior — cachedTokens is ignored and the full prompt is billed at the standard input rate. Includes regression tests covering: gpt-4o with partial cache, fully cached input, zero cached tokens, gpt-4o-mini, gpt-4 (no rate defined), and clamping cachedTokens when the API reports more cached than total prompt tokens. Verified by extracting calculateOpenAICost into a standalone Node script and running 11 cases against hand-computed expected costs (all pass).
…nuedev#13104) Fix the prettier-check failure on PR continuedev#13160 introduced by the previous commit's hand-formatted long lines.
…ployments/{deployment} (continuedev#13114)
AzureApi._getAzureBaseURL previously forced every 'provider: azure' request
through the legacy Azure OpenAI Service URL shape
(/openai/deployments/{deployment}?api-version=...). That 404s on Azure AI
Foundry (a.k.a. Microsoft Foundry) endpoints, which expose an OpenAI-
compatible /openai/v1 path supplied by the user in apiBase.
Add an apiType === 'azure-foundry' branch that returns the apiBase as-is,
and skip the deployment/apiVersion guards for it. The existing
'azure-openai' / 'azure' branches keep their existing behavior, including
the deployment/apiVersion requirements.
Adds 2 regression tests in main.test.ts:
- foundry apiBase round-trips without path manipulation
- foundry construction does not throw without env.deployment / env.apiVersion
Verified by extracting _getAzureBaseURL into a standalone Node script and
running 6 cases (3 legacy azure-openai + 3 foundry) against hand-computed
expected baseURLs (all pass).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
AzureApi._getAzureBaseURLpreviously forced everyprovider: azurerequest through the legacy Azure OpenAI Service URL shape (/openai/deployments/{deployment}?api-version=...) regardless ofenv.apiType. That 404s on Azure AI Foundry (a.k.a. Microsoft Foundry) endpoints, which expose an OpenAI-compatible/openai/v1path supplied by the user inapiBase.The
AzureConfigSchemainpackages/openai-adapters/src/types.tsalready declaresapiType: "azure-foundry"as a valid value, but theAzureApiimplementation never branched for it. This PR adds the branch:env.apiType === "azure-foundry", return theapiBase(with trailing slash trimmed, search params extracted intodefaultQuery) without appending/openai/deployments/{deployment}.env.deployment/env.apiVersionrequirements for foundry (those are Azure OpenAI Service-only).azure-openai/azurepaths keep their existing behavior.Reproduction (from the issue)
Before:
AzureApirewritesapiBasetohttps://<your-resource>.services.ai.azure.com/openai/v1/openai/deployments/<deployment>and the Foundry endpoint returns 404.After:
apiBaseis used as-is; the request reaches the Foundry OpenAI-compatible routing path.Tests
Added 2 regression tests in
packages/openai-adapters/src/test/main.test.ts:should configure Azure AI Foundry client without appending /openai/deployments/{deployment}— verifies thebaseURLis the user-suppliedapiBase.should not require env.deployment or env.apiVersion for Azure AI Foundry— verifies nodeployment/apiVersionis required forapiType: "azure-foundry".The fix was verified by extracting
_getAzureBaseURLinto a standalone Node script and running 6 cases (3 legacyazure-openai+ 3 foundry) against hand-computed expected baseURLs (all pass). I could not run the vitest suite in this environment (nonode_modulesat the workspace root); the upstream vitest suite should be re-run by the maintainer.Checklist
I have read the CLA Document and I hereby sign the CLA
🤖 Generated with Hermes Agent