oah helps you build an AI development workflow that fits you and keeps changing as AI improves. It is a working reference and a guide you can adapt.
A useful result needs more than generated code: the scope must be clear, the changes checked, and decisions kept for the next session. oah connects those steps so one request can carry through the work with a record of what happened.
002 / Why it keeps changing
Older rules and skills can hold a newer model back or make its results worse. Defaults should be easy to understand and change; a rule that gets in your way is a design problem to fix.
Keep the parts that help, remove what no longer helps, and revise the workflow as your tools improve. You can start with the full setup or take only the impact map, wiki, leases, evidence gates or review loop that your project needs.
003 / Why Claude builds and Codex reviews
This split comes from the author's own experience, not a measured comparison: Claude fills in details a beginner might miss in a first version; Codex checks and corrects within a fixed scope.
The current commands run Claude Code and Codex CLI. The ideas can also be adapted to another tool or harness, with one AI or several. Give each stage to the AI that suits your work.
004 / From one request to a checked change
Describe the result you want in plain language. The AI records the goal and scope, checks what the change touches, reserves its paths and chooses the tools for the task. Claude builds; Codex reviews, corrects and reviews again.
Gates record the checks and their results. The project wiki keeps the decisions and reasons beside the code. In v0.3.0, optional TypeSafe Jev can judge difficulty for model selection; rules remain the fallback when it is unavailable or uncertain.
005 / The decisions stay with you
You ask, answer when the AI needs a decision, and confirm before the change lands. If the same problem repeats or the work reaches a design choice, the loop stops to ask you.
Ask “Is the review done?” or “Did all the gates pass?” and inspect the evidence. The final confirmation belongs to you; writing code, checking it and approving its landing are separate steps.
006 / Free, open source, yours to adapt
oah is free, open-source software under the MIT license. Read the source, change it and bring the useful pieces into your own workflow. Your AI services and any optional services use their own accounts and billing.
The current v0.3.0 release supports macOS and native Windows, and expects familiarity with git and pull requests. Install it, run oah init in your project, then try the small hello-oah example. The installation and documentation sections explain each step.
Each task gets a tier — low, medium, high or max — and the tier picks the model and reasoning effort for each engine. Readable rules score four axes: kind, intensity, reasoning and risk. Effort is verified and never lowered silently, optional tier pools list models you have checked, and every run records where its tier came from.
When you need it
Running every task on the same model and effort either spends the strongest model on trivial edits or sends risky work to a weak one, and afterwards you cannot tell why a model was used.
How it works
Rules score kind (for example docs, implementation, migration), intensity, reasoning and risk; oah recommend shows the score. Risk critical means max, and a migration or security task is at least high.
oah packet new writes the stage routes into the packet's ## Plan. It has no --tier option; edit the generated plan to change a packet's tier.
oah call uses the packet's stage tier, otherwise the rules; a call-time --tier overrides that choice for the run without rewriting the packet.
A tier's effort is a level the engine lists for the model, and highest means the top level Codex lists. A lower launch effort fails with OAH_EFFORT_DOWNGRADED; an effort that cannot be observed, such as Claude Code's, is recorded as unverified.
Optional [engines.<engine>.tier_pools] list the models you have checked for each tier; that tier runs the first one the CLI lists. oah never edits your pools.
Each run record keeps the axes, the tier and its source (rules, packet, flag or jev), and the requested and effective model and effort.
Example
The plan line `oah packet new` printed in the worked example: engine and tier per stage.
OAH_PACKET_CREATED .oah/tasks/hello-name/PACKET.md
plan: initial → claude → medium; review → codex → medium; correction → codex → medium
Requirements
Claude Code and Codex CLI that report their models. oah models shows, and with --refresh rereads, the model each tier uses.
Optional: a pinned model per tier, tier pools and effort_caps in .oah/config.toml; the upgrade notes say these keep their meaning.
Limits and recovery
Without a Jev key, difficulty stays a count of files and paths, so a one-line concurrency fix can score low and a 20-file rename high.
When Codex has not reported reasoning levels, a highest tier refuses with OAH_EFFORT_METADATA_MISSING instead of guessing; an effort the model does not list gives OAH_EFFORT_UNSUPPORTED.
A pool that names no model the CLI lists gives OAH_MODEL_UNRESOLVED.
v0.3.0 uses benchmark scores for automatic model choice and optional Jev judgement for difficulty.