OPENAI_EMBEDDING_API_KEY

[clzwqoii]

Issue draft
Title:

OPENAI_EMBEDDING_API_KEY is ignored when EMBEDDING_PROVIDER=openai and OPENAI_API_KEY is set

Body:

Summary

When EMBEDDING_PROVIDER=openai is used with both:

• OPENAI_API_KEY for an OpenAI-compatible chat provider
• OPENAI_EMBEDDING_API_KEY / OPENAI_EMBEDDING_BASE_URL for a separate local OpenAI-compatible embedding endpoint

the embedding provider still uses OPENAI_API_KEY, not OPENAI_EMBEDDING_API_KEY.

This makes it impossible to use a hosted OpenAI-compatible LLM while routing embeddings to a separate local endpoint such as LM Studio, even though OpenAIEmbeddingProvider documents and implements embedding-specific env vars.

Reproduction

Example config:

# Hosted OpenAI-compatible chat provider
OPENAI_API_KEY=hosted-chat-key
OPENAI_BASE_URL=https://example-chat-provider/v1
OPENAI_MODEL=some-chat-model

# Local OpenAI-compatible embedding provider
EMBEDDING_PROVIDER=openai
OPENAI_EMBEDDING_API_KEY=local-embedding-key
OPENAI_EMBEDDING_BASE_URL=http://127.0.0.1:1234/v1
OPENAI_EMBEDDING_MODEL=text-embedding-bge-m3
OPENAI_EMBEDDING_DIMENSIONS=1024
With this configuration, agentmemory sends hosted-chat-key to the local embedding endpoint. LM Studio rejects it with an invalid token error.

Expected behavior
For embeddings, OPENAI_EMBEDDING_API_KEY should take precedence over OPENAI_API_KEY, and OPENAI_EMBEDDING_BASE_URL should route embeddings independently from chat completions.

Actual behavior
createEmbeddingProvider() calls:

new OpenAIEmbeddingProvider(getEnvVar("OPENAI_API_KEY")!)
Because a constructor argument is passed, the provider's internal fallback:

apiKey || getEnvVar("OPENAI_EMBEDDING_API_KEY") || getEnvVar("OPENAI_API_KEY")
never reaches OPENAI_EMBEDDING_API_KEY.

Root cause
src/providers/embedding/index.ts passes OPENAI_API_KEY into OpenAIEmbeddingProvider for the openai embedding provider case.

Suggested fix
Let OpenAIEmbeddingProvider resolve its own env vars:

case "openai":
  return withDimensionGuard(new OpenAIEmbeddingProvider());
This keeps the documented precedence inside OpenAIEmbeddingProvider:

constructor override, if explicitly provided
OPENAI_EMBEDDING_API_KEY
OPENAI_API_KEY
Notes
This is especially useful for setups where:

chat/compression uses a hosted OpenAI-compatible provider
embeddings use local LM Studio / vLLM / Ollama / llama.cpp
the two endpoints require different API keys

## PR patch

```diff
diff --git a/src/providers/embedding/index.ts b/src/providers/embedding/index.ts
index 0000000..0000000 100644
--- a/src/providers/embedding/index.ts
+++ b/src/providers/embedding/index.ts
@@
-    case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider(getEnvVar("OPENAI_API_KEY")!));
+    case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider());
PR description draft
Title:

Respect OPENAI_EMBEDDING_API_KEY for OpenAI embedding provider

Body:

### What changed

This updates the OpenAI embedding provider factory to let `OpenAIEmbeddingProvider` resolve its own API key from the documented precedence:

1. explicit constructor argument
2. `OPENAI_EMBEDDING_API_KEY`
3. `OPENAI_API_KEY`

### Why

The current factory passes `OPENAI_API_KEY` directly:

```ts
new OpenAIEmbeddingProvider(getEnvVar("OPENAI_API_KEY")!)
That prevents OPENAI_EMBEDDING_API_KEY from being used when users configure:

OPENAI_API_KEY / OPENAI_BASE_URL for hosted OpenAI-compatible chat
OPENAI_EMBEDDING_API_KEY / OPENAI_EMBEDDING_BASE_URL for local embeddings
The provider already supports this split internally, so the factory should not override it.

Validation
The fix is behaviorally scoped to the OpenAI embedding provider construction path.
Existing configs that only set OPENAI_API_KEY continue to work because OpenAIEmbeddingProvider falls back to OPENAI_API_KEY.

[skywalker-35]

Can confirm this issue — hit it hard today while migrating from Zhipu embedding-3 to SiliconFlow BGE-M3.

Our setup

# LLM: DeepSeek V4 Flash
OPENAI_API_KEY=sk-deepseek-key
OPENAI_BASE_URL=https://api.deepseek.com
OPENAI_MODEL=deepseek-v4-flash

