After Codex's System Prompt Went Public, What's Left of the AI Agent Moat?

What is an agent actually worth — one that can edit code, call tools, operate a computer, and keep pushing tasks forward on its own? This seemingly abstract question has been thrust back onto the table by a wave of leaked system prompts. According to an analysis by Bilibili creator Nana, around the same time OpenAI announced GPT-6 OneSoul at DevDay, the GitHub repository "System Prompts Leaks" published a file labeled Codex. The archived file for GPT-6 OneSoul runs to 7,100 lines, spelling out in detail how the agent advances tasks, calls tools, and when it must ask the user for permission.

This happened at a commercially sensitive moment. Related funding disclosures indicate that OpenAI is seeking more than $30 billion in new financing at a valuation of roughly $1.4 trillion, with a public listing pushed back to 2027. When a company's value depends increasingly on agents completing work on behalf of humans, and the engineering processes behind those products are made public, a practical question follows: how much of what customers pay is for the model's raw capability, and how much is for the work system built around it?

What's Hidden in 7,100 Lines of Rules

According to published descriptions, researchers repeatedly probed and prompted the model until it disclosed its own behavioral rules, which were then compiled and archived by the repository. What became public is essentially the instructions and tool protocols the model receives.

These rules are remarkably specific. For example: when a user requests a task, the model should keep pushing forward until a deliverable result is ready; when deployment changes are needed, complete the composable work first and save approvals for last; for reversible operations and read-only actions, there's no need to repeatedly check in with the user. Even how to report intermediate progress and how to format responses are spelled out clearly.

Placed in the context of everyday work, these rules make intuitive sense. When you ask an assistant to fix a program, you expect more than a few edited lines — you expect them to read the project, find the relevant files, make the changes, check the results, keep going if problems arise, and hand back a version you can review. The model handles understanding and generation; tools give it real access to files and the runtime environment; and the rules tell it how to chain those actions into a complete piece of work. Only when all three are connected do you get the agent experience we actually see.

The most valuable shift is that developers can now study this approach directly. Things that previously had to be inferred from product behavior — how to cut down on pointless confirmations, how to scope permissions, how to keep tasks moving, how to deliver reviewable results — can now be examined line by line. For competitors, this is effectively a concrete engineering reference that shortens the time needed to figure out these workflows and makes certain product experiences considerably easier to replicate.

---

A system prompt is a hidden set of instructions injected into the model before the user conversation begins. It sets the model's persona, permission boundaries, output format, and behavioral priorities. It never appears in the user interface, yet it governs the model's "personality" and decision logic throughout the entire session. For agent products, the system prompt is essentially an operations manual: it tells the model when to proceed autonomously, when it must check with the user, and how to handle errors. At 7,100 lines, this manual covers an extraordinarily granular set of scenarios — permission tiers, tool-calling sequences, task interruption and recovery logic, and more. That is precisely why such prompts have historically been treated as trade secrets: they encode not just prompt-writing technique, but hard-won engineering knowledge distilled from running large numbers of real-world tasks.

---

Why Rules Don't Guarantee Reliable Completion

Handing rules to a model is still a long way from reliably completing a task. The most easily overlooked problem in long-horizon tasks is this: each individual step might perform fine, while the overall run still fails.

Nana offered a probability illustration: suppose a task requires 20 consecutive steps, each with a 95% success rate, compounded independently. The probability of all 20 succeeding is roughly 35.8%. Every step sounds reliable; chained together, only about one in three attempts makes it through. The reason is that each step's output becomes the next step's input — one mishandled error can send all subsequent work in the wrong direction.

This calculation reveals the inherent fragility of task chains. Real agents can check, retry, and roll back, and those recovery mechanisms are exactly what the engineering system needs to handle: run a check after modifying a file; if an error appears, fix and retry; read the return value after a tool call to confirm the operation succeeded; maintain task state so completed steps aren't forgotten. What the model generates each turn only becomes the basis for the next step after the environment validates it.

This system — connecting model, tools, state, and feedback — is commonly called the Harness: the agent's runtime framework. Think of it as a workbench: each action leaves a result, and the system decides how to continue based on that result. The system prompt is the operating procedure on that workbench. Clear procedures reduce confusion, but whether the tools work, whether the model can interpret feedback, and whether it can recover from failures all shape the final output just as much.

A Minimal Framework in ~100 Lines of Code

The SWE-bench team built a stripped-down framework called Mini-SWE Agent in roughly 100 lines of Python and reported approximately 65% resolution on SWE-bench Verified. This example is worth paying attention to because it compresses the work loop to its bare minimum: the model proposes an action, the environment executes it, the result is returned, and the model continues.

Engineering design doesn't have to justify itself through the complexity of its module count — what matters is whether this loop actually helps the model solve problems. It's worth noting that ~65% resolution reflects a specific model, a specific run configuration, and a specific set of evaluation tasks; assessing a framework's effectiveness requires holding all those conditions together. Lines of code are easy to compare. Whether the framework gets the actual job done is what the customer ultimately experiences.

This also pushes the question toward open-source models. Developers can take the now-public planning rules, autonomous-progress requirements, and tool protocols, plug them into models like DeepSeek^Ad or Qwen, and check whether long-task performance improves. Once workflows become easier to replicate, competition falls more directly on delivered outcomes.

