Long-Running Coding Agents Need a Harness, Not Just a Bigger Model

The frustrating failure mode in a long-running coding agent is not always a bad patch. It is the moment when the task has been compacted twice, several tools have run, a subagent has returned a summary, and nobody can answer a simple question: what has been proven, what is still an assumption, and what should happen next?

Buying a larger context window does not answer that question. Neither does putting a longer policy prompt at the top of every session.

The useful default is two separate decisions:

1. Route the model by the input and execution constraint that can make the task fail.
2. Run the work through a harness that records state, caps actions, checks evidence, and produces a restartable handoff.

This guide is deliberately not a generic coding-model leaderboard. It gives a practical way to choose a first ChinaAPI route for a long-running coding task, then makes the more important point: a model is an inference component; a durable agent is an operating system around it.

The current routing inventory

Our gateway-reconciled catalog snapshot captured on 2026-07-24 contains 25 live per-token model IDs. Every one is tagged Reasoning and Tools in the catalog metadata; 11 publish a 1M-token context window, and six combine 1M context, tool support, and vision input.

That is an availability and published-capability map, not a benchmark. It does not prove that a model follows tools correctly, fixes more bugs, or stays reliable under your traffic. It does mean that an agent builder has enough distinct routes to stop treating every task as a text-only flagship prompt.

The position is firm: choose the route by the evidence your task needs and the budget you can enforce, not by the word “flagship.” A 1M text-only model is a false saving if the acceptance check requires a screenshot. A premium coding route is a false default if a bounded extraction or test-writing task can be accepted by a lower-cost route.

For exact IDs, current displayed rates, and catalog changes, check live pricing before production use. The Cursor, Cline, and LiteLLM guides show the same OpenAI-compatible endpoint in tool-specific settings.

A model route is not a task contract

An agent can have an excellent model and still fail a long job in completely ordinary ways:

• A repository scan silently consumes the whole context budget.
• A tool loop retries until the cost is surprising.
• A prior session's TODO is treated as current fact after the branch changed.
• Several subagents return plausible summaries, but no parent agent checks whether they agree with the current diff and CI.
• The final answer says “done” although an acceptance test was never run.

Those are not primarily language-model problems. They are task-state, authority, and verification problems.

OpenAI describes its Codex harness as the layer that orchestrates the user, model, and tools in the agent loop. Its engineering team also describes the work around agents as specifying environments and feedback loops, not merely issuing better prompts. Read the agent-loop explanation and the Harness Engineering report.

The practical consequence is simple. Treat the model selection as one field in a task card, not as the task plan itself.

Start every long task with a bounded task card

This task card is small enough to store with a trace, but specific enough to stop an open-ended coding request from becoming an open-ended agent loop. The exact model is a candidate, not a claim of measured superiority.

{
  "task_id": "repo-bugfix-01",
  "task_type": "repository_bugfix",
  "candidate_model": "LongCat-2.0",
  "escalation_model": "glm-5.2",
  "source_modalities": ["repository_text", "issue", "test_log"],
  "context_requirement": "1m",
  "needs_tools": true,
  "max_tool_rounds": 8,
  "max_attempts": 2,
  "max_cost_usd": "set per task",
  "acceptance_checks": [
    "targeted test passes",
    "diff stays inside the named module",
    "no unsupported claim in the handoff"
  ],
  "human_approval_required_for": ["production deploy", "data deletion", "credential change"]
}

The first two fields that deserve attention are not the model names. They are source_modalities and acceptance_checks.

If the agent has to reconcile a browser screenshot with a CSS change, select a model with the corresponding input capability before comparing token prices. If no test can establish the task's result, write the review or approval step before the agent starts editing. If the task cannot tolerate a destructive command, make the permission boundary executable rather than hoping the model rereads a warning.

Here is the smallest OpenAI-compatible starting point for the candidate model above:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["CHINAAPI_API_KEY"],
    base_url="https://api.chinaapi.ai/v1",
)

response = client.chat.completions.create(
    model="LongCat-2.0",
    messages=[
        {"role": "system", "content": "Work only within the stated task card."},
        {"role": "user", "content": "Inspect the failing test before proposing a patch."},
    ],
)
print(response.choices[0].message.content)

Use an exact current model ID from live pricing. The code establishes a request path, not a complete autonomous coding agent. A production loop still needs its own tool schema, sandbox, authorization policy, telemetry, and acceptance executor.

The five controls that turn a chat loop into a recoverable system

