Show HN: LocalGPT – A local-first AI assistant in Rust with persistent memory
댓글 (149)
Your docs and this post is all written by an LLM, which doesn't reflect much effort.
I wish this was an effective deterrent against posting low effort slop, but it isn't. Vibe coders are actively proud of the fact that they don't put any effort into the things they claim to have created.
I was also burnt many times where some software docs said one thing and after many hours of debugging I found out that code does something different.
LLMs are so good at creating decent descriptions and keeping them up to date that I believe docs are the number one thing to use them for. yes, you can tell human didn't write them, so what? if they are correct I see no issue at all.
These plagiarism laundering machines are giving people a brain disease that we haven't even named yet.
├── MEMORY.md # Long-term knowledge (auto-loaded each session)
├── HEARTBEAT.md # Autonomous task queue
├── SOUL.md # Personality and behavioral guidance
I do think that local-first will end up being the future long-term though. I built something similar last year (unreleased) also in Rust, but it was also running the model locally (you can see how slow/fast it is here[1], keeping in mind I have a 3080Ti and was running Mistral-Instruct).
I need to re-visit this project and release it, but building in the context of the OS is pretty mindblowing, so kudos to you. I think that the paradigm of how we interact with our devices will fundamentally shift in the next 5-10 years.
See here:
https://github.com/localgpt-app/localgpt/blob/main/src%2Fage...
Love or hate it, the amount of money being put into AI really is our generation's equivalent of the Apollo program. Over the next few years there are over 100 gigawatt scale data centres planned to come online.
At least it's a better use than money going into the military industry.
If I'm running a business and have some number of employees to make use of it, and confidentiality is worth something, sure, but am I really going to rely on anything less then the frontier models for automating critical tasks? Or roll my own on prem IT to support it when Amazon Bedrock will do it for me?
Got the same feeling when I put on the Hololens for the first time but look what we have now.
I assume I could just adjust the toml to point to deep seek API locally hosted right?
Does this mean the inference is remote and only context is local?
https://github.com/localgpt-app/localgpt/blob/main/src%2Fage...
The ReadMe gives only a Antropic version example, but, judging by the source code [1], you can use other providers, including Ollama, just by changing the syntax of that one config file line.
[1] https://github.com/localgpt-app/localgpt/blob/main/src%2Fage...
It is more like an OpenClaw rusty clone
Uses Mlx for local llm on apple silicon. Performance has been pretty good for a basic spec M4 mini.
Nor install the little apps that I don't know what they're doing and reading my chat history and mac system folders.
What I did was create a shortcut on my iphone to write imessages to an iCloud file, which syncs to my mac mini (quick) - and the script loop on the mini to process my messages. It works.
Wonder if others have ideas so I can iMessage the bot, im in iMessage and don't really want to use another app.
Its fast and amazing for generating embedding and lookups
"cargo install localgpt" under Linux Mint.
Git clone and change Cargo.toml by adding
"""rust
# Desktop GUI
eframe = { version = "0.30", default-features = false,
features = [ "default_fonts", "glow", "persistence", "x11", ] }
"""
That is add "x11"
Then cargo build --release succeeds.
I am not a Rust programmer.
cd localgpt/
edit cargo.toml and add "x11" to eframe
cargo install --path ~/.cargo/bin
Hey! is that Kai Lentit guy hiring?
See my post above.
Can it run on these two OS? How to install it in a simple way?
You're using the same memory format (SOUL.md, MEMORY.md, HEARTBEAT.md), similar architecture... but OpenClaw already ships with multi-channel messaging (Telegram, Discord, WhatsApp), voice calls, cron scheduling, browser automation, sub-agents, and a skills ecosystem.
Not trying to be harsh — the AI agent space just feels crowded with "me too" projects lately. What's the unique angle beyond "it's in Rust"?
It tries to do everything, but has no real security architecture.
Exec approvals are a farce.
OC can modify it's own permissions and config, and if you limit that you cannot really use it for is strengths.
What is needed is a well thought out security architecture, which allows easy approvals, but doesn't allow OC to do that itself, with credential and API access control (such as by using Wardgate [1], my solution for now), and separation of capabilities into multiple nodes/agents with good boundaries.
Currently OC needs effective root access, can change its own permissions and it's kinda all or nothing.
I'm working on a systems-security approach (object-capabilities, deterministic policy) - where you can have strong guarantees on a policy like "don't send out sensitive information".
Would love to chat with anyone who wants to use agents but who (rightly) refuses to compromise on security.
I can only think of two ways to address it:
1. Gate all sensitive operations (i.e. all external data flows) through a manual confirmation system, such as an OTP code that the human operator needs to manually approve every time, and also review the content being sent out. Cons: decision fatigue over time, can only feasibly be used if the agent only communicates externally infrequently or if the decision is easy to make by reading the data flowing out (wouldn't work if you need to review a 20-page PDF every time).
2. Design around the lethal trifecta: your agent can only have 2 legs instead of all 3. I believe this is the most robust approach for all use cases that support it. For example, agents that are privately accessed, and can work with private data and untrusted content but cannot externally communicate.
I'd be interested to know if you have reached similar conclusions or have a different approach to it?
Ask and ye shall receive. In a reply to another comment you claim it's because you couldn't be bothered writing documentation. It seems you couldn't be bothered writing the article on the project "blog" either[0].
My question then - Why bother at all?
[0]: https://www.pangram.com/history/dd0def3c-bcf9-4836-bfde-a9e9...
How much should we budget for the LLM? Would "standard" plan suffice?
Or is cost not important because "bro it's still cheaper than hiring Silicon Valley engineer!"
curious: when you say compatible with OpenClaw's markdown format, does that mean I could point LocalGPT at an existing OpenClaw workspace and it would just work? or is it more 'inspired by' the format?
the local embeddings for semantic search is smart. I've been using similar for code generation and the thing I kept running into was the embedding model choking on code snippets mixed with prose. did you hit that or does FTS5 + local embeddings just handle it?
also - genuinely asking, not criticizing - when the heartbeat runner executes autonomous tasks, how do you keep the model from doing risky stuff? hitting prod APIs, modifying files outside workspace, etc. do you sandbox or rely on the model being careful?
To solve this I've built Wardgate [1], which removes the need for agents to see any credentials and has access control on a per API endpoints basis. So you can say: yes you can read all Todoist tasks but you can't delete tasks or see tasks with "secure" in them, or see emails outside Inbox or with OTP codes, or whatever.
Interested in any comments / suggestions.
ort-sys@2.0.0-rc.11: [ort-sys] [WARN] can't do xcframework linking for target 'x86_64-apple-darwin'
We're past euphoria bubble stage, it's now delulu stage. Show them "AI", and they will like any shit.
I feel Elixir and the BEAM would be a perfect language to write this in. Gateways hanging, context window failures exhaustion can be elegantly modeled and remedied with supervision trees. For tracking thoughts, I can dump a process' mailbox and see what it's working on.
Sounds like exactly this, hot off the presses...
They deliberately only show you a fraction of the thoughts, but charge you for all the secret ones.
Big props for the creators ! :) Nice to see some others not just relying on condensing a single context and strive for more
- You can build it into a single binary with no external deps
- The Rust type system + ownership can help you a lot with correctness (e.g. encoding invariants, race conditions)
Can you explain how that works? The `MEMORY.md` is able to persists session history. But it seems that it's necessary for the user to add to that file manually.
An automated way to achieve this would be awesome.
The author can easily do this by creating a simple memory tool call, announcing it in the prompt to the LLM, and having it call the tool.
I wrote an agent harness for my own use that allows add/remove memories and the AI uses it as you would expect - to keep notes for itself between sessions.
I also think it'd be a great starting point for building a private pub/sub network of autonomous agents (e.g. a company that doesn't want to exfil its password files via OpenClaw)
The name, however, is a problem. LocalGPT is misleading in 2 ways. 1. It is not Local, it relies on external LLM providers. 2. It is not a Generative Pretrained Transformer.
I'd highly recommend changing the name to something that more accurately portrays the intent and the method.