Cards and OpenAI Codex — a comparison

Cards is honestly about guiding and checking, through a durable per-job work object that survives sessions; Codex is honestly about starting and checking, through a parallel agent workspace with automated review. Cards fits a developer whose constraint is lost intent and expensive re-entry; Codex fits a developer whose constraint is generation throughput and a saturated review queue. They compose: Cards is one of the surfaces that can launch Codex, and Codex is one of the harnesses Cards launches.

The companion piece to the Cards formula notes lays out person-and-agent work as a pipeline with five steps: starting new attempts, guiding them, checking them, fitting them into the larger project, and sometimes approving them through a real authority gate. Three more things shape the result: how many attempts become accepted work, how much accepted work holds up later, and how much cleanup the workflow creates. This page compares Cards and OpenAI Codex pipe by pipe without ranking them. In the ontology of agent control systems, Codex is an interactive agent workbench and background delegation engine with its own harness, parallel execution modes, and an automated verification stage; Cards is a control-artifact and memory-continuity system wrapping a single coding-agent job. The operator for both is a professional software developer. For Cards the unit of work is one coding-agent job; for Codex it is a thread that produces a candidate change.

Cards is a VS Code extension for building with coding agents from plan to commit. For one coding-agent job — a bug fix, a feature, a cleanup, an investigation — it keeps a durable work object on disk: the description, one or more plans, comments and attachments, the sessions and transcripts that ran, the commits that landed, the changed files, and an attribution map of what the job touched against the current codebase. The developer shapes the plan on the card, launches a configured agent from the card's context through an action, and returns to intent and actual work together. Cards does not run the agent — the harness and model provider do. But it is not a passive notebook either: its default configuration ships actions and skills that direct how the plan forms, how it is stress-tested, how the implementation is checked, and how the change merges. The boundary is execution, not direction. Cards directs and organizes the job; the harness and model run it.

Codex is OpenAI's coding agent, delivered as a CLI, an IDE extension, a desktop app, and a cloud surface, currently driven by GPT-5.5, described in May 2026 as the strongest agentic coding model to date. The desktop app is positioned as a command center for agentic coding, with built-in worktrees and cloud environments where agents work in parallel across projects. Codex reads and edits files, runs commands, uses computer use to operate macOS apps and an in-app browser to verify rendered UI, runs subagents under a multi-agent configuration, persists multi-step Goals across sessions, wakes scheduled thread automations, and runs an automated reviewer over its own output. Codex is the agent: it does the work.

Cards is organized around keeping one job intelligible from plan to commit. Codex is organized around running many threads of work in parallel and reviewing them. One of the harnesses a Cards action can launch is Codex; one of the surfaces that can run Codex is a Cards-launched action. The comparison below is therefore mostly about composition, not rivalry.

Starting is the act of getting an attempt into the pipeline at all. The two products move different things here.

Cards' effect on starting is about seriousness, not speed. The default intake interview draws a vague intent into a written description and an explicit plan before any agent time is spent. Fewer half-formed ideas get past the front door; the ones that do arrive with a scoped definition the agent and a later reviewer can both read. The ontology layer is the Control Artifact layer: Cards converts intent into a plan artifact before execution. It does not raise the raw rate at which attempts can be launched, and has no answer for a team whose limit is hosted compute or how many parallel agents it can pay for.

Codex moves the opposite quantity. It is built to launch many attempts at once: threads in the CLI, IDE, and desktop app, cloud threads that clone the repository and run independently, subagents that fan out under the multi-agent configuration with path-based addresses, and scheduled automations that wake threads without anyone asking. The ontology layer is the Execution Mode layer, spanning interactive local, background local, and remote collaborative execution. The raw number of attempts a developer can start per period rises sharply. Codex does not decide which attempts are worth starting or sharpen a vague prompt before it consumes agent time; usage limits and per-token cost govern how many cloud threads a team can actually sustain.

The two effects compose and do not contend for the same pipe. A Cards intake interview produces a description and plan; a Cards action launches Codex against that context; the attempt starts with a clear definition and runs on a parallel agent. If the constraint is generation throughput, Codex addresses it; if it is vague specifications entering the pipeline, Cards does. Neither substitutes for the other here.

Guiding is the work of telling the agent what to do, correcting it, and re-entering after stepping away. This is where Cards has its strongest claim.