1. A task graph, not a scrolling conversation

Each node should have an input, output, status, dependency, owner, and acceptance check. A repository scan can run before implementation. A test cannot run before the relevant code exists. A production action can wait for human approval. Making those relationships explicit prevents an agent from treating every available tool as the next sensible action.

2. Memory with provenance and expiry

PLAN.md, STATE.md, and HANDOFF.md are useful only if they point back to facts. Record where a statement came from, when it was written, which branch it applies to, and when it should be checked again. Current code, commits, pull requests, CI, and tests outrank old summaries.

This is memory garbage collection in practice. Memory is not an archive that should grow forever. It is a working index that should be pruned when the underlying facts change.

3. A trace that can explain a failure

Store the tool call, input reference, result, test output, retry count, and state transition. The goal is not surveillance or maximum logging. The goal is to make a later question answerable: did the task fail because the model chose a bad edit, because a prior assumption was stale, because a tool was unavailable, or because the acceptance rule was absent?

4. Enforceable boundaries

Prompts are useful soft constraints. Permissions, sandboxing, hooks, linters, tests, approvals, and rollback paths are harder constraints. Put irreversible or consequential actions behind the latter.

Claude Code's subagent documentation makes the same separation visible from another angle: isolated workers can protect the main context from verbose exploration, but their outputs still need a parent workflow that evaluates them. Its subagent guide is useful background for designing that boundary.

5. A checkpoint that a new session can actually use

A handoff should not be a chronological diary. Keep the original objective, verified facts, decision and trade-off, unresolved risks, exact next action, and the fact sources to read first. Then a new session can recover from a compacted conversation without importing every old guess.

The human role becomes clearer after these controls exist: set the objective and boundaries, approve consequential decisions, inspect risk, and accept the outcome. The system, not a person's short-term memory, carries the operational detail.

Long context helps, but it does not govern

It is easy to confuse model architecture with agent governance. They meet in a long session, but they solve different problems.

MoE increases parameter capacity while activating only part of the model for a token. MLA reduces the cost of attention and KV-cache handling for long-context inference. DeepSeek's V3 report describes both techniques in its efficiency design. Read the technical report.

Those advances can make a longer context affordable. They cannot determine whether an old handoff is stale, whether a subagent conclusion has been reviewed, or whether a deployment needed approval.

Long context answers “can the model retain more material?”

Governance answers “which material is still true, who may act on it, and how can we recover when the task goes wrong?”

Do not use one as a substitute for the other.

Turn failures into evaluation inputs, not mythology

A trace of an agent failure is raw material, not a ready-made training example.

First classify it. Did a memory file mislead the agent? Did a handoff omit a risk? Did the scheduler parallelize the wrong tasks? Did the agent skip the CI evidence? Did the model fail within a sound task contract? Each category suggests a different repair: a freshness check, a checkpoint field, a hook, an eval, a better tool interface, or a changed routing rule.

Only then do repeated failures become useful for supervised examples, preference data, reinforcement learning, or regression tests. A system that cannot tell a bad trace from an underspecified task will only train noise more efficiently.

What this guide does not claim

We have not yet published repeated ChinaAPI results for repository-level bug-fix completion, tool-call success, agent-loop latency, accepted-patch cost, or recovery quality across the models in the table. We therefore do not call any candidate the universal best coding model, promise a model's availability, or turn catalog metadata into a performance ranking.

The catalog can change, and a 1M context window is capacity rather than evidence quality. Verify the exact model ID and displayed rate before deployment. Run a fixed task set against your own repository, store acceptance results and total repair time, then promote a route only after it wins on usable outcomes.

The practical order of work is not glamorous, but it is reliable:

route by required inputs and constraints
→ bound the task with a card and acceptance checks
→ execute under permissions, trace, and budgets
→ checkpoint verified facts for recovery
→ convert recurring failures into evals and guardrails

That is how a coding agent becomes more than a model with a terminal. It becomes a system that can explain its work, survive a session boundary, and give humans the only control surface that scales: goals, boundaries, judgment, and acceptance.

Sources and method

• ChinaAPI catalog facts in this article come from the gateway-reconciled models-data.json snapshot captured on 2026-07-24. Counts reflect the fields in that snapshot, not a quality or availability guarantee.
• OpenAI, Unrolling the Codex agent loop
• OpenAI, Harness Engineering
• Claude Code, Create custom subagents
• DeepSeek-V3 Technical Report