Contributing Gemini AI Support to memU

Published on 2026-03-01

memU is a personal memory layer for AI assistants — an MCP (Model Context Protocol) server that lets tools like Claude Code retrieve and store memories across sessions. Instead of every conversation starting from zero context, memU persists what matters: user preferences, project patterns, past decisions, accumulated context.

The project already supported OpenAI embeddings for semantic memory retrieval. I added Gemini AI as a supported provider.

---

What the Contribution Involved

memU's memory system works by embedding memories as vectors and retrieving the most semantically similar ones at query time. The embedding provider determines the quality and cost of that retrieval.

Adding Gemini support meant:

1. Integrating the Gemini embedding API Google's text-embedding-004 model — mapping memory strings to dense vectors in a compatible embedding space. This required understanding the Gemini API's embedding endpoint, its input constraints (token limits, batch behavior), and how to normalize outputs to be comparable with the existing retrieval logic.

2. Making the provider switchable Hard-coding OpenAI into the retrieval pipeline would make it brittle. The cleaner solution was abstracting the embedding call behind a provider interface so users can configure which model backs their memory store. OpenAI, Gemini, or future providers — the retrieval logic stays unchanged.

3. Handling the API differences OpenAI and Gemini have different request shapes, rate limits, and error surfaces. The Gemini provider needed its own error handling and retry logic without leaking those details into the core retrieval system.

4. Testing retrieval quality Embedding quality affects which memories surface for a given query. I ran comparative retrieval tests — same memory set, same query, different providers — to verify that Gemini embeddings returned semantically coherent results rather than random noise.

---

Why This Matters

memU with only OpenAI support creates a hard dependency: you need an OpenAI API key and you pay OpenAI's embedding costs for every retrieval. Adding Gemini gives users a choice — Google's embedding model is fast, well-priced, and deeply integrated with the Gemini ecosystem.

For anyone building Claude Code workflows who already uses Gemini elsewhere, this removes the friction of needing a second AI provider just for memory.

---

What I Learned

Open-source contributions are about interface design more than implementation. The implementation of the Gemini API call is simple. The interesting decision was where to put the abstraction boundary — how to make adding a third provider later require minimal changes. Getting that boundary wrong means every new provider is a surgical refactor.

Embedding models are not interchangeable. text-embedding-ada-002 and text-embedding-004 produce vectors in different spaces. You can't mix embeddings from different models in the same vector store without re-embedding everything. If a user switches providers, their stored memories need to be re-indexed. This was a constraint worth documenting explicitly.

Small, well-scoped contributions compound. This wasn't a massive feature. It was one provider added cleanly, with tests, to an existing system. But it makes the project genuinely more useful for a set of users who weren't served before. That's enough.

---

The Meta Point

I use memU in my own Claude Code sessions — it's how context about my projects, preferences, and patterns persists across conversations. Contributing to a tool you actually depend on is a different kind of motivation than contributing to something abstract. You know exactly what the user wants because you are the user.