I believe this is the popular "batteries included" kit: <a href="https://github.com/can1357/oh-my-pi" rel="nofollow">https://github.com/can1357/oh-my-pi
I know that's the way omp is often introduced but I don't think it's fair for either omp or pi - after lately switching my usage more towards omp I'd say by this point they're almost more different than Pi and Codex. And I like them both.
Yeah I just gave it a run and it starts off burning 6% of my tokens on start.
Pi sits at 0%.
I'm so use to the command keys in Pi that having to type something out in OMP slows me down. I'll stick with Pi, I've built it to my needs and having WSL finally working. I still have to run 2 CLIs, one for LLama.ccp and the other for Pi, not sure if this is normal.
OMP provides a significant amount of structure to the work. That costs some tokens in terms of the system prompt. When I use these systems, I balance the return of the extra guidance in the system prompt with the cost of the context. You've talked about how much context it takes, but you haven't talked about any difference in behavior.
omp offers some nice tools, like /shake, to manage context efficiently and offset some of that consumption.
Not sure about your point with command keys. OMP has all kinds of shortcuts and is highly configurable. It seems very unlikely that you cannot achieve what you're looking for in OMP in terms of shortcuts. Specifics would be immensely helpful here.
And yeah, you'll need to run your inference engine separately from your harness, for the same reason the web server and the web browser are different applications.
That the "batteries included" bit, but it's not "burning tokens" in the sense that using Pi with the same batteries would (of course) use just as many. I can strongly recommend omp.sh if you just want to be up and running without hassle and a far better (for me) developer experience.
Yeah, saying it kills the minimalist bit misses the point of omp being a separate project. It took a minimalist-base of pi and added tools that make it usable out of the box. Hence batteries.
One example here is that it added MCP extensions to make the harness usable with MCP servers long before Pi figured out that that was the right move. A lot can be said about development of MCP over that timeframe, but I appreciated the bias towards adoption, since progress is driven by empirical experimentation rather than theory in this domain right now.
I've long championed assembling developer tools yourself from scratch and I've been an advocate of vanilla Emacs and customizing it yourself as an ideal developer experience (I realize this opinion is controversial). But OMP is essentially the VSCode to pi's Emacs.
I ended up choosing omp as my daily driver, mostly because I see the velocity of change in AI development being far too fast for me to make a worthwhile investment into customizing the environment myself, since that investment will have a relatively short half-life. With Linux, which I learned more than 30 years ago and still believe to be a fantastic investment, I can largely use the same knowledge I gained then to administer systems today. I fear that much investment in the specific tools that I add to my pi harness will expire before 2027. So I'm sort of drafting OMP until things settle down.
I am wondering what use people get out of this. What I like about pi is that, using proprietary harnesses to begin with, I already somewhat know what kind of features I use and features I wish I could use. Asking pi to self modify itself (with a smart enough model) is a one time cost for a fully vetted feature that I personally approve. Do users of OMP find all of its additions useful?
Yeah, Advisor and "time-travelling rules" (TTSR) work great (they're injecting corrective prompts automatically either via another critic LLM or a bunch of regex rules, respectively)
It automates a lot of the babysitting of agents, and lets me use a couple of smaller models with safeguards instead of burning tokens on a galaxy brain just because it listens to instructions in AGENTS.md.
It’s the same kind of people that would use omz, they probably have no idea what 90% of the batteries are or do. But it sure makes them feel smart and cool.
wasting_time · · focus · HN ↗
personjerry · · focus · HN ↗
jLaForest · · focus · HN ↗
bayesianbot · · focus · HN ↗
mcast · · focus · HN ↗
xboxnolifes · · focus · HN ↗
arcanemachiner · · focus · HN ↗
Hell, some extensions could theoretically lower your token burn. (Like rtk, if it actually worked.)
miroljub · · focus · HN ↗
agentdev001 · · focus · HN ↗
ZeWaka · · focus · HN ↗
kelnos · · focus · HN ↗
miroljub · · focus · HN ↗
But you want to forbid those people from driving.
Do you work for Anthropic?
arcanemachiner · · focus · HN ↗
I have another one that allows you to edit the items in your Pi /tree history.
Some permission manager extensions also sit between the model and the harness, and don't actively change the tool or prompt info.
I probably have more, but you get the idea.
razster · · focus · HN ↗
I'm so use to the command keys in Pi that having to type something out in OMP slows me down. I'll stick with Pi, I've built it to my needs and having WSL finally working. I still have to run 2 CLIs, one for LLama.ccp and the other for Pi, not sure if this is normal.
rpdillon · · focus · HN ↗
omp offers some nice tools, like /shake, to manage context efficiently and offset some of that consumption.
Not sure about your point with command keys. OMP has all kinds of shortcuts and is highly configurable. It seems very unlikely that you cannot achieve what you're looking for in OMP in terms of shortcuts. Specifics would be immensely helpful here.
And yeah, you'll need to run your inference engine separately from your harness, for the same reason the web server and the web browser are different applications.
CharlesW · · focus · HN ↗
rpdillon · · focus · HN ↗
One example here is that it added MCP extensions to make the harness usable with MCP servers long before Pi figured out that that was the right move. A lot can be said about development of MCP over that timeframe, but I appreciated the bias towards adoption, since progress is driven by empirical experimentation rather than theory in this domain right now.
I've long championed assembling developer tools yourself from scratch and I've been an advocate of vanilla Emacs and customizing it yourself as an ideal developer experience (I realize this opinion is controversial). But OMP is essentially the VSCode to pi's Emacs.
I ended up choosing omp as my daily driver, mostly because I see the velocity of change in AI development being far too fast for me to make a worthwhile investment into customizing the environment myself, since that investment will have a relatively short half-life. With Linux, which I learned more than 30 years ago and still believe to be a fantastic investment, I can largely use the same knowledge I gained then to administer systems today. I fear that much investment in the specific tools that I add to my pi harness will expire before 2027. So I'm sort of drafting OMP until things settle down.
rurban · · focus · HN ↗
ZeWaka · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
orsorna · · focus · HN ↗
pornel · · focus · HN ↗
It automates a lot of the babysitting of agents, and lets me use a couple of smaller models with safeguards instead of burning tokens on a galaxy brain just because it listens to instructions in AGENTS.md.
alostpuppy · · focus · HN ↗
pornel · · focus · HN ↗
what · · focus · HN ↗