The card holds the description, the plan sequence, the comments and attachments, and the running attribution map. When the developer returns after a meeting, a handoff, or a week away, the picture is on disk, not buried in a chat transcript that may have compacted. The per-attempt cost of re-entry drops: the developer reads the card instead of reconstructing it, a reviewer reads the intent without interrupting the author, and the next session's agent needs no long re-explanation. The ontology layer is Memory and Continuity: durable local state that persists independently of any agent session. A smaller effect lives on the Attention and Supervision layer — the card is an ordinary file, glanceable on a second monitor without opening the heavy editor — but this is same-machine only, with no phone app or shared dashboard.

Codex reduces the per-thread setup cost differently. Skills package reusable workflows, AGENTS.md files carry project conventions, memories carry preferences forward, persisted Goals keep a multi-step objective alive across sessions, and the IDE extension automatically sends open files and selection context with each prompt. These are genuine reductions, but the carrier is the agent's own configuration and memory, not a human-readable work object an independent reviewer can open. The tension is structural: Codex encourages parallel threads — the desktop app shows them side by side, subagents fan out, automations wake on a schedule, and approval prompts from inactive subagents surface while the developer is on the main thread. The ontology layer is Attention and Supervision, moved in two directions at once: lower cost per thread, more threads demanding attention. For one or two focused threads the per-thread saving dominates; for a wide fan-out total steering demand can rise faster than the saving. Codex does not flag stale Skills or AGENTS.md; it follows whatever is on disk.

The two are complementary, not redundant. Codex lowers the cost of steering a thread it is running; Cards lowers the cost of re-entering the job that thread belongs to, and carries the intent that the Codex configuration does not preserve in human-readable form across a handoff to a different person.

Checking is verifying that the work is correct before it counts. Both products have a real claim here, and they share the most important risk in this comparison.

Cards lowers the cost of an independent human check by putting the description, the plan written before the work, and the running attribution map next to the diff. A reviewer judges whether the work meets its intent without scrolling a transcript or guessing what the change was for, and the attribution tree shows which files moved across the project. The ontology layer is the Control Artifact layer: Cards makes the verification inputs more informative without performing the verification. Its advisory markers — plan approved, ready to merge — are exactly the danger. A reviewer can click a marker the agent drafted the contents for without checking the substance: rubber-stamping, where the record says checking happened when it did not. Cards makes work look checked while leaving it unchecked unless real independent verification — tests, an outside reviewer, an evaluation system — sits behind the markers.

Codex contributes automation. The CLI reviews the working tree, an automated reviewer can be triggered against a GitHub pull request, and the desktop app has a review pane with inline comments and staging. As of 2026 Codex also routes eligible approval prompts through a reviewer agent before the request runs and shows an automatic-review item with status and risk level. Rather than take a vendor benchmark's word for review quality, the way to judge it is to trigger Codex's automated reviewer against a real pull request in your own repository and see whether it catches the class of regression your team actually ships. The ontology layer is the Verification and Adjudication layer: Codex produces review results directly. Its dominant failure mode is the same in shape as Cards': the model that wrote the code also reviews it, so a bug it systematically produces is one it is likely to systematically miss, and a developer who sees review passed may skip the human pass that would have caught it.

The contrast is what each contributes toward making checking real. Cards contributes the structure for an independent check — intent stated before the work, a map of what changed, a record an outside reviewer can read without trusting the producing agent. Codex contributes automation that runs at scale before a human looks. They compose: Codex's automated reviewer as a first pass, the Cards card as the substrate for the human second pass. Neither removes the rubber-stamping risk; both name it.

Fitting in is merging a finished piece into the larger project without breaking adjacent work. Both products make a modest claim.

Cards provides the attribution tree, which shows at a glance which parts of the project a job touched, so collisions with other in-flight work surface earlier than at merge time, and it defaults to an isolated working copy per card. Codex provides built-in worktrees in the desktop app, cloud environments that clone the repository into isolation, and a review pane that stages, commits, and pushes. The ontology layer for both is Delivery and Integration, entered with limited scope: Cards contributes visibility, Codex contributes execution support. Neither addresses merge-conflict resolution, dependency coordination, or release sequencing.

The high-concurrency warning applies to both and is sharper for Codex, whose design pushes parallelism hardest. Worktree and clone isolation prevent local file collisions but not semantic conflicts where two changes pass their own tests and break when combined. Cards warns the same way about running many cards at once. Neither has tooling to detect or manage the nonlinear rise in integration cost as thread or card count grows.

