The prompts
Paste these into omp in order, in one session or several.
They assume setup is done, approval mode included.
1 · Shakedown
Run it on a scratch repo before you touch routing.
Create a scratch git repo in ~/tmp/omp-shakedown with a small Python module (a string-formatting helper) and pytest tests. Then, in that repo: introduce a deliberate off-by-one bug, run the tests to show the failure, fix it, and commit with a sensible message. Narrate which tools you use as you go. Do not touch anything outside ~/tmp/omp-shakedown.
2 · Route the cheap roles
omp edits its own config, and you review the diff.
Open ~/.omp/agent/config.yml and set up role routing: keep my current default model for the "default", "slow" and "plan" roles, and route "smol" and "commit" to the cheapest fast model I currently have access to (list my available providers/models first and tell me which you picked and why, with its price tier). Use the modelRoles syntax with "@" aliases where sensible. Show me the final YAML before saving, then save it and confirm the roles with /model.
3 · Check which model ran each subagent
That’s where the savings are.
In the shakedown repo, use the task tool to spawn three parallel subagents: one adds type hints, one writes docstrings, one adds two more test cases. When they're done, tell me exactly which model handled each subagent and which handled this main turn. If the subagents did not run on the smol-role model, diagnose why against ~/.omp/agent/config.yml and fix it.
4 · Set up fallbacks
Do it before your first rate limit.
Add a retry.fallbackChains block to ~/.omp/agent/config.yml: a "default" chain listing my main model followed by two alternatives I have access to (prefer a different provider for at least one), and a "smol" chain with two cheap alternatives. Keep retry.modelFallback on. Show me the YAML before saving. After saving, restart-check: confirm omp starts with no config warnings — if it warns about an unknown model id, fix the id rather than deleting the entry.
5 · Get a human review
If you share the codebase or the bill, let the others pin notes on your config.
Write a one-page self-contained HTML summary of my new omp setup: which model serves each role and why, the fallback chains, any path-scoped privacy rules, and what a typical week should cost versus all-frontier (pull real numbers from omp-stats if available, otherwise mark estimates clearly). Then add the twocents MCP server: claude mcp add --transport http twocents https://twocents.page/mcp (or add it to omp's own mcp.json — .omp/mcp.json — and reload). Call share_page with the full HTML and give me the review link. I'll send it to the people who share this codebase or this bill; they can pin notes on any line — "don't send client code to that provider", "route commits even cheaper" — no login. When the notes are in, call get_feedback with the room id, show me each note, and apply the ones I approve to the actual config.
A routing config decides what code leaves your machine and whose subscription pays. Someone who didn’t write the YAML will see those choices differently.