I work in Codex CLI and generally update when I see a new stable version come out. That meant that yesterday, I agreed to the prompt to try gpt-5.1.-codex-max. I stuck with it for an entire day, but by the end it caused so many problems that I switched back to plain gpt-5.1-codex model (bonus for the confusing naming here). codex-max was far too aggressive in making changes and did not explore bugs as deeply as I wished. When I went back to the old model and undid the damage it was a big relief.

That said I suspect many vibe coders in this sub might like it. I think Open AI heard the complaints that their agent was "lazy" and decided to compensate by making it go all out. That did not work for me though. I'm refactoring an enterprise codebase and I need an agent that follows directions, producing code for me to review in reasonable chunks. Maybe the future is agents that follow our individual needs? In the meantime I'm sticking with regular codex, but may re-evaluate in the future.

EDIT: Since people have asked, I ran both models at High. I did not try the Extended Thinking mode that codex-max has. In the past I've had good experiences with regular Codex medium as well, but I have Pro now so generally leave it on high.

TLDR; After extensive real world architecting, strategizing, planning, coding, reviewing, and debugging comparison sessions between the GPT-5.1 High and GPT-5.1-Codex Max High/Extra High models, I'll be sticking with the "GPT-5.1 High" model for everything.

I’ve been using the new GPT‑5.1 models inside a real project: a reasonably complex web app with separate backend, frontend, and a pretty heavy docs folder (architecture notes, AI handoffs, test plans, etc.).

My priority is correctness over speed. I wanted to see, in a realistic setting, how:

• GPT‑5.1 High compares to

• GPT‑5.1‑Codex‑Max High and

• GPT‑5.1‑Codex‑Max Extra High (reasoning)

for tasks that mix code comprehension, documentation reading, planning, and task suggestion.

This wasn’t a synthetic benchmark; I ran them against my actual repos.

Example prompt / task

Over the last couple of weeks (roughly Nov 7–21), I’d made a bunch of changes:

• Backend: new management/ops command, test suite cleanup around a previously broken feature, new “modern” tests that avoid touching a live DB.

• Frontend: refactors in some auth/consent/legal UI, tightening typing and logging, moving experimental components into a “playground” area so they don’t pollute builds, plus some routing cleanup.

• Docs: AI handoff docs updated with latest state, a detailed test‑status doc, a routing standardization plan, and TODOs for codebase mapping.

My prompt to each model (paraphrased):

“Without changing any code, analyze the changes we’ve made in the last couple of weeks and the docs we’ve written about them. Tell me:

• what we’ve accomplished,

• what we should have done differently, and

• a list of potential next tasks (near‑term and/or medium‑term).”

Each model had access to the same stuff: repo guardrails, AI handoff doc, recent git history for backend/frontend/docs, and the relevant status/plan docs.

What GPT‑5.1 High did

GPT‑5.1 High gave a longer, more narrative answer, but it was well‑grounded:

• It correctly identified the main work:

  • New read‑only management command for operations.

  • Cleaning up a previously broken feature in the backend by:

    • Marking old/legacy tests as skipped (but kept for reference).

    • Making manual “debug scripts” opt‑out of pytest so they can’t accidentally hit a real DB.

    • Adding a new “modern” test module that calls the current routes in a safe, dependency‑mocked way.

  • Frontend cleanup:

    • Removing/relocating demo/test routes.

    • Moving experiments into a non‑production playground folder and excluding it from builds/tests.

    • Aligning a contact form with backend enums.

    • Tightening types and gating noisy logging behind dev‑only checks.

  • Routing work:

    • Collapsing an old detail page into a redirect to the new canonical page.

    • Adjusting some calls to use the “canonical” route shape instead of the older alias.

  • Docs:

    • AI handoff updated with concrete “Story is resolved, new tests are here, here’s how to rerun mapping scripts, here’s how to use feature flags,” etc.

    • Backend test status doc explaining test changes and future test‑infra ideas.

    • A route standardization plan that distinguishes “pipeline” routes vs “resource” routes.

• It also talked about what could be better in a more architectural/process sense:

  • Reduce doc sprawl: mark older “current status” docs as historical and have a single always‑current status doc + AI handoff as the truth.

  • Treat code + tests + a short status doc as a single atomic unit when making changes to critical systems, instead of having a lag where the code is fixed but tests/docs still describe the broken behavior.

  • Schedule the routing cleanup as a real refactor project (with phases, tests, rollout plan) instead of a slow, ad‑hoc drift.

  • Build a safer testing infrastructure: test‑only DB configuration and test‑only auth helpers so future tests never accidentally talk to production DB/auth.

