How to Evaluate Long-Horizon AI Agents: Real Capability, Cost, and Reliability

The competitive focus of AI models has been shifting from “single-turn answer quality” to “whether the system can persistently complete complex work.” Instead of merely generating a code snippet, answering a question, or writing a document, a long-horizon agent must handle longer contexts, more complex dependencies, and multiple rounds of feedback. It not only proposes a plan—it executes tasks, detects errors, corrects results, and finally delivers an outcome that a human can inspect, run, or reuse.

Recent public demonstrations of a new class of models have shown stronger long-horizon execution capabilities. Relevant experiments include building a bootable prototype operating system from an empty directory, and orchestrating large-scale multi-agent collaboration to formally reproduce mathematical proofs within a short time. These results are certainly noteworthy, but they should not be equated with “the model is already able to independently take over real projects.” To judge actual capability and cost-effectiveness, we still need to deconstruct the process, verify the quality of outputs, and calculate the full cost of use.

1. What Really Matters: Moving from Content Generation to Delivered Outcomes

Traditional code models typically produce functions, modules, or local modifications as primary outputs. After a user states a requirement, the model generates code, and the developer then handles debugging, integration, testing, and deployment. This pattern can significantly improve local development efficiency, but overall project progress still depends on human coordination.

Long-horizon agents aim differently. They need to break a large goal into multiple executable steps, such as:

1. Analyzing requirements and constraints.
2. Designing the system architecture.
3. Creating directories, configuration files, and base modules.
4. Writing core code.
5. Running tests and collecting error information.
6. Modifying the implementation based on feedback.
7. Checking compatibility between modules.
8. Preparing documentation, build scripts, and delivery instructions.

The value of such a system lies not only in how well a particular piece of code is written, but in its ability to maintain task state, remember what has already been done, identify unresolved issues, and stay consistent across multiple subtasks.

From the public experiments, the model can coordinate a large number of sub-agents to jointly implement modules such as the kernel, storage, input devices, networking, GUI, login flow, and installer, ultimately allowing a simplified system to boot on ordinary hardware. This result shows that the model has reached a new stage in task decomposition, parallel collaboration, code generation, and automated verification.

However, “it can boot” is only a clear milestone; it does not imply long-term stability, hardware compatibility, security, or production readiness. What it demonstrates is that the model can close the loop from an empty project to a runnable prototype under certain conditions—not that it can replace a full software engineering team.

2. The Core of Long-Horizon Capability Is Not Context Length

Many people interpret long-horizon capability as “the model remembers more text.” In practice, the genuinely hard parts include at least four dimensions.

2.1 State Management

Long-running tasks often last hours or even days. The model must know what has already been done, which steps failed, which files have changed, and whether the current result still satisfies the original goal. If the model just keeps appending text without structured tracking, it will risk duplicated effort, overwritten modifications, missing dependencies, and goal drift. Therefore, mature long-horizon systems typically need to maintain task lists, version records, test results, error logs, and acceptance status.

2.2 Task Decomposition

A complex goal cannot be completed in a single pass. The model needs to split the goal into well-bounded subtasks while identifying dependencies between them. For example, when building a prototype system, the low-level boot process may need to precede the GUI; the storage module must match the file system interface; the installer depends on the system image and boot configuration. If the decomposition is unreasonable, even if each subtask is locally correct, the final integration may fail.

2.3 Failure Recovery

Real development almost never succeeds on the first attempt. Compilation failures, failing tests, interface mismatches, missing dependencies, and differences in runtime environments are common. A good long-horizon agent should not simply “keep generating” but should locate the cause from logs, determine whether it is a code error, configuration error, or environment issue, and choose an appropriate remediation strategy. More importantly, it needs to avoid fixing one test by breaking another module.

2.4 Result Verification

Automatically generated outputs must be independently checked. The model should perform static analysis on the code, run unit tests, integration tests, and basic scenario validation, and compare the results item by item against the requirements. If verification is still performed by the same reasoning pipeline that produced the output, there is a risk of “the generator also serving as the acceptance checker.” In practice, independent test suites, human spot checks, and rule-based acceptance mechanisms should be introduced.

3. What the Formal Mathematics Experiment Shows

Another widely discussed experiment involved multiple agents collaborating to formally reproduce an existing mathematical proof. Formal verification is not simply converting a natural-language proof into another typesetting format; it expresses every derivation step as a logical object that a computer can check. The proof system verifies that definitions are correct, theorem citations are applicable, and inference steps satisfy the rule set. If the final check passes, this can largely eliminate the jumps, misuse of conditions, and symbol errors common in traditional textual proofs.

The experiment demonstrates several model capabilities:

• Understanding the structure of a complex proof.
• Breaking the proof into multiple lemmas.
• Filling in intermediate steps in a formal language.
• Continuously correcting based on checker feedback.
• Coordinating multiple subtasks and merging results.

However, formal reproduction is still a different problem from proposing new mathematical theories. Reproducing an existing proof focuses on comprehension, translation, and verification; creating original theory requires new concepts, conjectures, and proof strategies. The success of the former cannot directly imply that the latter is equally mature. This is also a principle to keep in mind when evaluating AI models: experimental results only prove the capabilities covered by the experiment—they cannot be infinitely extrapolated to all adjacent tasks.

4. Understanding “Same Underlying Model, Different Usage Scope”

Some AI models set different safety policies, access conditions, and task scopes based on the use case. Even if the underlying reasoning ability is similar, different service forms may lead to completely different actual user experiences.

