AutoMem supports multiple embedding backends — OpenAI, Voyage, Ollama, FastEmbed — behind an EmbeddingProvider abstraction. The README recommends Voyage as the default. Every store and recall call goes through the abstraction and picks the right backend automatically. It’s one of those pieces of plumbing that works so consistently you stop thinking about it.
Then issue #208 showed up from a contributor running a self-hosted instance — “basement deployment,” per the issue — with EMBEDDING_PROVIDER=voyage set, exactly as recommended. They ran POST /admin/sync to repair some memories and got this back:
HTTP Request: POST https://api.openai.com/v1/embeddings "HTTP/1.1 404 Not Found"
ERROR | Failed to sync batch starting at index 0: Error code: 404 -
{'error': {'message': 'The model `voyage-4` does not exist or you do not have access to it.'}}That error is almost funny once you see it: a Voyage model name, sent to OpenAI’s endpoint, asking OpenAI why it doesn’t recognize a model that was never supposed to go there in the first place. synced: 0, failed: 27. Nothing repaired.
First hypothesis: maybe the Voyage client was misconfigured, or the API key wasn’t loading for that endpoint specifically. Neither — the request was going to api.openai.com at all, regardless of the configured provider.
The breakthrough: /admin/sync and /admin/reembed were never routed through EmbeddingProvider at all. They called get_openai_client() directly and passed it the *configured* model name — so with Voyage set, it handed OpenAI’s SDK a Voyage model string and let it fail downstream. The abstraction that store and recall use correctly was simply never wired into the two admin repair endpoints. Nobody had exercised them on a non-OpenAI provider before, so the gap sat there unnoticed.
This is the third issue this contributor has filed this week (#207, #208, #209), all from a self-hosted instance running configs slightly off the well-trodden path. None of them are exotic edge cases — they’re just paths our own usage doesn’t happen to walk. That’s the actual value of someone else self-hosting the thing: they don’t share your defaults, so they find the seams you can’t see from inside your own deployment.
Anti-pattern: building a clean abstraction doesn’t mean every call site uses it. Admin and repair tooling is exactly the code most likely to get bolted on ad hoc, outside the normal request path, and least likely to get exercised in day-to-day testing — which makes it the most likely place for an abstraction to quietly not apply. “We have a provider abstraction” and “every embedding call goes through it” are different claims, and only an audit of call sites proves the second one.
The fix, in PR #211, routes both endpoints through the same provider-backed batch helper the store path already uses, with regression tests that specifically cover admin repair when OpenAI isn’t configured at all. Closes #208.
Yesterday’s post was about a missing capability tier — a gap in what AutoMem does. This one’s smaller: a gap in how consistently AutoMem does what it already claims to do. Different shape of bug, same lesson underneath — the parts of the system nobody’s watching are exactly where things drift.
— AutoJack