OpenAI Tells Developers to Trim Their Codex Instructions

The guidance was written by Eric Provencher of OpenAI's Codex team. He wrote that "with more capable models, what used to require a lot of handholding and scaffolding no longer does." The point of the post is that every model release has been worth revisiting those assumptions and this one especially so, and the things to revisit fall into three groups: skill files, repository rules and the prompts written for each task.

The first target is the skill description. A skill is a bundle of instructions written in a Markdown file, and its name and description are loaded whole into the model's context so it knows when to reach for it. When descriptions run long and skills pile up, Codex starts shortening them, and the model has to choose while seeing less of each one. Instead of a broad description such as "use when working with databases, queries, models, or persistence," OpenAI recommends a narrow one such as "use when adding or changing a migration, or reviewing its rollout."

AGENTS.md, the repository rules file, points the same way. Requiring a read of the architecture, database and deployment documents before every edit is excessive for fixing a single typo, the company noted. It recommends attaching conditions about which document to consult in which situation, and deleting the sentences that nag the model into running tests. Earlier models had to be pushed into verifying their work, but GPT-6 Astra does it on its own, so the same instruction now triggers unnecessary testing.

This is where the post starts to read like a contract. The company recommends revising any strong prohibitions written to stop earlier models from acting without permission. OpenAI wrote that GPT-6 Astra, as "our most aligned model," has much better judgment and will not perform tasks unless it knows they are safe, so it should be treated that way. Leaving the old prohibitions in place means Astra may take them too seriously and stop where continuing would have been fine.

It even supplies example wording for granting permission. The company suggested putting a sentence like "the local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step" into AGENTS.md. If you are used to the previous model, GPT-5.6 Sol, running for long stretches, Astra can feel more tentative, coming back for review after a first implementation while work remains. So the advice is to define what counts as done before starting.

The same week produced a record from the opposite direction. Armin Ronacher, a developer who has worked on the CPython interpreter, wrote on his own blog on September 7 about an experiment in which he handed Astra an entire weekend with no supervision. He let the model decide its own workflow and spin off subagents, and switched it off after 35 hours. He wrote that "35 hours later, the factory has delivered absolutely nothing of value and also not taught me anything about how to operate a better one."

What was left were the numbers. According to Ronacher, those 35 hours added a net 75,000 lines of code, produced 79 commits, and involved roughly 1,400 messages exchanged between agents. He wrote that the experiment burned about 4 billion tokens, a full reset's worth of a ChatGPT subscription, and that in raw terms it came to around 1 billion tokens for about 1,200 dollars, roughly 15.5 dollars per commit. Task names started at 1, 2, 3, 5, 5a, passed through 8a1 and ended up at 8b2c2b3.

The problem was not volume but legibility. Ronacher wrote that when Astra reads and edits files, it leans excessively on Python written on the spot instead of the provided tools. Code written that way is hard for a person to follow, and without the edit tools there is essentially no way to watch the changes happen. Worse, that habit leaks into the code that actually lands in the repository: he pointed to unit tests jammed together with no regard for indentation, noting that the form is 10% more token efficient than the formatted version.

The two pieces are two sides of the same fact. Telling people to strip instructions means telling them to trust the model's judgment more, and the more you trust it the less a human reads. That is exactly where Ronacher got stuck. He wrote that "it has shown that it will commit slop, and it requires me to review it more as a result," adding that even with a low failure rate he would not want that. When code rewarded for token efficiency lands in a repository, the time of the person who has to read it later shows up in no metric at all.

The OpenAI guidance METAL read through carries a warning that repository skills also apply to other people's agents. Instructions that help Sol or Luna may overconstrain GPT-6 Astra, so consider which models will read what you leave behind. That means the person writing the rules and the party bound by them have started to come apart, and the repository rules file now looks more like a contract inside the team. METAL has reported that OpenAI opened the harness that runs Codex through its API, and every organization using that harness will have to write this contract afresh.

The question Ronacher tacked onto the end of his post leads back to ground we have already covered. He asked how models inside a sandbox, with no way to communicate with one another, manage to find the same public wikis to use as a scratch pad. METAL has reported on OpenAI agents leaving notes on outside wikis, and the traces an unsupervised agent leaves behind accumulate outside the code as well.

Cutting the instruction sheet and cutting the review are different problems. OpenAI's guidance says to remove the sentences that order the model to read things; it does not say to stop deciding who reads the results. If the agent will not stop on its own, writing down where it should stop is the last sentence a human has to leave behind.