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
LumiChats Offline
"A black window that expects you to already know the words" is exactly why terminal tools stay niche no matter how good they are.
LumiChats Offline
@irahimiam Thanks, Arash! That line came from hearing the same frustration over and over. The goal with LumiChats is to make that same power accessible without requiring people to learn terminal commands first. Really appreciate you taking the time to read and comment! 🙌
Pay for what you run sounds obviously fairer than a subscription, and it has one nasty failure mode: people start rationing. The moment someone can feel the meter, they stop asking the second and third question, and those are usually the ones that get them the answer. Watch actions per session in week two against week one. If that drops, the pricing is teaching people to use it less, and "under a dollar for an afternoon" won't save you.
LumiChats Offline
@asadmalik901 That's a really insightful point, Asad. It's something we've been thinking about as well. Our goal is to make costs predictable enough that people don't hesitate to use LumiChats, and we'll definitely be watching engagement patterns like actions per session. One thing we've tried to do is avoid making people feel like they're being charged for every tiny interaction—when you start a usage period, you're free to use it without constantly watching a meter. If we ever see pricing discouraging exploration, we'll iterate. Thanks for calling this out—it's genuinely valuable feedback. 🙌
@aditya_kumar_jha1 The number I'd watch isn't day one, it's the second week. Ours looked fine on launch day and then actions per user fell about 40% by week two, because by then people had worked out roughly what each thing cost them. Nobody complains, they just stop poking at it.
LumiChats Offline
@asadmalik901 40% is a hard number and I'm not going to argue with it.
The one structural difference on our side is that the meter isn't per action a day pass is unlimited for that day, so the second and third question cost nothing once you're in. That doesn't remove rationing, it relocates it: instead of "is this question worth it", it becomes "is today worth a pass". Better place for the friction — once a day rather than once a thought but it's still friction, and it'll bite hardest on the casual "just checking one thing" use, which is exactly the use that turns into a habit.
So the number I'll watch is actions per pass, not per session. If that climbs while passes bought falls, the rationing has just moved upstream and I've fooled myself into reading it as engagement. I'll come back with it in two weeks.
Interesting angle — the terminal is doing more work than people realize, and it's not the typing.
When Claude Code generates something that doesn't compile, the terminal is where the loop closes: the agent sees the error, reads it, and retries. Take the terminal away and someone still has to close that loop. Does Lumichats surface the failure to the user, or does it self-correct silently before they ever see it?
I ask because in my experience that's where the whole "no-terminal" promise usually breaks: the moment a non-technical user is shown a stack trace, you've lost them — but if you hide it and retry blindly, you burn tokens and they wait without knowing why. Curious how you handled it.
LumiChats Offline
@rodrigo_baigorria It self-corrects, and the user sees that it's correcting without being shown what broke. The raw error goes to the model verbatim; the user gets one line in a collapsed panel — expandable to the full stack trace. Not hidden, just demoted.
Blind retry is the trap, so it's bounded: if the model asks for the same thing that just failed the same way, the run stops and says so. And a run that produced no file and no answer is never reported as finished — "it ran without erroring" isn't "it worked".
Honestly, the failure we hit wasn't stack traces, it was silence. A model writing a long file sends it as one tool argument, so the busiest minutes had nothing to show — which reads as a hang. Still finishing that one.
@aditya_kumar_jha1 "Demoted, not hidden" is the right call — and "it ran without erroring isn't it worked" is the part most people skip entirely.
On the silence: I hit exactly the same wall and ended up splitting it in two calls. A cheap, fast one that only produces the plan — what it's about to build, in plain language — streamed token by token, and then the expensive one that actually writes the files. The narration fills the dead minutes with something true instead of a spinner, and it barely costs anything because you can run the planning call at low effort.
The other thing that saved me was a heartbeat every 15 seconds on the stream. Not for the user — for the infrastructure. My host was silently dropping long connections, and from the client side that is indistinguishable from a hang.
Congrats on the launch.
LumiChats Offline
@rodrigo_baigorria The heartbeat one lands. I have the pessimistic half — the client calls a stream dead after 90s of silence, reset by every chunk. But that only bounds how long you wait for nothing; it can't tell you the connection is alive. Same road as you: a host holding a connection open, then five minutes later a terminated from the HTTP layer that nothing matched on. I'd filed it as a UI problem. It's an infrastructure one. Taking that.
The two-call split fixes something my answer doesn't. Reasoning does stream, so it isn't literally silent — but reasoning is the model talking to itself, and using it as narration means showing someone chatter never written for them. A cheap planning pass produces something authored for the reader. Different object. I'd watch for drift, since the writing pass can wander off the plan it just narrated — probably still worth it.
Thanks — these two are worth more than the congrats.
@aditya_kumar_jha1 Drift is real, and I don't think you can prevent it — but you can make it detectable. I treat the plan as a contract: pull the checkable claims out of it (which files it said it would create, which sections it said it would wire up) and assert them against the output afterward. If the writing pass wandered, the assertion fails — and that's a far better signal than the model's own report that it finished.
It gave me something I didn't expect, too: the failures turn into a corpus. Every time an assertion catches drift, that becomes a rule I feed into the next generation's prompt. The plan stops being narration and starts being a test.
Good luck today.
The permission split (ask / auto-apply / read-only) covers whether it asks. The part I can't picture is what the ask looks like for someone who doesn't know the words. I run a terminal agent every day, and an approval prompt is only a safety feature because I can evaluate it — "run this command, write those files" carries information for me, so my yes/no does too. For the researcher with 200 PDFs, the same prompt is noise. By the third one they're clicking yes on reflex, and the ask has quietly become a ritual instead of a decision.
Do you translate each action into plain-language intent before asking — "unpack the images from this PDF" rather than the command itself? And if so, how do you handle the gap when the description and the actual action drift, since the user is approving the sentence, not the command? You solved the error side with "demoted, not hidden" — one line, expandable to the full trace. Wondering if approvals get the same treatment, because that gap between what's said and what runs seems like the hardest part of "no terminal" to me.
LumiChats Offline
@kyo_shino Yes, plain intent. The important part is that the sentence is generated from the call, not written by the model.
The card reads "Create portfolio.html" or "Install pandas" or "Run npm install", with the exact path or command on the line beneath it, plus one line on why the step needs to happen at all. For a missing library that reads "a library this step needs is missing, installing it lets the task continue."
That structure is the answer to your drift question. The description is not the model narrating what it is about to do. It is derived from the tool name and its actual arguments, so there is no prose layer in between that could describe one thing while another runs. You are approving a sentence, but the sentence is a rendering of the command rather than a claim about it, and the command sits right underneath, so the two can be compared without expanding anything.
Approvals do get the same treatment as errors, with one inversion. One line, Details expands. Except for file edits and destructive commands, which open expanded by default, because for those the diff is the decision and hiding it would be the wrong default.
On the third click becoming reflex: I think that is the real failure, and better wording does not fix it. Fewer prompts do. "Always allow writes in thesis" turns 200 asks into one scoped decision, made once, while the person still has the context to judge it. That button is hidden on anything destructive, because the engine refuses to persist that kind of grant, so offering it would be a lie.
@aditya_kumar_jha1 "A rendering of the command rather than a claim about it" is exactly the distinction I was fishing for — deriving the sentence from the actual arguments instead of letting the model narrate itself removes the layer where drift lives. And the inversion for edits, the diff opening expanded because the diff is the decision, is the detail I'd have missed and immediately believe.
One thing I've learned running scoped grants on my own agent, offered as a data point rather than advice: the grant outlives the judgment that made it. My allowlist is full of "always allow" decisions that were obviously right in the moment and that I couldn't reconstruct today — the folder's stakes changed, the grant didn't. The nice property of your derived sentences is that a grant inventory could be rendered the same honest way, so revisiting an old grant costs as little as approving it did.
Thanks for the thorough answer — this thread turned into the clearest explanation of what "no terminal" actually has to solve that I've seen.
What's the difference with Claude Cowork ?
LumiChats Offline
@tacitefood Great question! Cowork is probably the closest comparison, and it's an excellent product. The main differences are that LumiChats lets you choose between running everything locally or using the cloud, supports 40+ models instead of locking you into one, and has flexible pay-as-you-go pricing with unlimited use during a day pass—no subscriptions or session limits. It's also designed to make powerful AI workflows accessible to non-developers through a simple desktop interface.
LumiChats Offline
@tehreem_fatima5 That's a completely fair concern. We chose to launch before the code-signing certificate was ready because there was strong demand from early users, especially researchers and scientists who wanted the desktop version as soon as possible. An OV code-signing certificate is our top priority, and we're working to get it in place as soon as we can. We're also planning to open-source the codebase, because software that can run commands on your machine should be transparent and auditable. In the meantime, LumiChats is permission-first and always asks before making changes to your system.
The CPU only inference is the quietly underappreciated constraint here most offline AI projects quietly assume you have a CUDA capable GPU, so running on any modern laptop without that dependency
LumiChats Offline
@mohammed_messeguem Thanks, Mohammed! That was a deliberate design goal. We wanted LumiChats to work on the hardware people already have, not just high-end GPU machines. If someone does have a GPU, they can use it, but CPU-only support was important so more people can run AI locally without extra requirements. 🙌
the ask-before-changes / auto-apply / read-only split covers permission, but what about undo? if it's written a real .docx or edited files in a folder and I don't like what it did, is there any versioning or rollback, or is the expectation that I'm backing my own files up before pointing it at a folder? that's the part that'd decide whether I trust it on anything important versus a scratch directory.
LumiChats Offline
@galdayan There's real rollback, and one gap you should know about before you trust it on anything that matters.
Every file a tool writes or patches is snapshotted immediately before that specific write not at the start of the run, right before the change so a rewind restores the exact bytes that were there. That covers the ordinary case: it edited four files, you don't like the result, you put them back.
The gap is the one you named. When it produces a document by writing and running a script which is how a lot of .docx and .xlsx output actually gets made the file is created by the script, not by a tool call, so there's no "before" snapshot for it. Creating a new file is harmless, you just delete it. A script that overwrites something you already had is the case rewind won't save you from.
So: it defaults to its own working folder, and pointing it at a real project is a deliberate act. If you do that on anything important, use git. The rewind is a convenience for the common case, not a substitute for version control — and I'd rather tell you that now than have you discover it.
@aditya_kumar_jha1 that's exactly the kind of answer I was hoping for, thanks for not glossing over it. makes sense that script-generated output is the blind spot since it never goes through the tool call path. I'll keep it pointed at scratch folders for now and only aim it at a real repo once git's already covering me there.
LumiChats Offline
@galdayan That is exactly the right call, and honestly it is what I do too.
One thing that makes the scratch folder less limiting than it sounds: you can point it at a real repo for the reading and thinking, and still have it write output somewhere disposable. Most of the risk is in where it writes, not where it looks.
The script path is a real gap and not a permanent one. Closing it means snapshotting before a script runs when it could overwrite something that already exists, rather than only on tool calls. When that ships I would rather you hear it from a changelog entry than from a launch post, so it will be in there.
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.