• The task list it produced was more of a roadmap than a pure “do this tomorrow” list:

  • Finish the remaining route work in a principled way.

  • Execute codebase mapping TODOs (type consolidation, invalidation coverage, mapping heuristics).

  • Undertake a test‑infra project (test DB, test auth, limiter bypasses).

  • Continue tightening the integration around the editor and a story‑generation component.

  • Improve operational tooling and doc hygiene.

It was not the shortest answer, but it felt like a thorough retrospective from a senior dev who cares about long‑term maintainability, not just immediate tasks.

What GPT‑5.1‑Codex‑Max High did

Max High’s answer was noticeably more concise and execution‑oriented:

• It summarized recent changes in a few bullets and then gave a very crisp, prioritized task list, including:

  • Finish flipping a specific endpoint from an “old route” to a “new canonical route”.

  • Add a small redirect regression test.

  • Run type-check + a narrow set of frontend tests and record the results in the AI handoff doc.

  • Add a simple test at the HTTP layer for the newly “modern” backend routes (as a complement to the direct‑call tests).

  • Improve docs and codebase mapping, and make the new management command more discoverable for devs.

• It also suggested risk levels (low/medium/high) for tasks, which is actually pretty handy for planning.

However, there was a key mistake:

• It claimed that one particular frontend page was still calling the old route for a “rename” action, and proposed “flip this from old → new route” as a next task.

• I re‑checked the repo with a search tool and the git history:

  • That change had already been made a few commits ago.

  • The legacy page had been updated and then turned into a redirect; the “real” page already used the new route.

• GPT‑5.1 High had correctly described this; Max High was out of date on that detail.

To its credit, when I pointed this out, Max High acknowledged the mistake, explicitly dropped that task, and kept the rest of its list. But the point stands: the very concise task list had at least one item that was already done, stated confidently as a TODO.

What GPT‑5.1‑Codex‑Max Extra High did

The Extra High reasoning model produced something in between:

• Good structure: accomplishments, “could be better”, prioritized tasks with risk hints.

• It again argued that route alignment was “halfway” and suggested moving several operations from the old route prefix to the new one.

The nuance here is that in my codebase, some of those routes are intentionally left on the “old” prefix because they’re conceptually part of a pipeline, not the core resource, and a plan document explicitly says: “leave these as‑is for now.” So Extra High’s suggestion was not strictly wrong, but it was somewhat at odds with the current design decision documented in my routing plan.

In other words: the bullets are useful ideas, but not all of them are “just do this now” items - you still have to cross‑reference the design docs.

What I learned about these models (for my use case)

1. Succinctness is great, but correctness comes first.

   • Max/Extra High produce very tight, actionable lists. That’s great for turning into tickets.

   • But I still had to verify each suggestion against the repo/docs. In at least one case (the route that was already fixed), the suggested task was unnecessary.

2. GPT‑5.1 High was more conservative and nuanced.

   • It took more tokens and gave a more narrative answer, but it:

     • Got the tricky route detail right.

     • Spent time on structural/process issues: doc truth sources, test infra, when to retire legacy code.

   • It felt like having a thoughtful tech lead write a retro + roadmap.

3. “High for plan, Max for code” isn’t free.

   • I considered: use GPT‑5.1 High for planning/architecture and Max for fast coding implementation.

   • The problem: if I don’t fully trust Max to keep to the plan or to read the latest code/docs correctly, I still need to review its diffs carefully. At that point, I’m not really saving mental effort - just shuffling it.

4. Cross‑model checking is expensive.

   • If I used Max/Extra High as my “doer” and then asked GPT‑5.1 High to sanity‑check everything, I’d be spending more tokens and time than just using GPT‑5.1 High end‑to‑end for important work.

How I’m going to use them going forward

Given my priorities (correctness > speed):

• I’ll default to GPT‑5.1 High for:

  • Architecture and planning.

  • Code changes in anything important (backend logic, routing, auth, DB, compliance‑ish flows).

  • Retrospectives and roadmap tasks like this one.

• I’ll use Codex‑Max / Extra High selectively for:

  • Quick brainstorming (“give me 10 alternative UX ideas”, “different ways to structure this module”).

  • Low‑stakes boilerplate (e.g., generating test scaffolding I’ll immediately review).

  • Asking for a second opinion on direction, not as a source of truth about the current code.

• For anything that touches production behavior, I’ll trust:

  • The repo, tests, and docs first.

  • Then GPT‑5.1 High’s reading of them.

  • And treat other models as helpful but fallible assistants whose suggestions need verification.

If anyone else is running similar “real project” comparisons between GPT‑5.1 flavors (instead of synthetic benchmarks), I’d be curious how this lines up with your experience - especially if you’ve found a workflow where mixing models actually reduces your cognitive load instead of increasing it.

https://www.tbench.ai/leaderboard/terminal-bench/2.0