Run 'pip install omnara && omnara', and you'll have a regular Claude Code session. But you can continue that same session from our web dashboard (https://omnara.com/) or mobile app (https://apps.apple.com/us/app/omnara-ai-command-center/id674...).
Check out a demo here: https://www.loom.com/share/03d30efcf8e44035af03cbfebf840c73.
Before Omnara, we felt stuck watching Claude Code think and write code, waiting 5-10 minutes just to provide input when needed. Now with Omnara, I can start a Claude Code session and if I need to leave my laptop, I can respond from my phone anywhere. Some places I've coded from include my bed, on a walk, in an Uber, while doing laundry, and even on the toilet.
There are many new Claude Code wrappers (e.g., Crystal, Conductor), but none keep the native Claude Code terminal experience while allowing interaction outside the terminal, especially on mobile. On the other hand, tools like Vibetunnel or Termius replicate the terminal experience but lack push notifications, clean UIs for answering questions or viewing git diffs, and easy setup.
We wanted our integration to fully mirror the native Claude Code experience, including terminal output, permissions, notifications, and mode switching. The Claude Code SDK and hooks don't support all of this, so we made a CLI wrapper that parses the session file at ~/.claude/projects and the terminal output to capture user and agent messages. We send these messages to our platform, where they're displayed in the web and mobile apps in real time via SSE. Our CLI wrapper monitors for input from both the Omnara platform and the Claude Code CLI, continuing execution when the user responds from either location. Our entire backend is open source: https://github.com/omnara-ai/omnara.
Omnara isn't just for Claude Code. It's a general framework for any AI agent to send messages and push notifications to humans when they need input. For example, I've been using it as a human-in-the-loop node in n8n workflows for replying to emails. But every Claude Code user we show it to gets excited about that application specifically so that’s why we’re launching that first :)
Omnara is free for up to 10 agent sessions per month, then $9/month for unlimited sessions. Looking forward to your feedback and hearing your thoughts and comments!
mccoyb•5mo ago
Truly — this is an excellent and accessible idea (bravo!), but if I can whittle away at a free and open source version, why should I ever consider paying for this?
zackify•5mo ago
I’ve been using Tailscale ssh to a raspberry pi.
With Termix on iOS.
I can do all the same stuff on my own. Termix is awesome (I’m not affiliated)
smithclay•5mo ago
TheTaytay•5mo ago
coyotespike•5mo ago
_1tem•5mo ago
itsalotoffun•5mo ago
cygn•5mo ago
kmansm27•5mo ago
svieira•5mo ago
mccoyb•5mo ago
kmansm27•5mo ago
mccoyb•5mo ago
bobbylarrybobby•5mo ago
mccoyb•5mo ago
Not very enlightening: just because Dropbox became big in one environment, doesn't mean the same questions aren't important in new spaces.
arendtio•5mo ago
So every time someone comes around with a sentence like 'but if I can whittle away at a free and open source version, why should I ever consider paying for this?', the answer will be that Dropbox thread ;-)
herval•5mo ago
sailfast•5mo ago
Maybe that is more for a general engineer than a Hacker though - hacker to me implies some sort of joy in doing it yourself rather than optimizing.
mccoyb•5mo ago
Probably a bad habit.
sailfast•5mo ago
jama211•5mo ago
_1tem•5mo ago
cpursley•5mo ago
_1tem•5mo ago
1. an AI email drafter which used my product docs and email templates as context (eventually I plan to add "tools" where the AI can lookup info in our database)
2. a simple email client with a sidebar with customer contextual info (their billing plan, etc.) and a few simple buttons for the operator to take actions on their account
3. A few basic team collaboration features, notes, assigning tickets to operators, escalating tickets...
It took about 2 days to build the initial version, and about 2 weeks to iron out a number of annoying AI slop bugs in the beginning. But after a month of use it's now pretty stable, my customer support hire is using it and she's happy.
cpursley•5mo ago
repo: https://github.com/agoodway/star-support-demo
bravesoul2•5mo ago
_1tem•5mo ago
forsakenharmony•5mo ago
The big issue with AI coding is that is kills the fun part of software development (actually writing code) and just becomes reviewing and understanding code you didn't write
ramraj07•5mo ago
Every line of code is tech debt, true. Every integration is orders of magnitude more tech debt. The only time an integration wasn't tech debt was when I set up new relic logging.
amrangaye•5mo ago
I’ve done several projects that would take months to complete otherwise with “vibes coding”, including: an African fairy tale generator for my daughter, a farm management system for the ministry of agriculture in my country, a Gambian political comic strip creator, a system that generates ten minutes summary podcasts of all my country’s news etc. I’ve also had great success with clients - and got them to sign on much faster - by just putting together a quick demo now that I show them instead of sending a proposal and pitch deck describing what I’ll build for them. It makes them so much more excited and we can make changes almost in realtime.
I’ve noticed a lot in the industry and even on hn, that coders - especially long time ones - tend to “look down” on vibes coding, the same way they did with scripted languages back in the day, and I imagine the same way with compilers. I think this will generally fade out as it becomes industry standard, but in the meantime sometimes I see comments on hn that are so discouraging and cynical it makes me wonder if the person actually tried it out or had just pre judged it. I also think the phrase “vibe coding” is a terrible name, cause it makes it sound like a lazy way of doing things. It’s so much more than that, and lets you think and plan at the idea level. Things like planning your system before you ask it to implement also help a lot.
ericb•5mo ago
* LLM's are lousy at bugs
* Apps are a bit like making a baby. Fun in the moment, but a lifetime support commitment
* Supporting software isn't fun, even with an LLM. Burnout is common in open source.
* At the end of the day, it is still a lot of work, even guiding an LLM
* Anything hosted is a chore. Uptime, monitoring, patching, backing up, upgrading, security, legal, compliance, vulnerabilities
I think we'll see github littered with buggy, unsupported, vibe coded one-offs for every conceivable purpose. Now, though, you literally have no idea what you're looking at or if it is decent.
Claude made four different message passing implementations in my vibe coded app. I realized this once it was trying to modify the wrong one during a fix. In other words, claude was falling over trying to support what it made, and only a dev could bail it out. I am perfectly capable of coding this myself, but you have two choices at the moment--invest the labor, or get crap. But, then we come to "maybe I should just pay for this instead of burning my time and tokens."
mccoyb•5mo ago
One technique which appears to combat this is to do “red team / blue team Claude”
Red team Claude is hypercritical, and tries to find weaknesses in the code. Blue team Claude is your partner, who you collaborate with to setup PRs.
While this has definitely been helpful for me finding “issues” that blue team Claude will lie to you about — hallucinations are still a bit of an issue. I mostly put red team Claude into ultrathink + task mode to improve the veracity of its critiques.
stpedgwdgfhgdd•5mo ago
I do not how it is implemented, but if I can press ‘continue’ from my phone, someone else could enter other commands… Like export database…