Versions aimed at general consumers typically impose stricter restrictions on high-risk domains such as network security, biological research, and private data processing. When it comes to vulnerability exploitation, attack code, dangerous experiment design, or sensitive operations, the system may refuse to answer or only provide defensive or conceptual content.

Versions intended for verified professional organizations or research institutions may have a broader research scope, but they usually require additional identity vetting, compliance commitments, and usage constraints. This creates a common misconception: users see a benchmark score and assume they can use the same capability, when in fact that score may correspond to a different access tier and security configuration.

Therefore, a model selection sheet should not just record a “theoretical capability score.” It should also include at least the following fields:

• Whether the current account has usage eligibility.
• Which tasks will be restricted.
• Whether an alternative model is available when restrictions apply.
• Whether internal code and sensitive data can be processed.
• Whether results support audit and traceability.
• Whether long tasks have time, concurrency, or resource limits.
• What the process is for human intervention after failures.

Only by combining capability, permissions, and risk boundaries together does the evaluation become meaningful.

5. Performance Improvement Does Not Equal Cost Reduction

The cost-effectiveness of a long-horizon agent cannot be judged merely by the price of a single call or the model’s output speed. The full cost typically includes:

1. Model call cost.
2. Parallel sub-agent invocation cost.
3. Long context and historical state maintenance cost.
4. Code execution, build, and test environment cost.
5. Human review and rework cost.
6. Data security, access control, and log storage cost.
7. Time cost caused by failed tasks.

For example, a task may outwardly require only generating a piece of code, but the model may go through multiple planning rounds, dozens of tests, and many sub-agent calls. If the developer still needs to review every file at the end, the actual time saved may be lower than expected.

A more reasonable calculation is to compare the total cost of “producing a qualified deliverable” rather than the unit price of “generating a text segment.” The following logic can be used:

Actual benefit = saved human time − model call cost − review cost − rework cost − risk handling cost

For tasks with clear requirements, sufficient test coverage, and easy result acceptance, long-horizon agents are more likely to deliver value. Examples include code migration, test case generation, documentation organization, configuration generation, and prototype validation.

For tasks with ambiguous requirements, complex business rules, and high cost of errors, the model may need significant human supervision even if it has strong capabilities. In such cases, improving model capability does not necessarily mean overall cost decreases correspondingly.

6. How Enterprises and Development Teams Should Validate

Do not decide based on marketing demos or a single benchmark result. A safer approach is to build a small-scale, repeatable test set.

Step 1: Choose Real but Isolated Tasks

Test tasks should come from the team’s daily work, for example:

• Adding tests to existing modules.
• Migrating old interfaces to new ones.
• Analyzing a batch of runtime logs.
• Writing an initial version of an internal tool.
• Fixing a set of known defects.
• Generating deployment and rollback documentation.

Avoid experimenting on core production systems at the start, and avoid only picking the simplest problems where the model excels.

Step 2: Define Clear Acceptance Criteria

Acceptance criteria should be as executable as possible, for example:

• All tests pass.
• Static checks show no high-severity issues.
• Key interfaces remain compatible.
• Performance is not lower than the existing baseline.
• Documentation includes installation, configuration, and rollback steps.
• The result can be reviewed by another developer.

Without acceptance criteria, it is impossible to distinguish “looks finished” from “actually finished.”

Step 3: Record the Full Process

In addition to the final output, record task duration, number of invocations, number of failures, amount of human modification, and reasons for rework. Pay special attention to the stages where the model repeatedly fails, because this data reveals real capability better than a single successful case.

Step 4: Conduct Manual Sampling Reviews

For code, security configuration, and data processing tasks, manual inspection is mandatory. A model passing tests does not mean there are no logical flaws, nor does it mean it understood all business constraints.

7. How Developers Should Adjust Their Workflow

Long-horizon agents do not make engineering discipline obsolete; they amplify the importance of solid engineering foundations. If a project lacks tests, documentation, module boundaries, and version management, the model will struggle to work reliably.

Development teams are advised to prepare in advance:

• Clear requirement specifications.
• Executable automated tests.
• Stable build processes.
• Clear code directory structures.
• Traceable version records.
• Least-privilege execution environments.
• Independent acceptance scripts.
• Mechanisms to de-identify sensitive information.

For high-risk operations, adopt a workflow of “model proposes the plan, executes in a controlled environment, and human confirms the result” rather than allowing the model to directly modify production resources. For operations involving network access, database writes, permission changes, or external publishing, add approval checkpoints and rollback mechanisms.

Conclusion: Evaluating “Delivery Reliability” over “Smartness”

The progress of long-horizon agents is real. They are no longer confined to answering questions or generating local code; they are beginning to possess the ability to plan, execute, test, correct, and integrate complex work. Prototype system construction and formal proof experiments show that such models have great potential in multi-step collaboration and automated verification.

However, experimental results must be interpreted within their specific context. A bootable prototype is not a stable product; passing a formal proof check does not imply the ability to propose new theories; and public benchmark scores do not guarantee that all users will get the same service scope.

When judging actual capability and cost-effectiveness, the key question is not whether the model can deliver one impressive demonstration, but whether it can persistently deliver within defined constraints, be reliably accepted, reduce overall cost, and remain controllable when failures occur. For developers, the most worthwhile investment is not blindly chasing the latest model name, but building a mature system of task decomposition, automated testing, permission control, and result auditing. Only then can the capabilities of long-horizon agents be transformed into stable engineering productivity.