Mem

Inspiration

Chrome already has a history search bar. The uncomfortable question early on was: What can mem do that Ctrl+H can't? If the answer is "semantic search over page titles," that's a nicer search bar not a secondary memory.

Three things history structurally cannot do, no matter how good its search gets:

1. It stores URLs and titles, so it can never answer a question about what a page actually said.

2. It has no representation of state, "did I finish this?" isn't a question it can positively answer. It can't even understand that question.

3. It's passive. It answers when asked, so everything you don't think to ask about is functionally lost.

Human memory doesn't work like a log. Nobody can recall a random Tuesday as a bunch of URLs. They recall "the afternoon I was trying to figure out why the auth redirect kept looping." We built it specifically for that purpose.

What it does

Alright but what actually is mem, mem is a local first second memory across your browsing, Gmail, Drive, Youtube, Calendar, Classroom, and dropped files.

Ask it things and get answers with citations it shows real synthesis over document content, streamed, with follow-ups. "Why do they degrade?" works as a second question.

it commitments, reads a line like "yo i have another hackathon ending tmrw at 12pm" in any chat and offers a reminder. Pure local string work; nothing leaves the machine unless you click.

Runs with no API key. On-device Gemini Nano for generation, hashed local embeddings for retrieval. How we built it

How we built it

With the help of claude it was built using JS, MV3, IndexedDB, no build step no backend as it is a Chrome extension accessible through the developer panel.

AI is a three provider facade, OpenAI, Gemini, on-device, with automatic fallback when a key is missing, rate limited, or offline. Every vector is tagged with its embedding space so vectors from different models are never compared.

I used pre-existing code that I made myself but only parts majority of the work and idea was built in the past couple of days. The general idea about it was not built until this weekend where I made a v1 and then a v2 which is the most recent update.

Challenges we ran into

The 2,000-character ceiling. A 60,000-character PDF got exactly one embedding, computed over its title and opening. Everything past that was semantically unreachable, the single biggest quality bug, and invisible unless you went looking.

"Why?" embeds to nothing. Follow-up questions retrieved garbage until queries were rewritten into standalone form before retrieval rather than just passing history to the model. While I was doing Anthropic's Building With Claude's API course I realized that I had not accounted for this.

One thing that is still there is that you can't use the on device model in your phone as the model only works on a computer.

Accomplishments that we're proud of

129 tests, all passing, including the one that matters: a fact buried 40,000 characters into a document is retrievable.

It works with no key and no network. Not a degraded mode with a warning banner, a real fallback path.

Commitment detection fires on how people actually type ("tmrw at 12pm", confidence 0.92) and stays silent on hedged plans and ordinary chatter.

What we learned

The honest test is brutal and useful. "Could Ctrl+H do this?" killed several features that felt clever and kept the ones worth building.

What's next for Mem

Learned on-device embeddings once WebGPU-backed models are practical, hashed vectors capture vocabulary and morphology, not synonymy, and "photovoltaics" still won't find "solar cells" offline.

Beyond that: cross-device sync without a server, contradiction detection across sources, and opening the index to other tools.

Built With

• claude
• indexeddb
• javascript
• mv3