AI agents with two brains: ChatGPT thinks, Codex builds

A GitHub repository collected more than two thousand stars within days, and its name is the manual: codex-with-chatgpt. The division of labor reads: ChatGPT thinks, Codex builds. The question is not whether it works but why, and what that means for a one-person operation on a 45-euro phone. My answer is context hygiene. This pattern has already produced two projects in my setup whose test suites passed in full, 36 of 36 tests. The number documents verified results of the workflow; whether the role separation caused them stays open without a control run. Below: the mechanics for AI agents, what local really means here, the cost recalculation, and a complete handoff example from my own roles.

XiaoDuoYa/codex-with-chatgpt separates two roles that otherwise collide inside one agent. The planner receives the task, breaks it down, and passes instructions on. The builder executes them, writes code, and runs tests. The repo description puts it in one line: ChatGPT thinks, Codex builds. The mechanics are unspectacular, which is exactly why they work. A model that plans and builds at the same time fills its own context with error messages, stack traces, and files it has read, and at some point that crowd pushes the original plan out. Keeping the roles apart keeps two contexts apart, and both stay small enough to remain functional. No new miracle, just clean craft that enough people are relearning for GitHub to celebrate it.

The role split deserves a closer look, because the repo name sounds more impressive than the technology. Codex is OpenAI's coding agent and, per the vendor's own documentation, runs on several surfaces: a command-line tool, an IDE extension, the web, and the desktop app. In every variant the program is the tool side working on assignment. The planning brain in the repo is a cloud model with its own context window that formulates orders and evaluates results. That two-stage architecture is the substance of the trend, not the brand of either tool.

I do not have to speculate here, I can show it. In my stack, Hermes plans the tasks, the pi agent builds, Hermes verifies. Two projects came out of that workflow, and both passed their test suites in full. The Network Obfuscation Layer, a Python proxy rotation system, reached 29 of 29 passing tests; the Preiskompass, a reselling monitor with an SEO blog, reached 7 of 7, together 36 of 36. Those 36 refer to the respective test suites of the two projects in their versions of August 30, 2026, not a general seal of quality for future revisions. I wrote none of the code, I orchestrated: broke the task down, worded handoffs, checked results against the acceptance criteria.

One term needs precision here, because I used it too generously in the previous version of this post: the stack does not run entirely locally. The host runs locally, a used Google Pixel 6a acting as compute and control unit, and the planning runs in the cloud on a rented model. Anyone comparing such stacks should draw this line cleanly, because it decides cost, privacy, and failure behavior. The trend repo has the same property; there too a cloud model thinks and a local tool builds. The difference between the two variants is not the architecture but the parts filling the roles.

That the trend does not stand alone shows the surroundings: a de-AI writing skill called sepia collected 1,912 stars in the same span, and a measurement across 17,000 agent runs shows big coding agents keep picking simple tools like grep when offered. The market is sorting itself toward simple, proven components, not more magic. This observation is secondhand, the Armature report is linked in the sources block, and I did not evaluate the 17,000 runs myself.

Abstractions pay off once you see them concrete, so here is the structure of a real handoff from the Preiskompass build, reconstructed from the original records. The planner receives the task in three parts. Part one, the goal: a script that queries price data from a product page, normalizes it, and writes it into a table. Part two, the limits: no changes to files outside the project, no new dependencies without justification, no network calls outside the given domain. Part three, the acceptance criteria: the script must run on a sample file, must handle three defined edge cases, and the test suite must pass.

The builder gets exactly this note and returns three things: the changed files with a short reason per change, the test suite output as plain text, and a list of the cases it did not touch. That third return is the underrated part, because it lets the planner verify without repeating the build. Verification runs as its own check against the acceptance criteria, not as the builder's summary in the builder's own words. Only after that check passes does the job count as done. In my workflow this happens over a fixed protocol, in the trend repo over the descriptions of the participants. The pattern is the same: whoever verifies sees the task, not the self-report.

Plenty gets written about intelligence, rarely about invoices. My real numbers from the live dashboard, as of September 4, 2026: 1,200 requests used, 41.2 percent of the weekly limit, the five-hour window at 45 percent. My legacy plan counts requests and not tokens, and that is precisely why clear role separation here is not a design question but a budget question. Scripts handle the mechanics without a single call; I buy requests only for judgments. The documented single measurement: fetching and processing a complete 54-minute video costs about 0.5 percent of the window, because the script share never sees the model.

Whoever bills in tokens instead, or on top of that, needs the vendors' comparison figures, and the same separation applies as with the roles: dashboard values and official price lists are different sources. The official lists for the models involved sit in the sources block, and my choice of a primary model is derived from those plus my own usage pattern, not from a general superiority claim. Which model fits which price-performance window depends on your own request pattern, and you should know that pattern before you compare anything.

The stack runs on a used Google Pixel 6a that cost 45 euros. The hardening of August 28 last held on September 4, 2026: 88 hours in a row without interruption, zero out-of-memory kills since the hardening, a 99 percent survival rate over seven days, measured with 170 of 171 checks in the snapshot log. These numbers prove the host carries the workload, not that the architecture works everywhere. That is why this section is worded narrowly: it reports the observation that orchestration with separated contexts works on a small device, not a general superiority claim over other setups. A comparison against a laptop or desktop stack would be a different test, and I have not run it.

Four things need saying plainly. First: the repo is ten days old and I have not audited it. I checked the star count, the creation date, and the description via the GitHub API, nothing more. Whoever deploys it reads the code themselves. Second: the result of 36 of 36 tests is evidence for my stack in this version, not a general market claim about multi-agent architectures. Third: the 2,422 stars show interest, not quality, and sepia's 1,912 stars deserve the same reading. Fourth: the stability figures come from my own snapshot log and apply to this device and this period. Whoever wants to reproduce the numbers finds the method in the stack post, not in this one.

About the author: I run the HUNTER cyberdeck. I am Marcel, a graphic designer and the operator of the d4sn3st sites. Since 2026 I have been building with AI agents, orchestrating instead of typing, and documenting my figures openly on the blog. This post rests on the stability snapshots and daily notes from August 28 to September 4, 2026, and the GitHub checks I ran through the public API. Last fact-checked on September 5, 2026.