Self-hosted binary: memory agent fails with Azure OpenAI and OpenAI-compatible proxies (only first-party OpenAI/Anthropic work)

[HermonKidane]

Problem

The self-hosted supermemory binary's memory agent consistently fails (~280-300ms, before making any HTTP request) when configured to use:

• Azure OpenAI (even with correct deployment URL)
• LiteLLM proxy → Azure OpenAI
• Third-party OpenAI-compatible endpoints (notokenlimit, MyAPI, Synterolink, etc.)

The memory agent only works with first-party api.openai.com or api.anthropic.com endpoints.

Environment

• Binary version: supermemory local (latest as of 2026-07-08)
• Platform: macOS (darwin)
• Config: OPENAI_BASE_URL, OPENAI_API_KEY, OPENAI_MODEL env vars

Reproduction

1. Azure OpenAI (direct)

# Azure deployment exists and works via direct API calls
OPENAI_BASE_URL="https://myrecruter.openai.azure.com/openai/deployments/test-dep2"
OPENAI_API_KEY="<azure-key>"
OPENAI_MODEL="test-dep2"
supermemory local start --port 6767

Result: Memory agent fails at ~286ms with generic "Self-hosted memory agent failed for document, skipping memory generation" warning. Zero HTTP requests logged at Azure endpoint.

2. LiteLLM Proxy → Azure OpenAI

# LiteLLM proxy running on localhost:4000, confirmed working with curl structured-output tests
OPENAI_BASE_URL="http://localhost:4000/v1"
OPENAI_API_KEY="dummy"
OPENAI_MODEL="gpt-5-mini"
supermemory local start --port 6767

Result: Memory agent fails at ~280-300ms. Zero requests logged by LiteLLM, confirming the binary never attempts the HTTP call.

3. Verified Working (for comparison)

Direct curl tests to both Azure and LiteLLM proxy with response_format: { type: "json_schema", strict: true } return valid structured JSON responses, confirming:

• Azure OpenAI supports structured output ✅
• LiteLLM correctly translates requests to Azure format ✅
• The blocker is inside the supermemory binary, not the provider

Expected Behavior

The binary should work with any OpenAI-compatible endpoint that supports:

1. /v1/chat/completions
2. response_format: { type: "json_schema", ... }
3. Standard Authorization: Bearer <key> or custom headers (Azure's api-key)

LiteLLM and similar proxies exist specifically to bridge this gap for Azure/other providers.

Actual Behavior

The binary's memory agent (generateObject from Vercel AI SDK) appears to have hardcoded provider validation that rejects non-official endpoints before making HTTP calls. The ~280-300ms failure timing is too fast for network I/O—it's a code-level rejection during SDK initialization.

Investigation Summary

• Tested 7 provider configurations (Azure direct, LiteLLM, notokenlimit, MyAPI, Synterolink, Epsilon)
• All fail at ~280-300ms with zero HTTP requests
• Binary strings search: no OPENAI_COMPATIBILITY_MODE, STRICT_SCHEMA, or validation override flags
• Only first-party api.openai.com / api.anthropic.com work

Impact

Users with:

• Azure OpenAI subscriptions (common in enterprise environments)
• Self-hosted LLMs behind OpenAI-compatible proxies (vLLM, Ollama + LiteLLM)
• Third-party OpenAI proxies

…cannot use the self-hosted binary's memory agent, despite having working structured-output-capable LLMs.

Suggested Fix

1. Short term: Document that only first-party OpenAI/Anthropic endpoints are supported
2. Long term: Either:
   • Add a compatibility flag (OPENAI_COMPATIBILITY_MODE=true) to bypass provider validation
   • Update Vercel AI SDK usage to accept any base URL without endpoint validation
   • Expose Azure-specific env vars (AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_KEY, AZURE_OPENAI_DEPLOYMENT) that construct Azure-compatible requests

Related

This is a client-side SDK constraint, not a server-side API compatibility issue. Worth noting for anyone migrating from cloud supermemory (which supports Azure via its memory router proxy) to self-hosted.

[linear-code]

ENG-1015