The codex-auto-review model and why it appears

What the label means

The codex-auto-review model identifier is the name attached to the review pass, distinct from the model doing the coding. When you see it, you are looking at accounting: something in your setup ran a review over a diff, and the platform tagged that call separately so it can be metered and reported apart from your regular agent work.

That is the whole claim we are willing to make. We do not know its parameter count, its context window, or how it differs internally from the general coding models, and neither does anyone outside OpenAI. Treat any blog post that states those numbers with suspicion. What you can observe is behaviour, and behaviour is enough to work with.

What you can tell from the outside

Run the same diff through a review pass a few times and read the outputs side by side. Across the teams we have watched do this, a consistent picture shows up:

• Findings are line-anchored and narrow. It comments on a specific expression, not on the design of the module.
• It rarely proposes rewrites. It flags and moves on, which is the correct posture for a reviewer.
• Recall varies run to run. Two passes over one diff will share most findings and each will have one the other missed.
• It is more cautious on security-shaped code than on plain business logic.
• Precision falls off sharply once a diff crosses a few thousand lines.

None of that requires knowing the model. It requires ten minutes and a diff you already have.

Why the codex-auto-review model shows up on your bill separately

Most people search this term because a line item surprised them. The review runs on top of your normal usage. If you turned on review for every pull request in a busy monorepo, you added a model call per PR, sometimes per push, and each one reads the full diff.

Two adjustments cut that noticeably without giving up the value. Restrict review to the branches that matter, so drafts and dependency bumps do not trigger it. And keep diffs small, which reduces input size and improves the findings at the same time. A team we worked with in Amsterdam had a bot opening 40 automated dependency PRs a week, every one of them getting a full review. Excluding that bot removed most of the cost and lost nothing.

The mistake to avoid

Do not build policy around the model name. Names change, routing changes, and a rule in your CI that pins or checks a specific identifier will break quietly on a Tuesday. Build policy around outcomes instead: what fraction of review comments led to an edit, and did any incident in the last quarter come from something a review pass should have seen.

Also do not treat the review as an approval gate that replaces a person. It has no view of your product, your customers, or the incident from March. It reads a diff.

What to do next

Go look at your actual usage breakdown and find out how many review calls you made last month and on which repositories. Then take the ten noisiest repositories and decide, per repository, whether review belongs there. That is a 30-minute job and it is the only version of this question that changes anything.

If you want help putting this into practice, talk to us.