DeepakNess

Setting Up and Testing OMP (Oh My Pi) Agent

I wrote about setting up Pi a couple of months ago. I still use Pi, but less than before – my daily driver these days is Grok Build, as noted on my AI stack page. I recently discovered OMP (Oh My Pi) – a different terminal coding agent based on Pi – and I have been liking how it works so far. I am still testing it, but one thing I really like is how it lets my model services work together instead of competing.

DeepSeek v4 Flash does the everyday work, and Grok 4.5 handles vision and planning. Nemotron 3 Ultra is my secondary model, waiting in the fallback chain so a rate limit never stops a session.

Here's how it works.

The problem

I use two model services:

The problem was never "which model is best". The real problems were using all of them without manually switching models every few minutes, and keeping long sessions alive when rate limits hit.

Model roles

OMP has a model roles feature where instead of configuring one model, you configure a model for each role in the config file:

Role What it does
default The main model that does the actual work
plan Used when a task needs planning first
slow The heaviest model, for the hardest problems
task Subagents – the model used when work is delegated to parallel agents
smol / tiny Lightweight tasks like titles and commit messages
vision Image analysis
designer UI and design work
advisor A second model that watches every turn and can interrupt with concerns

Each role also takes a thinking level: minimal, low, medium, high, xhigh, or max. So "use DeepSeek for everything, but with different thinking effort" is literally a few lines of config. The complete list of roles lives in the settings documentation under modelRoles.

My current setup

My global config at ~/.omp/agent/config.yml maps roles to models:

modelRoles:
  default: deepseek/deepseek-v4-flash:max
  plan:    xai-oauth/grok-4.5:high
  vision:  xai-oauth/grok-4.5:medium
  tiny:    deepseek/deepseek-v4-flash:high
defaultThinkingLevel: max

DeepSeek v4 Flash is the default because it handles most of my work fast and cheap, with max thinking. Grok 4.5 handles planning and looks at images, since DeepSeek is text-only. And lightweight one-off calls like titles also go to Flash.

I started with separate profile files pinned per project – a shell function that copied a profile from ~/.omp/profiles/ into each project's .omp/config.yml. It worked, but I settled on a single role-based config instead. The roles cover the switching I actually need, and one global config is easier to maintain than a profile per project.

The advisor

OMP also has an advisor role – a second model that reviews each completed turn and can interrupt with a concern if the main model is about to do something wrong. I used exactly that when I started, with a stronger model supervising a cheaper driver.

My current config has it off:

advisor:
  enabled: false
  syncBacklog: "off"
  immuneTurns: 3

It's a single toggle, so it's easy to bring back when I want a second set of eyes on a session.

Approval mode

I run everything in yolo mode – all commands and edits are auto-approved, no permission popups. I know most people would hate this, but it works for me for two reasons: I review every diff before committing, and the sessions are easy to redo if something goes wrong. The approval modes are worth reading before you decide.

Approval policy is a global setting – role configs only set models, so safety policy stays the same everywhere.

Fallback chains

Rate limits come with the models I use most, and I have hit them during long sessions – the session would have stopped dead if OMP didn't handle it. So Nemotron 3 Ultra sits in a fallback chain as my secondary model, ready when the primary fails:

retry:
  fallbackChains:
    default:
      - opencode-zen/nemotron-3-ultra-free

When the active model fails or exhausts its limits, OMP automatically retries and then moves down the chain instead of stopping. The session keeps going, and once the primary model is available again, it switches back. I have had long sessions survive rate limits this way without touching anything.

Final thoughts

OMP is still in its testing phase for me. Pi still has its place, mainly for side projects, and I have been using it regularly. So far, here is what I like about how OMP works:

The best part is that this is all config files – no product decision locked me in. If DeepSeek, Codex, or any other provider releases something better, I can switch to it with one line in the config. If I want a project to behave differently, I can change a role or pin a different config.

I will keep updating this post as the setup changes.

Comment on Mastodon