Add Azure OpenAI as a first-class LLM and embedding provider

[ShreeBohara]

Both factories advertised multi-provider support behind real ABCs (BaseLLM, BaseEmbeddings) but only ever constructed public-OpenAI clients. This adds azure_openai to each.

Approach

Target Azure's v1 OpenAI-compatible surface (<endpoint>/openai/v1) and reuse the standard AsyncOpenAI client rather than AsyncAzureOpenAI — the openai SDK's own README warns the Azure client's static types "can be incorrect". So the Azure branch is a different base_url and a deployment name, not a second client implementation.

azure_openai_base_url() normalises the endpoint idempotently: bare host, trailing slash, /openai, or an already-complete /openai/v1 all produce the same result.

The two divergences that would otherwise have been silent

/models returns 404 on some Azure configurations. There it enumerates deployments, and not every setup exposes it. health_check now treats 404 as reachable — the endpoint answered, so credentials and networking are fine — while still failing on 401/403 and on unexpected statuses. Without this, /api/health would report a perfectly working Azure deployment as degraded.

tiktoken cannot resolve an encoding from a deployment name. tokenizer_model is now passed separately. I want to be precise about this one rather than overclaim: the old bare except KeyError: cl100k_base was accidentally correct, because every current OpenAI embedding model resolves to cl100k_base anyway —

text-embedding-3-small  -> cl100k_base
text-embedding-3-large  -> cl100k_base
text-embedding-ada-002  -> cl100k_base
fallback used by old code -> cl100k_base

So this is a latent correctness fix plus a warning where there was silence, not a live bug fix. It would have mattered on an o200k_base embedding model or a non-OpenAI base_url.

Two fixes Azure made reachable

• openai_embedding_dimensions is configurable. It was hardcoded to 1536 while the model was configurable, so a text-embedding-3-large deployment (3072) only failed when Chroma rejected the insert.
• The unknown-provider branch now raises. It previously fell back to OpenAI whenever a key happened to be set, dropping all seven rate-limit/batching/pacing arguments — so a typo in EMBEDDING_PROVIDER silently produced a differently-behaving client with no error anywhere. llm/factory.py already raised; these now match.

Scope

api_key accepts str | Callable[[], str] so an Entra token provider can be passed without either class knowing how the credential is obtained. Nothing supplies one yet — auth is API-key only, and the docs say so. I'd rather ship that honestly than imply managed identity works.

Verification

Gate	Result
New unit tests	22 (URL normalisation, factory wiring, missing-config errors, tokenizer resolution, dimensions, all 5 health-check branches)
Full suite	111 passed, 0 failed (was 89)
ruff check src tests	clean
Azure from env alone	correct base_url, deployment-as-model, tokenizer, dimensions
Default OpenAI path	unchanged — api.openai.com/v1, gpt-4o, 1536
App import	41 routes

Config coverage checked programmatically — all six new variables exist in config.py, docker-compose.yml (55 forwarded) and .env.example.

Not verified: no calls were made against a real Azure resource. The wiring is asserted at construction, which is where the divergences live, but a live smoke test against an actual deployment is still worth doing before relying on it.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
codebaseqa-web	Ready	Preview	Aug 9, 2026 7:48pm