Blog
What does "long-horizon" mean for AI coding agents?
Long-horizon means an agent works for hours or days toward one goal. Why long-horizon tasks fail, and what keeps a run alive to the end of the work itself.
2026-09-08 · Sathwik R
Long-horizon describes work an agent carries for hours or days rather than for one exchange: a migration, a refactor across forty files, a backlog worked through overnight. The defining feature is not difficulty. It is that the task outlives the context window, the terminal session, and your attention — so something has to hold it together while none of those are available.
Why do long-horizon tasks fail?
They rarely fail on the code. They fail on continuity — the run loses something it needed, and nothing notices. Four causes account for almost all of it, and each has a specific fix that is not a better model.
| Failure | What actually happens | What fixes it |
|---|---|---|
| Context loss | Hour one's constraint falls out of the window | Compaction that keeps the decisions, not the transcript |
| Session death | The terminal closes; the run goes with it | A resident process that owns the run |
| First-failure stop | A red build ends the turn with a summary | Recovery with a retry budget |
| Silent finish | The agent reports success nobody checked | A gate the agent does not grade |
What is context compaction?
Compaction is what a harness does when a conversation approaches the model's window: it summarises the older part of the run into a durable form and keeps the recent part verbatim, so the agent carries forward its decisions instead of its transcript. In Relay the split is a setting — 16,384 tokens reserved for the prompt and response, 20,000 tokens of recent turns kept intact — because the right boundary depends on the model you brought.
The subtle part is what survives. A summary that keeps "we tried the ORM and reverted it" is worth more than one that keeps the last twenty tool calls, because the first prevents a repeat and the second is already in the diff.
How does a run survive a closed laptop?
By not living in your terminal. Relay's agents run as background processes with their own lifecycle: you start one, detach, and reattach later from anywhere — relay list shows what is running, relay attach puts you back in the room, and relay send gives a running agent a new instruction without interrupting it.
That is the difference between an agent you are using and an agent you are employing. One occupies a window. The other occupies a slot in the day.
Most agents are sprinters. Long-horizon work is a shift, and a shift needs someone who stays.
How long should a long-horizon run be allowed to go?
As long as its budget says, and not one turn longer. Unbounded autonomy is not ambition; it is an unattended process burning your provider's tokens on a goal it may have misread in the first ten minutes. Relay makes every bound explicit — assistant turns, tokens, wall-clock milliseconds, retries per gate — and a run that hits one stops with what it has rather than pretending to be finished.
relay --goal "split the monolith's billing module into its own package" \ --goal-token-budget 400000 --autonomous --autonomous-timeout-ms 28800000
A budget is also the honest answer to "what did this cost?" — a number you set beforehand rather than one you discover afterwards.
Is a long-horizon agent the same as an autonomous one?
No, though they usually travel together. Autonomy is about who advances the loop; long-horizon is about how long the loop must survive. A five-minute run can be fully autonomous, and a two-day task can be supervised step by step. The reason the words blur is that anything genuinely long-horizon has to be autonomous for most of its life, simply because you are not there — autonomous coding agents, explained covers that half, and the harness covers what holds the rest together.