# Embedding: SiliconFlow BGE-M3 (free tier)
EMBEDDING_PROVIDER=openai
OPENAI_EMBEDDING_API_KEY=sk-siliconflow-key
OPENAI_EMBEDDING_BASE_URL=https://api.siliconflow.cn/v1
OPENAI_EMBEDDING_MODEL=BAAI/bge-m3
OPENAI_EMBEDDING_DIMENSIONS=1024

Symptoms

• smart-search returned results but scores were stuck at 1/rank pattern (~0.016) — indicating pure BM25, no vector search
• Logs showed: OpenAI embedding failed (401): "Api key is invalid" — DeepSeek key being sent to SiliconFlow
• circuit_breaker_open cascaded to kill all LLM compression because we hadn't set OPENAI_API_KEY in .env yet (was injecting via process env)

Temporary fix (confirmed working)

Patched the dist bundle directly:

- case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider(getEnvVar("OPENAI_API_KEY")));
+ case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider(getEnvVar("OPENAI_EMBEDDING_API_KEY")));

After this, Chinese smart-search went from 0 → 5 results, LLM compression recovered, no more 401s.

Additional silent-failure concern

The catch {} block around this.embeddingProvider.embed(query) in tripleStreamSearch silently swallows these 401 errors. Users see zero/empty results with no indication that their embedding config is broken. agentmemory doctor also doesn't catch this — it only tests connectivity, not actual embedding calls.

Would be great to see the proposed fix merged (passing no arg to OpenAIEmbeddingProvider so it follows its own fallback chain).

[skywalker-35]

Closing the loop on this from the agentmemory v0.9.21 side. We've been running a workaround for ~4 days and have confirmed the exact root cause and the fix path. There are now multiple PRs in flight (notably #832, #870, #932, #933) targeting the same createEmbeddingProvider() factory change, so a separate PR from us would be a duplicate. Recording the validated root cause + minimal fix here for posterity and to help whichever PR lands.

Confirmed minimal fix (1 char)

src/providers/embedding/index.ts currently forces OPENAI_API_KEY into the OpenAI embedding provider:

case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider(getEnvVar("OPENAI_API_KEY")!));

OpenAIEmbeddingProvider already implements the documented precedence chain internally — apiKey constructor arg → OPENAI_EMBEDDING_API_KEY → OPENAI_API_KEY — but the factory's forced constructor arg short-circuits that. The fix is to drop the forced arg and let the provider resolve its own env vars:

case "openai": return withDimensionGuard(new OpenAIEmbeddingProvider());

That's a 1-character diff (! removal) and restores the documented behavior. #832 does exactly this and is the cleanest of the in-flight PRs — recommend merging that one.

Our production config (confirmed working after the fix)

# LLM (DeepSeek V4 Flash, hosted)
OPENAI_API_KEY=sk-deepseek
OPENAI_BASE_URL=https://api.deepseek.com
OPENAI_MODEL=deepseek-v4-flash

# Embeddings (separate hosted endpoint, free tier)
EMBEDDING_PROVIDER=openai
OPENAI_EMBEDDING_API_KEY=sk-siliconflow
OPENAI_EMBEDDING_BASE_URL=https://api.siliconflow.cn/v1
OPENAI_EMBEDDING_MODEL=BAAI/bge-m3
OPENAI_EMBEDDING_DIMENSIONS=1024

After applying the factory fix, the DeepSeek key no longer leaks to the SiliconFlow endpoint, smart_search scores normalize (no longer stuck at the 1/rank BM25-only pattern), and LLM compression recovers (the circuit_breaker_open cascade that killed it disappears because embedding 401s stop happening).

Silent-failure footnote (related, not blocking)

The catch {} block around embeddingProvider.embed(query) inside tripleStreamSearch swallows 401s silently. Users see zero / empty results with no signal that their embedding config is broken. agentmemory doctor only tests connectivity, not actual embedding calls — same blind spot. Worth a one-line log.warn in that catch so misconfig surfaces in stderr. Filing as a follow-up rather than expanding this issue's scope.

Related PRs in flight

• Fix OpenAI embedding provider key selection #832 — same 1-line factory fix (earliest, cleanest)
• fix: prefer OPENAI_EMBEDDING_API_KEY over OPENAI_API_KEY for embeddings #870 — same fix (now closed as duplicate)
• fix: prefer OPENAI_EMBEDDING_API_KEY over OPENAI_API_KEY for embeddings #932, fix: prefer OPENAI_EMBEDDING_API_KEY over OPENAI_API_KEY for embeddings #933 — same fix (subsequent iterations)
• Fix/embedding key resolution #942 — broader embedding key resolution (now closed as too large in scope)