---

SWE-bench (Software Engineering Benchmark) is an evaluation benchmark published by a Princeton University team. It requires a model to autonomously locate and fix a bug in a real GitHub repository based on an Issue description, with success judged by whether the provided test cases pass. SWE-bench Verified is a curated subset, manually reviewed to ensure task descriptions are clear and reproducible; it is generally considered a more reliable basis for head-to-head comparison than the full benchmark. A 65% resolution rate means the model independently completes roughly two-thirds of real code-repair tasks in this subset — a meaningfully strong result for tasks requiring cross-file comprehension, multi-step reasoning, and environment interaction. That said, different teams submit results using different model versions, inference budgets, and retry counts, so experimental conditions matter when making comparisons.

---

How Much Should a Single Task Cost?

For enterprise customers, the most pressing question is usually: what does a complete task actually cost? A cheap per-call price can still add up if the task requires multiple retries; an expensive per-call price might still save money if the task is completed reliably. You can only calculate the business value of an agent by connecting the model's price to its actual output.

OpenAI itself has been differentiating on price tiers: GPT-6 Astra is priced at $10 per million input tokens and $50 per million output tokens; GPT-6 OneSoul comes in at $2 per million input and $10 per million output, with cached input at $0.10. OneSoul's standard input/output rate is roughly one-fifth that of Astra. On OpenAI's DeepSWE V1 evaluation, OneSoul is described as approaching Astra's performance at about one-fifth the cost. This product positioning is itself an answer to customers' cost questions: which tasks need the flagship model, and which can be handled by a more economical one.

Nana ran through an example calculation: suppose a company buys a $500-per-month subscription for each of 500 engineers — that's $3 million per year. Faced with that kind of expenditure, companies will naturally compare alternatives. But the math on alternatives also needs to be run all the way through: on-premises deployment requires servers and requires someone to maintain the model runtime environment, tool permissions, task state, and failure handling. Since an agent's effectiveness comes from multiple components working in concert, buying the hardware still leaves all those components to be assembled. What enterprises actually need to compare is: how much do we invest in a year, how much work can reliably get done, and how much still needs human intervention?

Why This Affects Valuation

High valuations depend on future revenue — and on how much profit a company can retain over the long run. Related funding disclosures point to ~$70 billion in annualized recurring revenue as a future target for OpenAI, with Sol and the persistent agent Dots expected to drive enterprise growth. Dots comes equipped with a cloud VM and browser, enabling continuous task execution. If customers stick around for the long term, subscription revenue has room to keep growing.

But once customers discover that part of the work can be accomplished a different way, the service provider needs to justify its price with more concrete delivery outcomes. Publicizing the engineering workflow opens a new avenue for that comparison: behavioral designs that competitors previously had to figure out themselves can now be studied directly. This could erode the exclusive advantage that comes from proprietary workflow design, while also raising customers' willingness to shop around.

OpenAI also faces enormous capital demands. According to the Financial Times, the company expects to burn through approximately $278 billion in cumulative cash between fiscal years 2026 and 2030. That means it must both keep raising funds and grow revenue fast enough to gradually support those outlays. If alternatives proliferate and pricing comes under pressure, the company needs to work harder to demonstrate that its service keeps delivering value customers will pay for. It's also worth noting that, according to related reports, the U.S. Federal Trade Commission launched an investigation into OpenAI, Anthropic, and other companies on September 30, focusing on the risks their AI technologies may pose to consumers.

---

ARR (Annualized Recurring Revenue) is a standard metric used by SaaS and subscription businesses, calculated by converting the current value of subscription contracts into an annualized figure. It represents a snapshot of current business scale rather than cumulative historical revenue. When valuing high-growth tech companies, investors typically anchor on revenue multiples: if a company's ARR is X, the valuation is often tens of times X, with the remainder reflecting expectations of future growth. OpenAI's ~$1.4 trillion valuation set against a $70 billion ARR target implies a market-implied revenue multiple of roughly 20×, an extremely high figure by traditional software standards — a bet that agent adoption at scale will continue driving subscription growth. If competition intensifies, customers churn, or pricing erodes, that multiple faces pressure to re-rate.

---

Competition Ultimately Comes Back to the Product

AI agents may evolve along two technical trajectories: one bakes more task-planning and tool-decision capability directly into the model, reducing reliance on external text-based rules; the other co-designs models with specialized chips to use compute more efficiently for the same workload.

Whether either path produces a sustainable advantage ultimately comes down to task performance and cost. The most significant consequence of this prompt leak is that it makes the value of AI agents far easier to decompose: what role rules, models, and tool environments each play is now much clearer, and it's easier to compare which design choices are worth borrowing versus which capabilities still require investment.

For closed-source products, this raises the bar for proving value. For open-source developers, it provides a reference for improving their own workflows. For customers, it means decisions can be grounded in more concrete metrics — did the task get done, is the result reliable, does the total cost make sense?

Back to where we started: what is an agent actually worth? The answer has to come down to how much work it can reliably deliver. Seven thousand one hundred lines of rules help us understand how it acts; long-term business value must be sustained by the track record of actual execution. With the system prompt now public, comparisons between products will only get more specific. Whoever can turn a replicable workflow into a reliable, economical, and sustainable service will have the better chance of retaining customers — and keeping their premium.