Approving is a recurring authority gate where a separate party must formally sign off on each piece of work. Neither product makes a real claim here, and both are explicit about it.

Cards has no approval queues, no audit trail for outside reviewers, no role-based controls, and no hosted dashboard; the card lives on the developer's machine and the markers are advisory, with one narrow exception treated as a real rule for the final merge marker. Codex deprecated its blanket auto-approval in favor of explicit permission profiles and sandbox controls that bound what the agent may do on the machine — file writes, command execution, network access — and its 2026 reviewer-agent gate screens eligible approval prompts before an action runs. These protect the workstation and bound autonomy; they are not formal sign-offs on the work itself, and Codex has no policy-owner dashboard or enterprise identity integration for per-work authorization. The ontology layer is Authority, Identity, and Trust, where both products are minimally present. If a team's binding constraint is a recurring formal authority gate, neither product is the answer.

Cards lifts the accepted fraction by filtering before execution: the intake interview keeps vague ideas out of the pool, and attaching the description and plan removes context-loss rejections, where work is sent back not because it is wrong but because the intent was illegible. Codex lifts it by filtering after execution: better steering through Skills, AGENTS.md, memories, and Goals produces fewer obviously wrong threads, and the automated reviewer catches bad candidates before they reach the acceptance stage. Codex's own parallel generation pushes the other way — a cloud thread launched on a vague prompt and left unattended, or a subagent surfacing irrelevant findings, produces plausible output that misses the requirement.

The structural difference is where the filter sits. Cards filters the specification before the agent runs; Codex filters the output after it runs. A team using both gets both filters: fewer poorly specified attempts enter, and fewer well-specified but poorly executed ones survive.

Cards helps durability by keeping the reason for the work attached to the record, so a change is less likely to be undone for the wrong reason, and the attribution map answers whether a change is still in place a month later without forensic work. Codex helps durability through review: code reviewed even by the same model is less likely to ship obvious bugs, and the backward-compatibility claim is relevant if the reviewer genuinely catches problems that would otherwise cause a revert.

Both share the same limit. Durability failures caused by shifting requirements, wrong assumptions, or solving the wrong problem are not caught by either mechanism. Cards cannot tell that a plan's assumptions have aged out, and its signal to re-confirm a stale plan only helps a team that honors it. Codex has no visibility into causes of low durability that live outside the diff.

Both products reduce cleanup in some directions and create it in others, and both carry the same dominant risk on the checking step.

Cards reduces cleanup through dedicated agents that look for failure modes in plans and implementations before they cause downstream work, and through the on-disk record that makes rescue of a stuck job faster. It creates cleanup when advisory markers replace real verification: half-checked work merges, fails later, and someone unwinds it. In real use this is usually the dominant effect on cleanup unless real independent checks sit behind the markers.

Codex reduces cleanup through review that catches bugs before merge, worktree and cloud isolation, and automations that proactively find issues. It creates cleanup through abandoned cloud threads that leave state behind, subagent outputs that need triage, scheduled-automation findings that accumulate as low-signal backlog, and the same self-review rubber-stamping pattern. For both, the honest summary is identical: cleanup falls when the team keeps real independent verification behind the automated and advisory signals, and rises when it treats those signals as a substitute for independent judgment.

Cards' honest claim is guiding and checking, through a durable per-job work object that survives sessions and makes re-entry and independent review cheap, with smaller effects on starting, fitting in, accepted yield, and durability, and nothing on approving. Codex's honest claim is starting and checking, through a parallel agent workspace and an automated reviewer with differentiated model capability, with a narrower effect on guiding and a modest one on fitting in. A team whose narrowest pipe is generation throughput or a saturated review queue should reach for Codex; a team whose narrowest pipe is lost intent and expensive re-entry should reach for Cards. They are designed to be used together: a Cards action launches Codex from a job's context, and Cards keeps the work readable around the run that Codex performs.

Adopting Cards costs one VS Code extension install; it does not ask you to leave Codex or migrate anything out of it — in fact, a Cards action can launch Codex directly. Cards runs on your existing local Git repository with no daemon, no account, and no code uploaded to a new service; card data lives locally at `~/.cards/cards-repos/<card-id>/`, alongside your repository rather than inside it, so there is nothing to import from Codex and nothing Codex produced that has to be rebuilt to use Cards. Uninstalling Cards removes the extension; your repository and git history are unaffected either way. There is no formal side-by-side trial program.