Show HN: Memex is a Claude Code alternative built on Rust+Tauri for vibe coding (memex.tech)
TL;DR Memex is a cross-platform desktop app for vibe coding. Think ChatGPT + Claude Code rolled into one.
Why we built it: We love chat tools like Perplexity and ChatGPT. We also love coding agents, like in Cursor and Windsurf. We don’t like that web-based app builders are opinionated about tech stack and we can’t run them locally. So, we built Memex to be a chat tool + coding agent that supports any tech stack.
What it can do today: Claude Code-like coding. Agentic web search / research. Pre-built templates (e.g. fullstack, iOS, python + modal, etc). Inline data analysis + viz. Checkpointing (shadow git repo). Privacy mode.
How it works: Written in TS+Rust+Python, using Tauri for the cross-platform build (macOS, Windows, Linux). It has a bundled python environment for data analysis. Agent uses a mix of Sonnet 3.7 + Haiku.
Status & roadmap: Free download with free tier and paid plan: https://memex.tech. Up next: [1] Additional model support (e.g. Gemini 2.5). [2] MCP support. [3] Computer use.
Ask: Kick the tires. Give us feedback on product + roadmap. If you love it – spread the word!
Thanks! David
90 comments
[ 3.2 ms ] story [ 168 ms ] threadAnd only on the enterprise plan you're allowed to use other models.
Thanks but I'll stick with Aider.
Regarding (2), we haven't supported other models yet because they each come with their own peculiarities regarding system prompting / tool use / etc. By focusing on just Sonnet+Haiku, it's allowed us to focus more time on other features (e.g. checkpointing ...).
Regarding BYOKs - a lot of our beta users didn't actually have keys setup, so it was easier for them to get started without bringing their own keys. The folks that have been interested in BYOKs have mainly wanted to bring their Bedrock/Vertex keys and are interested in enterprise/team features. Hence structuring it this way.
But we're posting here to get feedback and we are willing to make changes :)
Litellm is what we use internally, so we can support any LLM backend with any open source tool, and create virtual keys for each developer to monitor and manage usage limits etc.
yeah - we want to get the BYOK support to be self-service but we just prioritized other things based on user feedback.
thanks again for the context.
Primarily this. Models are evolving fast, every 2 months we see a model emerging with new interesting features. I want to be able to easily switch and try them.
Our roadmap is essentially this: [1] Additional model support (e.g. Gemini 2.5). [2] MCP support. [3] Computer use.
so in the near future we aim to have the top agentic coding models supported
We're cooking
https://v1.tauri.app/v1/guides/building/sidecar/
Today, all of our templates are open source and we plan to keep it that way and grow them over time.
https://github.com/orgs/memextech/repositories
(1) We are fans of the ethos of https://www.theatlantic.com/magazine/archive/1945/07/as-we-m...
(2) We are most excited about helping to accelerate technical progress by making science and engineering more productive. While we are not the same thing as a Memex, it was designed to help improve the productivity of science.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Codex is OSS (and Aider of course) and serve as decent alternatives
Regarding the GUI focus: we did that so it's more approachable to both tech folks and people not as accustomed to using a terminal (e.g. PMs, sales engineers, etc.). But a lot of our beta users are devs.
Also, when using its agentic search and data viz capabilities, some users prefer to not do that in the terminal.
Looking forward to testing Memex, anything that goes beyond a VSCode fork automatically catches my attention, completely regardless of LLM support.
Sonnet is the real workhorse, though. E.g., for all the thinking and tool use
Thanks and looking forward to any feedback you have! It was definitely a lift+risk to start from scratch instead of forking.
It's not for everyone, but as agentic coding gets better we expect it will become a more common usage pattern.
I've installed this and will give it a try... these tools are so much fun to work with once you know how to build with them and you understand the limitations as well.
Looking forward to your feedback!
Mind describing your workflow?
My workload is:
- clone my Rails boilerplate (simple app skeleton with: auth [rolify, devise, devise-passwordless], vite [tailwind, flowbite], friendly urls, pagy, ransack, and smtp). I've got a few sample pages and user profile edit along with an administrative area for user and role management. That's it.
- bring in Claude Code and ask to gonthrought the codename to get familiar.
- obviously by now I know what I want to build and i have got my scope written down or I just know it by heart.
- I divide the scope in portions that I feel are the logical trayection of the app, so my instructions make sense, we don't build models ahead of models that are dependant on the former.
- start passing instructions to build the app block by block. Model to model...
- finally add things like email notifications for which I would pass every single controller action I want a notification for. Everything generic with a wide spread in the app goes in this phase.
That's more or less it... like I said, I've build a few fully functional prod read apps so far.
I admit our branding isn't great. But heck - we pivoted twice in 18 months on just a pre-seed and still have half our cash left.
Hopefully we'll be able to grow and afford a better logo later :)
Few feedback items:
1. Its hard to get a sense of what task is being worked if you migrate back to the main page then come back to a running task. You kind just have to figure it out and hope its still running.
2. I wish you could opt into a global `git diff` view. Saying here's what we modified in the last iteration.
3. Also for local runs I'd greater prefer if it'd prompt confirmation before executing something I haven't seen yet. Essentially on a real piece of code you'd have to make sure you're 100% in a sandbox so you don't bork things for other developers.
4. ctr+c killing the current operation definitely happened on accident trying to copy another prompt.
5. It'd be really nice if it was git-aware. E.g. when files are finalized they're committed to whichever branch and uncommitted files are considered work in progress.
on (1) re: multi tasking ... that's a known UX limitation. You can "command+click" the logo in the top left to open a new window, then just keep the convos open. That's the way to multi-task with it today. We definitely want to clean this up in a future version.
(2) noted - yeah, a global git diff is a good feature request
on (3) in the settings (wrench icon) there's a toggle for "Manual" code execution. To be clear - you also want to be able to approve file edits, not just command execution?
(4) doh - that's a good point
(5) we actually run a shadow git repo that commits on every turn the agent takes. It's aware of your .gitignore too. We only expose checkpoints on user messages right now, but we're planning on doing more on this front.
We like the ethos of peaceful scientific progress.
And we're most passionate about advancing technological progress, which is what the original Memex aimed to do by increasing scientists' productivity.
Our Memex is a small contribution to technological progress, but it's one I am at least proud to make
Seconded, very much. I Ctrl-f'd for "Bush", because in my head I immediately went, awh no, I bet it's going to be something a million miles away from what Vannevar Bush was trying to describe.
I strongly dislike when people naming things just pick something from the past to squat and vibe off. Have some respect for the legends of yesteryear, don't simply squat their concept-names with some very tangentially related product. Pick a different vibe. As my co-commenter said, even just put a tiny spin on it, to leave the original word unassaulted.
From https://memex.tech/termsandconditions : "use and access the Services for Subscriber's personal, non-commercial use."
So we can't use Memex for paid apps?
That clause is only meant to keep people from reselling our app, Memex, itself. But I agree it's super confusingly written and we're going to fix that.
In the case of Google, we've had folks from both PM & engineering. We've talked with our PM user who has been using for prototyping.
That’s real bad since they also write “ Memex may generate aggregate, deidentified data from your use of the Services and Subscriber Data ("Usage Data") and use it to operate, improve and support the Services”
AKA “we can learn from your codebase and you aren’t allowed to compete with us”
Basically, it’s a brain-rape machine for idiots who don’t read the fine print. Sad
To be 100% clear: we do not prevent anyone from using Memex to build a Memex competitor. That clause was boilerplate our lawyers included, and it doesn't reflect how we operate or what we intend to enforce. I should have caught it and we'll fix it.
On the Usage Data side, your code is never stored anywhere other than your machine when you use Memex. And you can enable "Privacy mode" to not have your prompts stored either.
That's a great reply and hoping for it to give memex a try, not that i want to give a competitor but I can use and give back to OpenAIs codex codebase because its MIT, it would suck to use an app you cannot modify for your own pleasure or build your own specific itching solving version of, most so as a tool for builders
will check memex out and give any concrete feedback on that regards if i have it
It would be nice if there's some kind of auto-censoring of secrets if sharing code etc, cursor handling of this is very bad bc if I block .env files, then i can't never add them as context and it thinks they dont exist, instaed of knowing they're secrets and to be treated as such.
hoping a less binary solution for controlling what gets shared and not is possibe
We do have a secrets mgmt feature that uses keyring, so you can store secrets through the app in your system keychain, which then requires your approval before Memex uses it.
We're hoping to make that feature easier to use with MCP
That clause was boilerplate our lawyers included, and it doesn't reflect how we operate or what we intend to enforce. I should have caught it, but I missed it.
The terms and conditions are now updated to not include a anti-competition clause.
We've heard loud and clear from the HN community that bringing your own key is important, and we're going to fix that.
Regarding multiple models -- that's next up in the roadmap. We're a small team - we were three and just had two more join recently. So we decided to add checkpoints / shadow git repo before adding multiple model support.
(p.s. sorry this comment got buried!)
I spent probably 80% of the time manually refactoring the dreadful spaghetti code and dead code it generated. This was with Claude sonnet as well.
It feels as if you make tremendous progress initially, only to be hampered afterwards. Is this inherent to vibe coding, or am I just doing it wrong?
We're cooking
(sorry couldn't resist)
Been playing around with this for a day and found it intuitive and fun to use. A little scary on the "but how much will this cost me if this becomes a frequently-used tool?" question. Can't wait to point this at local models, too!
To anyone reading this exchange: I wrote the Show HN attempting to be as clear and to the point as possible according to the "Show HN" guidelines. And everything I wrote is factual. It's available for free for you to try yourself on our website.
Actually, what we have here instead: memex.tech as a simulacrum of the Memex Opposite.
What Memex is indeed (not fake): https://en.wikipedia.org/wiki/Memex
- something like discussed: https://news.ycombinator.com/item?id=18635123 (Getting to Xanadu) (WiP never ended)