GPT-6 Astra and the employee handbook from hell

A prompt collection attributed to GPT-6 Astra in Codex Desktop appeared in the CL4R1T4S repository. The bit being passed around was the size: about 300,000 characters for instructions and another 1.1 million for tools.

Which is quite an employee handbook. I wanted to see how much of it was necessary documentation and how much was explaining to a coding agent that it should, occasionally, write some code.

There is a line about users getting frustrated when it asks for permission. There is advice about finishing the work instead of offering to do it. Even the writing style needs supervision. And honestly, those are the bits I found more interesting than the file size.

The numbers need a bit of explanation

I counted 338,459 characters in the prompt file and 1,177,471 in the separate tools JSON. That includes whitespace. About 1.52 million combined, so the rough numbers check out.

But the prompt file is a collection of templates, modes, and instructions for different roles. Those counts do not mean every conversation starts with the entire lot loaded. They also do not tell us how many tokens a request uses. Characters and tokens are different units.

And this is a third-party upload. I have not authenticated it as a complete production configuration. I am looking at what is in the files, with links pinned to the revision I checked.

So yes, there is a lot of material here. The claim that Astra needs all of it before answering a question would need more evidence. Slightly inconvenient for the roast, but there is enough left to work with.

Please do the thing I asked you to do

This line in the posted instructions is probably my favourite:

The user gets very frustrated when you stop and ask for confirmation or permission

You can almost hear the person who wanted that added. "Yes. Do it. That was the request."

The underlying issue is in the public documentation too. OpenAI's Astra guidance says the model can ask questions when the user expects it to make reasonable assumptions and continue. The suggested prompting pushes it to finish authorized work instead of stopping after a plan or an offer to help.

Imagine assigning a ticket to a developer and then having to explain that "can you fix this?" means you want the fix. You are not conducting a survey of their capabilities.

I do understand the problem. An agent with a terminal needs limits. If the next step deletes a database, asking is useful. If the next step is reading the file you just asked it to edit, the question mostly gives you another notification to deal with.

Getting that distinction right is part of making the product usable. Still, seeing it written down in such detail is funny. We have a model capable of doing substantial engineering work, and some of the supporting instructions amount to a manager leaning over a desk saying, "You already have approval."

Somebody also had to fix the writing

OpenAI's writing guidance includes avoiding words such as "delve", "foster", and "leverage", along with advice about tone and structure.

Good. A database migration has suffered enough without becoming a journey.

This is a small thing, but it says something about the work around these models. A correct answer can still be annoying to read. It can bury a useful sentence in introductions, summaries, and an offer to explain the thing it was supposed to explain in the first place.

Then somebody has to describe the problem precisely enough for the model to stop doing it. "Write naturally" apparently leaves quite a lot of room for interpretation.

I find this part easier to sympathise with than to mock. People have preferences about writing, and the default will never suit everyone. But there is a certain pleasure in discovering that the frontier of AI engineering includes telling the model to stop sounding like a LinkedIn post.

Most of the tools file has a reason to exist

The tools JSON contains names, descriptions, and input schemas. Those schemas specify the arguments a tool accepts. A large chunk of material like that is documentation for operating software, and I want that documentation to be clear.

An agent should know what an action does before using it. Shortening a description until the tool becomes ambiguous would be a fairly stupid way to win an argument about prompt size.

What I would want to know is how much of the catalogue a particular task sees. For a blog edit, the useful starting point is the post, the content format, and a way to edit it. Other capabilities can become relevant later. The existence of a giant tools file does not establish how the running application makes those choices.

I would check that behaviour before getting excited about the number. Give the agent a small task and see what it loads, what it calls, and whether the extra information helps. A catalogue can be large and still be used sensibly.

Also, please do not multiply 1.5 million characters by an API price and call it the cost of saying hello. Apart from the token conversion and the question of what gets loaded, there is caching. OpenAI documents how matching prompt prefixes can be reused to reduce cost and latency. Tool and instruction changes can affect that reuse. The files alone do not give us a Codex Desktop bill.

That takes some of the fun out of the obvious joke. I would rather get that bit right.

The part I would hate to maintain

Reading instructions like these, I keep imagining the issue that came before each rule. That is my interpretation; I do not know how this collection was assembled.

Say an agent keeps stopping halfway through tasks. You add a rule to keep going. Then it goes further than the user wanted, so you explain the boundary. It becomes too cautious and starts asking about everything. Another paragraph. Eventually the permission explanation itself gets too long, and you need a rule about that as well.

Each change sounds reasonable on its own. After enough changes, somebody has to work out how they interact.

This feels familiar from ordinary software maintenance. You fix the immediate problem, add an exception, and move on. Six months later another person asks why the exception exists. With prompts, some of that logic is sitting in prose, possibly next to another paragraph written for a different failure.

At least an unused function sometimes gets a warning from the tooling. A paragraph can sit there looking very important for years.

Caching does not solve this bit. It can make repeated processing cheaper, but somebody still has to investigate why the agent stopped, chose the wrong tool, or treated a routine edit as a request for a planning meeting.

I would want the team to test these instructions against actual tasks. Does a simple edit finish without extra questions? Does a vague request get a useful clarification? Do restrictions hold when the model tries an action outside its permissions? The surrounding software should enforce those restrictions too. A strongly worded paragraph is a poor substitute for an access check.

And I would want to remove rules occasionally. Adding one is easy. Working out whether an old one is still helping takes more effort, so I suspect it is the job most likely to wait until next sprint.

I still want the agent to be useful

A big collection of instructions does not convince me that the model is bad. There is real engineering involved in giving it tools and making it behave usefully. Some of the boring documentation is probably what makes the pleasant demo possible.

I am less convinced by the idea that the management overhead has disappeared. There is still a lot to specify and maintain. It has just moved into a place where we can call part of it prompt engineering.

That is close to my concern about AI code review and oversized context. I want to know which information helps with the job in front of it. More available material does not answer that question by itself.

If the agent reliably finishes useful work, I can live with a large handbook. I would judge it by the result and how often I have to get involved, rather than the size of a file on GitHub.

But I am keeping that permission sentence. Out of all the technical material, the bit that sticks is somebody having to explain that the user is getting annoyed. Very advanced system. Familiar office problem.