Lumichats - A Claude Code alternative for people who avoid the terminal
70,000 people use LumiChats in a browser and kept asking for the one thing a browser cannot do: touch their files. So we built the desktop one. It runs commands on your machine, writes real documents, and you pay only for the work you run.
Replies
Zero data collection and fully offline is the first thing I check before recommending a tool on a security-sensitive project. That alone covers a lot of ground. What I want to understand is the model isolation side: does the app sandbox the model process away from the filesystem, or does it get direct read/write access to the project directory? And for the local models, are they bundled or bring-your-own?
LumiChats Offline
@hi_i_am_mimo Both of your questions are about our other product, so quickly: the fully offline one is separate software, and its models are bring your own. Nothing is bundled. You download one matched to your system specs.
LumiDesk, the one launching here, runs the model on our servers. So on your first question, there is no model process on your machine to sandbox, and it never gets direct read or write access to the project directory. It cannot open a file or run a command at all. It emits a tool call, the app executes it locally, and every write, edit and command passes the permission gate first. Grants are scoped to a folder, so anything outside the one you approved asks again, and destructive commands can never be pre approved.
The thing to weigh instead: whatever a tool reads becomes part of the conversation, and the conversation goes to the server. So the boundary is not the project directory, it is what you point the agent at. If the source itself is the sensitive material, the offline product is the one built for that.
That last point is the real question then. If whatever a tool reads goes to your servers as conversation context, what is the retention policy on that data? Asking because source code and local configs are often the most sensitive material, and the server processes context changes the threat model significantly compared to what offline implies in the name.
LumiChats Offline
@hi_i_am_mimo there is no retention policy on conversation data because there is no conversation data on our side.
What we hold for an account is your login id and your subscription plan. That is the whole list. Your conversation history lives on your device as local files, keyed by project. Reopening a chat reads from your disk. Delete a conversation and it is gone, permanently, because there is no server copy to also delete. If an account goes inactive for around six months, the little we do hold gets removed too.
Now the part I will not soften, because it is the actual answer to your threat model question. In cloud mode we do send your messages to the model. That is what cloud mode is. And your messages include whatever the agent was asked to look at, so if it read three source files to answer you, those files are in that request. We do not store it and it does not come back to us, but it transits. For source code, transit is the decision, not storage.
Everything else stays local. Commands run on your machine, files are read and written on your machine, none of it passes through us.
So the honest line: if the concern is a vendor accumulating your codebase, we do not, and there is no archive to breach. If the concern is the source touching any external system at all, cloud mode is the wrong tool no matter how good the retention policy is. That is why LumiChats Offline exists as separate software with local LLMs, and for a security sensitive project that is the one I would point you to.
"100% free" and "open source" while also shipping your own fine-tuned models raises an interesting question about sustainability. What's the actual business model or motivation behind maintaining this, is it a community project, a loss leader for a paid product, or something else? Knowing that matters for users deciding whether to build workflows around it, since "free forever" from a solo maintainer and "free tier of a company" have very different longevity profiles.
LumiChats Offline
@ansari_adin Good question, and the answer is cleaner than it looks because you are describing two different products.
The 100% free and open source one is LumiChats Offline. It runs entirely on your device, which means it costs us nothing to operate. There is no inference bill, no hosting, no per user cost that grows as more people use it. That is the whole sustainability answer: it is not free as in subsidised, it is free as in there is nothing to subsidise. It is open source so that anyone who wants to fine tune it for their own use case can, rather than waiting on us to support their domain.
On the models: we do not host them. You download from Hugging Face and run them on your machine. Those same models are going into our Android app soon, with more agentic capability than the desktop build has today.
The paid product is the cloud one, and that is where the business model lives. It is a per day subscription. I built it that way because as a student I hated paying for a whole month when I only needed something for two days. That is genuinely the origin. Sixty nine rupees a day, or a monthly plan if you use it constantly, and I take a small margin on it. It was aimed at students who cannot justify the bigger subscriptions.
So to your longevity point directly: this is not free forever from a solo maintainer. Cloud gives you five free messages a day and then you pay, because cloud inference costs real money and pretending otherwise is how free tiers die. Free forever applies to the local models, and it holds because running them costs me nothing. Those are two different promises and I would rather you know which one you are relying on before you build a workflow on it.
The permission and rollback answers above are thorough. One thing I didn't see: before a task actually runs, does the user get any kind of cost estimate, even a rough one, or do they find out what it cost only after it's done? Pay-per-use only feels safe to explore if you can tell roughly what a big task will cost before committing to it, otherwise the first surprising bill teaches the same rationing lesson Asad described, just from the other direction.
LumiChats Offline
@raffay_sajjad The estimate question dissolves here, because we do not bill per token.
It is a flat day pass. Sixty nine rupees, under a dollar, and the day is unlimited. Or eleven ninety nine a month. A big task and a small one cost exactly the same, so there is nothing to estimate before you start and no bill that can surprise you afterwards. The worst case is you spent one day's price.
Your point is right about per token products though, and it is the reason we did not build one. Metered pricing makes you do arithmetic before every prompt, and the rationing Asad described comes from exactly that. Charging for the day instead means exploring a task and being wrong about it costs nothing extra, which is when the tool is actually useful.