It started with a very simple thought:
Why not build my own terminal?
There wasn't some huge plan behind it.
I wasn't trying to replace PowerShell.
I wasn't trying to build an AI coding agent.
I definitely wasn't planning to create a workspace-aware automation system.
I just thought building my own terminal sounded cool.
So I tried.
And...
It didn't work. 😭
The First Version Was Barely a Terminal
My first attempts were pretty rough.
Eventually, though, I managed to get a basic version working.
It could accept commands, execute some things, and most importantly, I could define my own custom commands.
And that was basically the entire philosophy of the project at the time:
Custom commands.
That was it.
I loved the idea that instead of adapting myself to an existing terminal, I could slowly build a terminal around the way I worked.
Want a command for checking system information?
Add one.
Want a command for navigating files differently?
Add one.
Want some weird command that only makes sense in my workflow?
Why not?
I was genuinely happy with that little version.
So, naturally, I posted it on LinkedIn.
And surprisingly, people reacted pretty well to it.
But one interaction in particular changed how I looked at the project.
Then a C Developer Found the Project
One of the developers who came across the post worked with C.
Now, if someone spends their time writing C, there's a pretty good chance they know a lot more about low-level systems than I did when I started building this thing.
And he started commenting on RiftShell.
Not just:
"Nice project!"
It was more like:
This is good, but there's a problem here.
Then another issue.
Then another limitation.
And another thing that could have been designed differently.
😂
But strangely, I liked those comments.
They weren't random criticism. They made me think about what I was actually building.
At one point I explained:
I mainly built it because I wanted custom commands.
He mentioned aliases and some existing shell functionality that could already solve parts of what I was trying to achieve.
At the time, I didn't completely understand what he meant.
But it planted an interesting question in my head.
If existing terminals can already do custom shortcuts...
why should RiftShell exist?
That's a dangerous question to ask about your own project.
Because there are only two possible answers:
Either the project doesn't need to exist...
or you give it a reason to exist.
I chose the second one.
RiftShell Stopped Being About Custom Commands
I kept building.
One feature became another. The architecture changed, plugins appeared, the UI became more serious, and eventually AI entered the picture.
Somewhere along the way, my little custom-command terminal became RiftShell Orbit — a Windows-first AI developer shell and automation
workspace.
The philosophy changed too.
Originally:
Let me create my own commands.
Now:
Let the terminal understand what I'm working on — but never take control away from me.
From a custom shell to a developer workspace
RiftShell is still a terminal. It has multiple terminal sessions, command history, fuzzy search, tab completion, a command palette, background execution, Git commands, plugins, and more.
But now it also has Orbit, its integrated AI layer.
Orbit can inspect your workspace, understand project structures, read and review files, explain code, and propose changes.
Orbit proposing a real file modification. RiftShell shows the diff before the change is approved.
There are additional protections behind this: approvals are tied to the reviewed file state, overwritten files can be backed up under .ai_backups/, and multi-file operations can attempt rollback if something fails midway.
The idea is simple:
The terminal learned to think. You still hold the keys.
Local AI, Plugins, and Even Remote Control
Orbit currently supports Gemini, Groq, and local Ollama models, including configurable provider fallback.
RiftShell also has a plugin architecture, so functionality can grow without stuffing everything into the shell core.
And because apparently building an AI terminal wasn't complicated enough 😭, I eventually added an optional Telegram remote-control layer too.
The important part is that all of these features still go through RiftShell's controlled execution model.
Looking Back at Version One Is Kinda Funny
There was never some master roadmap saying:
Custom Shell → Plugins → Developer Workspace → AI → Safe Execution → Local Models → Remote Automation
The original plan was basically:
"It would be cool if I could make my own commands."
That's it. 😂
Then someone questioned why the project needed to exist when existing shells already had things like aliases.
That question ended up being surprisingly useful.
Instead of abandoning RiftShell, I kept asking:
Okay... then what should this become?
And that's how my tiny custom-command terminal slowly became RiftShell Orbit.
It's still evolving, and I genuinely don't know what it will look like several versions from now.
That's probably the fun part.
If you're into terminals, developer tools, local AI, automation, or agent safety, RiftShell is open source — and criticism is welcome.
Apparently, that's how this project gets new features. 😭
Top comments (0)