It all began when I tried Codex CLI. It was good. It did what it had to do. However, I was afraid of being locked into a single vendor’s tooling. The only other tooling that I’ve been religiously locked into is Jetbrains’ suite of IDEs.
Then came Codex’s usability. For the most of us, we run it in a dangerous manner, permitting it to run all commands, and modify all files. A colleague once bragged to me about how fast Cursor’s Composer was, and it immediately struck me that it was so fast, that even if it took your SSH key and used it to gain access to a private server, you’d never know. Its output flew up the console!
Knowing the raw power of these LLMs, it became evident to me that in order to utilise them effectively, I was going to have to:
- Ditch the CLI – we’re not in the 90s anymore, and I’ve done my fair share of configuring Gentoo Linux and the Linux kernel during my university days
- Have a tool that’s model agnostic, and not tied to a specific vendor.
- Ensure that it’s secure, so that I could sleep without worrying (agents can safely run all night long if they need to)
Enter OpenCode
After some research, I came across OpenCode, and instantly fell in love with it. I could deploy it on my remote server, run it in a Docker container, and apply a network firewall. Things were honestly great!
Soon, I started stumbling upon certain issues. Things like:
- Broken subagent delegation (this is genuinely hard, I will follow up on this post in the future. Stay tuned!)
- Broken terminal experience
- Absolutely zero handoff when moving from the browser on my Mac, to my iPhone
- Long sessions refused to reload completely, and in certain instances, sending new messages to a session would simply disappear
With these growing frustrations, the largest kicker was yet to come, when they swiftly changed the entire web UI, and tabled support for worktrees to a follow up version. WTF?
The Birth of Jupiter
I had had enough. After building what seemed like an easy agent orchestrator at CleverTap, I took it to the next step. What if I build my own agent harness, that addresses all the flaws of the current harnesses, and open source it?
Over the course of three months, I did toyed around with this idea, and shortly after two months, Jupiter became my goto IDE. I dropped OpenCode entirely in the last couple of weeks, as Jupiter was at par, and allowed me to build features that none of the current harnesses had. Simple things like:
- Keeping a Git worktree up to date automatically (goodbye manual git pull!)
- Checking out and existing branch into a new Git worktree
- A true handoff between any browser (if I pull up Jupiter on my phone, it lets me pick up exactly where I left it on the Mac. Same session, terminal state, current project selection, etc)
- Configurable environment variables
- Easily configurable agent lifecycle hooks to plug in notifications upon work completion
- And a lot more!
What Lies Ahead
Now that I’ve begun using Jupiter on an hourly basis, I’d like to see where it goes. Would other engineers fall in love with it?
Would it become the next preferred agentic IDE that everybody hosts?
This is just the beginning. There’s a lot more to come into Jupiter. During this journey, I’ll be posting some learnings, and thoughts along the way. Watch out for more posts around building Jupiter soon!
If you’d like to give Jupiter a shot, or explore its features to see what it looks like, see its GitHub repository here: https://github.com/judepereira/jupiter
Leave a Reply