Sending x-api-key instead of api-key as header for azure hosted anthropic service

[sresam89]

Sending x-api-key instead of api-key as header for azure hosted anthropic service

Description

Sending x-api-key instead of api-key as header for azure hosted anthropic service

C:/continue/packages/openai-adapters/src/apis/AnthropicUtils.ts
 const authHeaderName = isAzure && apiBase?.includes("cognitiveservices.azure.com")  ? "api-key"  : "x-api-key"; 

AI Code Review

• Team members only: AI review runs automatically when PR is opened or marked ready for review
• Team members can also trigger a review by commenting @continue-review

Checklist

• [yes] I've read the contributing guide

• [yes] The relevant docs, if any, have been updated or created

• [yes] The relevant tests, if any, have been updated or created

Screen recording or screenshot

Tests

compiled the plugin and ran the changes using android studio

---

Summary by cubic

Send x-api-key by default for Azure-hosted Anthropic; use api-key only when apiBase contains cognitiveservices.azure.com (case-insensitive) to prevent auth failures on newer Azure deployments.

• Bug Fixes
  • Case-insensitive domain check via apiBase?.toLowerCase().includes("cognitiveservices.azure.com") to choose between api-key and x-api-key.

^{Written for commit 9178f87. Summary will update on new commits.}

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/openai-adapters/src/apis/AnthropicUtils.ts">

<violation number="1" location="packages/openai-adapters/src/apis/AnthropicUtils.ts:82">
P2: Case-sensitive `apiBase.includes` check can cause Azure Cognitive Services URLs with mixed-case hostnames to fall back to `x-api-key`, despite `isAzure` being true, leading to incorrect auth header selection.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[sresam89]

I have read the CLA Document and I hereby sign the CLA

[sresam89]

@sestinj awaiting your inputs

[RomneyDa]

@sresam89 is there a more deterministic way to check if it's an anthropic endpoint? Right now anything not cognitive... will now do x-api-key, which might break other azure endpoints. Any way to specifically set x-api-key if anthropic?

[sresam89]

@sresam89 is there a more deterministic way to check if it's an anthropic endpoint? Right now anything not cognitive... will now do x-api-key, which might break other azure endpoints. Any way to specifically set x-api-key if anthropic?

this change is focused only on anthropic end points, when the provider selection is anthropic, does not affect other providers, to the extent of my testing knowledge
The cognitive check was to provide backward compatibility since it was the only publicly documented anthropic endpoint still accepting api-key instead of x-api-key header, newer endpoints (self hosted or anthropic supported) are likely supporting/accepting only x-api-key over api-key header.
open to change it otherwise, with findings other contributors have

[RomneyDa]

Ah that makes sense, I somehow missed that this is within AnthropicUtils.

[sresam89]

@sestinj awaiting for your review

[sresam89]

Ah that makes sense, I somehow missed that this is within AnthropicUtils.

Thanks for your approval