Long-Running Coding Agents: The 2026 Guide

The practical guide to keeping AI coding agents running for hours, days, and beyond: context management, autonomous loops, and the tools that make it work.

Claude Code's /goal command shipped in May 2026, and within a week, developers reported agents completing 52-hour coding tasks without human intervention. That is not a typo. Cursor's background agents have been running autonomously for over 30 hours on single features. OpenAI's Codex processes tasks that take up to 30 minutes in isolated cloud sandboxes, with parallel execution across multiple repositories. Devin manages multi-day engineering projects through parent-child session hierarchies. The era of "ask a question, get an answer" coding assistants is over. We are now in the era of long-horizon autonomous engineering.

But running a coding agent for hours instead of minutes introduces an entirely new class of problems. Context windows fill up. The agent loses track of what it was doing. Token costs spiral. The model starts hallucinating because it can no longer see the code it wrote three hours ago. These are not theoretical concerns. 65% of enterprise AI failures in 2025 were attributed to context drift or memory loss, not raw capability limitations - Mem0.

This guide breaks down every tool, technique, and platform that exists in 2026 for keeping coding agents running as long (and as usefully) as possible. We cover the exact mechanics of /goal, context compression, subagent isolation, cloud sandboxes, memory systems, and the open-source alternatives that compete with the big players. Whether you are running a single Claude Code session overnight or orchestrating hundreds of Cursor agents across a monorepo, this is the operational playbook.

Written by Yuma Heymans (@yumahey), founder of O-mega, who builds autonomous AI agent systems that run multi-hour browser automation, computer sessions, and delegated engineering tasks across parallel workstreams.

Contents

1. The Fundamental Problem: Why Coding Agents Hit Walls
2. Context Windows in 2026: The Raw Numbers
3. Claude Code /goal: The Autonomous Coding Loop
4. Agent View and Multi-Session Orchestration
5. Context Compression and Memory Systems
6. OpenAI Codex: The Cloud Sandbox Approach
7. Cursor Background Agents: Multi-Day Autonomous Work
8. Devin, GitHub Copilot, and the Broader Ecosystem
9. Aider and Open-Source Long-Horizon Tools
10. MCP: Extending Agent Reach Without Bloating Context
11. Hooks, Headless Mode, and CI/CD Automation
12. Subagents: Parallel Work With Isolated Context
13. Dreaming, Outcomes, and Self-Improving Agents
14. The Decision Framework: Choosing Your Stack
15. What Comes Next

---

1. The Fundamental Problem: Why Coding Agents Hit Walls

The structural question behind long-running coding agents is not "how do we make models smarter" but rather "what happens when an intelligent system must maintain coherent state across a problem that takes longer than its working memory allows?" This is the same constraint that limits human cognition during marathon debugging sessions, but the mechanics are different and the solutions are more precise.

Every language model operates within a fixed context window, a buffer of tokens that represents everything the model can "see" at once. When a coding agent reads files, writes code, runs tests, reads error output, edits more files, and iterates, each of those actions consumes tokens. The context window fills up. Once it is full, something must be discarded, compressed, or moved elsewhere. The question of which information to keep and which to discard is the core engineering challenge of long-running agent systems.

The problem compounds because coding tasks are not linear. A bug fix might require reading 15 files across 4 directories, understanding 3 different abstraction layers, running tests, interpreting stack traces, and then modifying code in a location far removed from where the symptom appeared. Each step generates context. A 30-minute debugging session can easily consume 50,000-80,000 tokens of context just from tool call inputs and outputs. A 4-hour feature implementation can blow through 200,000 tokens multiple times. As we explored in our guide to self-improving AI agents, the ability to maintain coherent behavior across extended interactions is what separates useful autonomous systems from expensive autocomplete.

There are three failure modes that kill long-running agents. Context overflow is the most obvious: the window fills, the agent loses access to information it needs, and it starts making decisions based on incomplete state. Context drift is subtler: the agent can still see its recent actions but has lost the original intent, requirements, or architectural decisions from early in the session, causing it to gradually deviate from the goal. Token cost explosion is the economic failure: even if the agent stays coherent, running a 1M-token-context model for 8 hours at full utilization generates costs that may not justify the output. Each of these failure modes has specific countermeasures, and the platforms that emerged in 2026 address them in fundamentally different ways.

---

2. Context Windows in 2026: The Raw Numbers

The context window landscape shifted dramatically in early 2026. What was a 200K-token ceiling for most production models a year ago is now routinely 1 million tokens across the major providers. This expansion is the single biggest enabler of long-running coding agents, but the raw numbers tell only part of the story.

Claude Opus 4.7, released April 16, 2026, operates with a 1,000,000-token context window and was specifically optimized for extended agentic coding tasks - Anthropic. Its predecessor, Claude Opus 4.6, introduced the 1M window in beta on February 5, 2026, with a measured 14.5-hour task completion time horizon. That number represents the longest single-session autonomous coding run Anthropic publicly benchmarked before the agent needed a fresh context. Claude Sonnet 4.6, released February 17, 2026, also supports 1M tokens and is the first Sonnet-tier model preferred over the previous generation's Opus in coding evaluations.

On the OpenAI side, GPT-5.5 launched April 23, 2026 as the new flagship, succeeding GPT-5.4 - CNBC. The GPT-5.4 family already supported 1M-token contexts through the API. Google's Gemini 3.1 Pro, released February 19, 2026, maintains a 1M-token window, while the earlier Gemini 1.5 Pro still holds the record at 2,000,000 tokens - Elvex. Meta's Llama 4 Scout pushed the open-weight frontier to a 10-million-token context window using a mixture-of-experts architecture with 17B active parameters across 16 experts - Meta AI.

But here is what the raw numbers obscure: most models degrade well before their advertised limit. A 200K-token model typically starts losing coherence around 130,000 tokens. The degradation is not gradual. It tends to be sudden, with retrieval accuracy dropping off a cliff at around 65-85% of the nominal capacity. This is why Claude Code's automatic compaction triggers at approximately 83.5% of the context window (roughly 167K tokens on a 200K window), not at 100%. The system is designed to compress before the model enters the degradation zone.

The practical implication for long-running agents is that a 1M-token window does not give you 5x the useful runtime of a 200K-token window. It gives you perhaps 3-4x, depending on how aggressively the agent manages its context. The quality of the context management strategy matters as much as the raw window size. This is why, as we documented in our complete guide to the Anthropic ecosystem, Anthropic invested as heavily in compaction infrastructure as in expanding the window itself.

The economic dimension is equally important. Running a coding agent at full 1M-token context for extended periods is expensive. Claude Opus 4.7 uses up to 35% more tokens than Opus 4.6 for the same text due to its enhanced reasoning. At current API pricing, an 8-hour session at high utilization can cost anywhere from $50 to $200+ depending on the model and the density of tool calls. This is why efficient context management is not just a technical concern but an economic one: every unnecessary token in the context window is money that produces no value.

---

3. Claude Code /goal: The Autonomous Coding Loop

The /goal command, released in Claude Code v2.1.139 in May 2026, is the most significant addition to the autonomous coding toolkit this year. It transforms Claude Code from a turn-by-turn assistant into a self-directed agent that works continuously toward a defined outcome - Claude Code Docs.

The mechanic is straightforward. You set a condition, and Claude keeps working, turn after turn, until that condition is met. There is no timeout, no fixed iteration count, and no manual intervention required unless you choose to interrupt. The agent evaluates its own progress after each turn using a fast model (defaults to Haiku) that reads the conversation transcript and determines whether the condition has been satisfied. A "no" result tells Claude to keep going and includes the evaluator's reasoning as guidance for the next iteration. A "yes" clears the goal and records completion.

Here is what it looks like in practice:

/goal all tests in test/auth pass and the lint step is clean

That single line starts an autonomous loop. Claude will read the test files, run the test suite, analyze failures, edit code, re-run tests, fix lint errors, and iterate until every test passes and lint is clean. The /goal indicator shows elapsed time and remains visible throughout. You can check status at any point:

/goal
# Shows: condition, duration, turn count, token spend, evaluator reason

Anthropic's official announcement video walks through the Agent View and /goal features that shipped together in the May 2026 update.

The design decisions behind /goal reveal a sophisticated understanding of what makes long-running agents fail. The condition can be up to 4,000 characters, allowing highly specific success criteria. You can include scope-limiting clauses like "or stop after 20 turns" to bound runtime. Only one goal is active at a time, so there is no ambiguity about what the agent is working toward. When a session ends with an active goal, the goal is restored on --resume or --continue, though the turn count and timer reset.

The evaluation model is deliberately separate from the working model. Claude Opus or Sonnet does the actual coding work, while Haiku evaluates progress. This separation matters for two reasons. First, it prevents the working model from "grading its own homework," a pattern that leads to premature completion claims. Second, Haiku is fast and cheap, so the evaluation overhead is negligible even across hundreds of turns.

There is a critical distinction between /goal and other autonomous approaches. The table below captures how the three main mechanisms differ:

The /goal approach is most powerful for tasks where the completion condition is objectively verifiable: tests pass, linting is clean, the build succeeds, a specific API endpoint returns the expected response. It is less suited for subjective tasks ("make the code cleaner") because the Haiku evaluator has limited ability to judge aesthetic quality without concrete metrics.

The 4,000-character condition limit is more expressive than it appears. Developers have reported using multi-clause conditions that effectively encode entire acceptance criteria:

/goal "all tests in test/auth/ and test/api/ pass AND \
  no TypeScript errors from tsc --noEmit AND \
  the /api/health endpoint returns 200 AND \
  coverage for src/auth/ is above 80%"

Each clause gives the agent a concrete sub-goal, and the evaluator checks all of them before declaring completion. This turns /goal into a specification-driven development tool: you write the acceptance criteria, the agent writes the code. The approach works particularly well for test-driven development workflows, where the tests already define what "done" means. You write the failing tests, set a /goal to make them pass, and the agent iterates until every assertion succeeds.

For non-interactive use, /goal integrates with headless mode:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

This makes it possible to run goal-directed agents in CI pipelines, cron jobs, or orchestration systems without human supervision. Combined with --max-turns and --max-budget-usd, you get autonomous execution with hard safety limits. As discussed in our Claude Code pricing guide, understanding these cost control mechanisms is essential before running extended autonomous sessions.

---

4. Agent View and Multi-Session Orchestration

Running one long-lived agent is useful. Running twelve simultaneously is transformative. Agent View, released as a Research Preview on May 11, 2026, provides a CLI dashboard for managing multiple Claude Code sessions in parallel - Claude Code Docs.

The interface shows all active sessions lined up by status, each with an icon indicating whether it is working, waiting for input, or completed. You launch it with claude agents and start background sessions with claude --bg "prompt". The key innovation is not the dashboard itself but the underlying infrastructure: each session gets its own context window, its own git worktree (if using worktree isolation), and its own independent execution environment. There is no shared state between sessions unless you explicitly coordinate through the filesystem.

This architecture enables a pattern that Anthropic calls multi-agent orchestration, which entered Public Beta at the Code with Claude event on May 6, 2026 - Simon Willison. A lead agent can delegate to specialist sub-agents running in parallel on a shared filesystem. One agent refactors the database layer while another writes tests while a third updates documentation. The lead agent coordinates and merges results.

The practical impact on long-running tasks is profound. Instead of one agent grinding through a 10-hour task sequentially (accumulating context the entire time), you can decompose the work into 5 parallel 2-hour tasks. Each sub-agent operates with a fresh, focused context window. The lead agent's context stays small because it only tracks high-level status, not implementation details. This is context management through architectural decomposition rather than compression.

The peek-and-reply feature lets you monitor any session's current state and send it messages without leaving the dashboard. This is important for long-running tasks because it means you can course-correct an agent that is heading in the wrong direction without restarting the entire session. You can see what each agent is doing, what files it is editing, and what its current reasoning is, all from one terminal view.

At the Code with Claude event, Anthropic also announced that rate limits were doubled across all consumer plans (Pro, Max, Team, Enterprise) and peak-hour throttling was eliminated entirely. This is a direct enabler for long-running agents, since rate limits were previously the most common practical constraint on extended sessions. A 4-hour coding session that previously would have hit rate limits 3-4 times can now run uninterrupted. The rate limit expansion was backed by a 300+ megawatt compute partnership with SpaceX's Colossus facility, providing 220,000+ NVIDIA GPUs of additional capacity - Dotzlaw.

As we covered in our Claude managed agents guide, this multi-agent orchestration model extends beyond coding into any domain where parallel autonomous work is valuable.

---

5. Context Compression and Memory Systems

Context management is the most technically complex challenge in long-running agent design. The fundamental tension is between retaining enough information for the agent to make good decisions and keeping the context window small enough for the model to process efficiently. Every platform resolves this tension differently, and understanding the trade-offs is essential for choosing the right approach.

Anthropic's compaction API (beta header compact-2026-01-12) is the most transparent implementation available. When input tokens exceed a configurable threshold (default 150,000, minimum 50,000), the system generates a summary of the conversation history, creates a compaction block, and drops all message blocks prior to it - Anthropic. Subsequent requests continue with the compacted context, dramatically reducing token count while preserving the essential state.

The key engineering detail is the pause_after_compaction flag. When set to true, the API returns with stop_reason: "compaction" instead of continuing automatically. This gives your application a chance to inject additional context, re-state important instructions, or modify the summary before the agent continues. This is critical for long-running agents because compaction can inadvertently drop persistent rules or architectural decisions that were stated early in the conversation. Without re-injection, the agent may "forget" your coding standards, project constraints, or testing requirements after compaction.

In Claude Code specifically, the /compact command triggers manual compaction, and automatic compaction kicks in at approximately 83.5% of the context window. Best practice is to run /compact proactively at around 60% utilization, because the quality of the summary is higher when the model has more headroom to work with.

Beyond compaction, the broader field of agent memory has matured significantly. The Mem0 platform published benchmarks in 2026 comparing three approaches to long-context management - Mem0:

These numbers are striking. Mem0 achieves 90% fewer tokens and 91% lower latency at the cost of a 6-point accuracy gap. For many long-running agent tasks, this trade-off is worth it. An agent that runs 10x longer at 67% accuracy may produce better total output than one that runs 1x at 73% accuracy, especially if the accuracy gap is in peripheral details rather than core logic.

The Focus architecture, documented by Analytics Vidhya, introduces two primitives to the ReAct loop: start_focus and complete_focus - Analytics Vidhya. The agent declares what it is investigating at each checkpoint, allowing the system to scope compression around investigation boundaries. When a focus completes, only the conclusion is retained, not the full exploration trace. This mirrors how human developers think: you investigate a hypothesis, reach a conclusion, and carry forward only the conclusion (not every stack trace and log line you read along the way).

Content offloading addresses a specific pattern where tool call outputs are enormous. When a tool returns more than 20,000 tokens (a common scenario when reading large files or running verbose tests), the output is written to a persistent file and replaced in context with a reference. The agent can re-read the file if needed, but the tokens do not permanently occupy the context window. This single technique can extend useful session duration by 2-3x for codebases with large files.

Embedding-based compression stores historical turns as dense vector embeddings rather than full text. Only semantically relevant segments are reconstructed for each new turn, achieving 80-90% token reduction for stored history. The trade-off is retrieval latency and the occasional loss of precise details that were not captured in the embedding. For long-running agents that revisit previous decisions infrequently, this approach is highly effective.

A tiered memory architecture combines these techniques: pin critical facts (project structure, coding standards, the current goal) into an immutable store. Maintain shorter-term compressed traces for recent activity. Checkpoint snapshots before major compression passes so that if the compression is too aggressive, the agent can recover. This is the pattern used by platforms like O-mega for multi-hour autonomous sessions where the agent must maintain coherent behavior across browser automation, code generation, and complex multi-step tasks.

---

6. OpenAI Codex: The Cloud Sandbox Approach

OpenAI's Codex takes a fundamentally different architectural approach to long-running tasks. Instead of running on your local machine with access to your full filesystem, Codex executes each task in an isolated cloud sandbox preloaded with a snapshot of your repository - OpenAI.

The sandbox is a container using a "universal" base image with pre-installed languages, package managers, and common tools. When you start a task, Codex copies your repo into the container, runs dependency installation (npm, pip, poetry, etc.) with full internet access, then locks down the network before the agent begins working. This two-phase design (open network for setup, restricted network for execution) is a security measure that prevents the agent from exfiltrating code or reaching arbitrary endpoints during its work.

Most Codex tasks complete in 1 to 30 minutes. This is deliberately shorter than Claude Code's multi-hour sessions. OpenAI optimized for throughput over duration: instead of one agent running for 8 hours, you run 16 agents for 30 minutes each in parallel. The container state caches for up to 12 hours, so sequential tasks on the same repo do not need to re-install dependencies.

The April 2026 update added several features aimed at extending Codex's effective task horizon. Persisted /goal workflows allow multi-step tasks that span beyond a single sandbox execution. Thread automations enable chains of tasks that hand off results between containers. The Codex macOS desktop app manages multiple agents, providing a visual interface for parallel long-running work. Codex now runs on GPT-5.5, released April 23, 2026, which provides stronger coding performance than its predecessors - OpenAI.

The trade-offs between local execution (Claude Code) and cloud sandboxes (Codex) are structural:

For long-running tasks, the local approach gives you continuity, the agent can reference previous work, access local databases, run local servers, and interact with your full development environment. The cloud approach gives you isolation and parallelism, each task starts clean, cannot corrupt your environment, and you can run many simultaneously. The right choice depends on whether your bottleneck is task depth (favoring local, long context) or task breadth (favoring cloud, parallel execution).

As analyzed in our top 50 AI coding agent frameworks benchmark, the architectural distinction between local and cloud execution is the most consequential design decision in the agent framework space, with implications for security, cost, and capability.

---

7. Cursor Background Agents: Multi-Day Autonomous Work

Cursor's background agents represent the most aggressive push toward truly long-running autonomous coding. Launched as a research preview on February 12, 2026, these agents have demonstrated sustained autonomous work for periods that dwarf other platforms, commonly running for more than a day on complex tasks - Cursor.

The real-world numbers from Cursor's research preview are remarkable. Users reported a chat platform integration that ran for 36 hours. A mobile app implementation ran for 30 hours. An auth and RBAC refactoring took 25 hours. An infrastructure task ran for 52 hours. These are not contrived benchmarks. These are production engineering tasks completed by background agents with minimal human intervention.

Each background agent runs in an isolated Ubuntu VM in the cloud, not on your laptop. The February 2026 update added Computer Use capabilities, giving each agent its own browser for visual verification. Agents create pull requests with demo screenshots and video recordings as evidence of feature completion. This addresses a key problem with long-running agents: how do you verify what an agent did over 30 hours without reading every line of its output? The answer is: the agent documents its own work visually.

Cursor's scaling experiments pushed the boundaries further. In a controlled test, they ran hundreds of concurrent agents on a single project, producing over 1 million lines of code across 1,000 files in one week, consuming trillions of tokens - Cursor. Specific projects included a Java LSP implementation (550K lines), a Windows 7 emulator (1.2M lines), and an Excel implementation (1.6M lines).

The multi-agent coordination architecture evolved through three iterations, each revealing fundamental lessons about how agents work at scale. The first attempt used a flat structure where all agents could access all files. This failed because of lock bottlenecks: agents constantly stepped on each other's work. The second attempt used optimistic concurrency control, where agents worked independently and merged results. This failed because agents became risk-averse, avoiding changes that might conflict with other agents. The third and successful attempt used a planner-worker pipeline. Planner agents explore the codebase and create task specifications. Worker agents complete assignments based on those specs without needing to coordinate with each other. This separation eliminates inter-worker coordination overhead while maintaining coherent overall direction.

A key finding from the scaling experiments: periodic fresh starts are essential to combat drift and tunnel vision. Even with large context windows, agents that run for extended periods develop "opinions" about the codebase that may not match reality. Periodically resetting the agent's context (while preserving its artifacts) produces better results than letting it run indefinitely. This finding aligns with the compaction-based approach used by Claude Code, where context is periodically compressed rather than allowed to grow unbounded.

Cursor also found that different models excel at different roles. Their experiments tested multiple models across planner and worker roles, and GPT-5.5 significantly outperformed other options for extended autonomous work. This suggests that model selection should be role-specific, not one-size-fits-all. A cheaper, faster model might be ideal for planning (which requires broad understanding but not deep implementation) while a more capable model handles the actual code generation.

Background agents are available to Ultra, Teams, and Enterprise Cursor users. The self-hosted variant allows companies to run background agents on their own infrastructure, addressing data sovereignty concerns.

The February 2026 update also added Computer Use capabilities that go beyond code editing. Each background agent gets its own browser within its Ubuntu VM, enabling visual verification workflows. The agent can navigate a web application, take screenshots to verify that UI changes render correctly, and include those screenshots as evidence in the resulting pull request. For front-end work that runs for many hours, this visual feedback loop prevents a common failure mode where the agent produces code that compiles and passes unit tests but looks completely wrong. The video recordings of agent sessions provide a complete audit trail of what the agent did, how the application looked at each step, and where it made decisions.

This visual verification capability is particularly relevant for long-running agents because errors compound over time. If an agent makes a small CSS mistake in hour 2 of a 30-hour session, every subsequent UI change builds on that mistake. With browser-based visual checks, the agent can catch and correct rendering issues iteratively, just as a human developer would by checking their browser after each change. The overhead of running a browser adds approximately 15-20% to session duration, but the error-correction benefit often more than compensates.

For teams considering long-running agents in production, our guide to building AI agents covers the architectural patterns that underpin these systems.

---

8. Devin, GitHub Copilot, and the Broader Ecosystem

The long-running agent landscape extends well beyond Claude Code, Codex, and Cursor. Several platforms have carved out distinctive approaches to autonomous coding over extended time horizons.

Devin by Cognition positions itself as a full-service autonomous software engineer rather than a coding assistant. Its 2026 feature set centers on multi-agent orchestration with isolated virtual machines - Devin. The parent session acts as a coordinator, spawning child sessions that each run in their own VM with structured JSON output schemas. This architecture handles long-running tasks by decomposing them across isolated execution environments, similar to Cursor's approach but with tighter orchestration primitives.

Devin's 2026 improvements directly target long-horizon work. 3x faster startup time (February 2026) reduces the overhead of spawning new sessions. Fast Mode provides approximately 2x faster responses at 4x the ACU (compute unit) cost per session, a trade-off that makes sense for time-sensitive long-running tasks where wall-clock time matters more than cost. Recurring sessions allow you to configure automated tasks with specific frequency, prompt, and playbook, essentially creating persistent agents that run on a schedule. Enterprise features include ACU hard caps per session to prevent runaway costs and MCP server allowlists for tool governance.

The parent-child session model is Devin's most distinctive feature for long-running work. A parent session can manage up to 75 MB of file attachments (increased from 20 MB in 2026), coordinate multiple children running in parallel, and aggregate their structured outputs. Session permalinks, search by tags, and time-range filtering make it possible to audit what happened across a multi-day engineering effort. For organizations that need full traceability of AI-generated work, this is a significant differentiator.

GitHub Copilot evolved from a completion tool into an autonomous agent system in 2026. The agent mode reached general availability in March 2026 for VS Code and JetBrains - GitHub. In this mode, Copilot determines which files to edit across the entire project, runs terminal commands, reviews outputs, and iterates on errors. It handles multi-step coding tasks autonomously within the IDE.

The cloud coding agent extends this further. You assign a GitHub issue to Copilot, and it works autonomously in a GitHub Actions environment, opens a pull request when done, and includes agentic code review that gathers full project context before suggesting changes - GitHub. This is a different model for long-running work: instead of an interactive session that runs for hours, it is a fire-and-forget task that produces a PR. The "duration" is typically 10-30 minutes, but the ergonomic benefit is that it runs entirely in the background with no IDE session required.

GitHub is shifting Copilot to a usage-based pricing model starting June 2026. The free tier provides 2,000 code completions and 50 chat requests per month. This pricing shift matters for long-running agent use because it directly ties cost to the number of agent interactions, making extended sessions more expensive than before.

Amazon Q Developer has climbed to the highest scores on the SWE-Bench Leaderboard for agentic capabilities, demonstrating strong performance on the benchmark most relevant to long-running coding tasks. Its free tier is notably generous: unlimited code suggestions plus full security scanning plus 50 agentic requests per month. The Pro tier at $19/user/month provides expanded limits. Q Developer's strength is its integration with AWS infrastructure, making it particularly effective for codebases that interact heavily with AWS services.

For a broader competitive analysis, our top 10 open-source AI coders guide covers the alternatives that do not require a commercial subscription, and our text indexing for AI coding agents guide explains the retrieval architectures that underpin these systems.

---

9. Aider and Open-Source Long-Horizon Tools

The open-source ecosystem for long-running coding agents has matured significantly, with aider being the most established project. Aider's approach to context management is architecturally distinct from the commercial platforms and offers important lessons about how to build long-running agents efficiently.

Instead of trying to fit the entire codebase into context and then compressing when it overflows, aider uses a repository map system that provides the model with a concise structural overview of the entire git repository - Aider. The map shows the most important classes, functions, types, and call signatures, selected through a graph ranking algorithm. Each source file is a node, edges connect files with dependencies, and the algorithm prioritizes identifiers that are most frequently referenced by other code.

The default token budget for the repo map is just 1,000 tokens (controlled via the --map-tokens flag). This is remarkably small. The map dynamically adjusts based on chat state, expanding when no files have been explicitly added to the chat and contracting when the conversation includes specific file content. For large repositories, aider sends only the most relevant portions of the map, selected through the ranking algorithm.

This design philosophy is the inverse of the "large context window" approach. Where Claude Code and Codex rely on massive context windows to hold as much information as possible, aider assumes the model should see as little as possible while still being effective. Files explicitly added to the chat get their full content. Everything else is represented only through the ranked map. The model navigates the codebase using the map as a compass, requesting specific files only when needed.

The tree-sitter based parsing that generates the repo map is language-aware, meaning it understands the syntax of Python, JavaScript, TypeScript, Go, Rust, and dozens of other languages. It does not just tokenize files. It extracts semantic structure: class hierarchies, function signatures, import relationships, and type definitions. This structural understanding means the repo map captures the architecture of the codebase, not just its text. When the agent needs to modify a function, the map tells it which other functions call it, which types it depends on, and which modules import it, all without loading those files into context.

For repositories with hundreds or thousands of files, this approach is particularly powerful. A 200-file TypeScript project might generate a 3,000-token repo map that captures every important interface, component boundary, and service dependency. The agent can reason about the full architecture while consuming only 1.5% of a 200K-token context window. Compare this to loading every file: even reading just the first 50 lines of each file would consume 50,000+ tokens, and the agent still might not grasp the architectural relationships between them.

For long-running sessions, this has a profound advantage: the context window grows slowly because the baseline overhead is minimal. A typical aider session might use only 5,000-10,000 tokens of context for a 500-file repository, leaving the vast majority of the context window available for actual work. This means aider can theoretically sustain useful work for longer periods before needing compaction, even on smaller context windows.

The trade-off is discoverability. An agent with a full 1M-token context window can sometimes find relevant code by pattern-matching across everything it has seen. Aider's agent can only find code that appears in its repo map or that it explicitly requests. If the relevant code is in a file that the ranking algorithm deprioritized, the agent may not find it without help.

Other notable open-source tools for long-running work include SWE-agent from Princeton, which standardizes the interface between language models and coding environments, and OpenHands (formerly OpenDevin), which provides a sandboxed execution environment similar to Codex but fully open-source. The open-source personal AI guide covers the broader landscape of self-hosted agent systems.

The common pattern across all open-source solutions is an emphasis on tool-mediated interaction over raw context. Instead of dumping entire files into the context window, these systems provide precise tools (read specific lines, search for symbols, run targeted tests) that minimize context consumption per action. This principle applies equally to commercial platforms, and the most effective long-running agent workflows combine large context windows (for resilience) with precise tool usage (for efficiency).

---

10. MCP: Extending Agent Reach Without Bloating Context

The Model Context Protocol (MCP) is the most important infrastructure development for long-running agents that most developers still underutilize. Released by Anthropic in late 2024, MCP has become the de facto standard for connecting AI agents to external tools and data sources - MCP Roadmap.

MCP matters for long-running agents because of how it handles data flow. Traditional tool integrations return full results into the context window. A database query returns all rows. A file read returns the entire file. A web API call returns the full response body. Each of these consumes tokens that persist in context until compaction. MCP's three capability types (Tools, Resources, and Prompts) are designed to minimize this overhead.

Tools execute server-side and return only processed results. Instead of the agent pulling raw data and processing it in-context, the MCP server does the processing and returns a concise result. A database MCP server can run a query and return just the relevant rows, not the entire table. A GitHub MCP server can fetch a PR diff and return only the changed sections, not the full file contents. This reduces context consumption by 10-100x for data-heavy operations.

Resources are data entities fetched on-demand rather than preloaded. An MCP server can expose a codebase as a set of resources that the agent browses selectively, rather than loading everything into context at session start. This is similar to aider's repo map approach but standardized across any data source.

The ecosystem has grown to over 500 public MCP servers with official SDKs in TypeScript, Python, C#, Java, and Swift - WorkOS. Native support from OpenAI, Google, and the broader tooling ecosystem means MCP is no longer an Anthropic-specific standard.

For long-running agent workflows, the 2026 MCP roadmap includes two features that directly improve session longevity. Stateless HTTP transport (in review) allows MCP servers to scale horizontally behind standard load balancers without maintaining persistent SSE connections. This makes MCP infrastructure more reliable for multi-hour sessions where a persistent connection might drop. Webhooks for MCP servers enable proactive data pushes, meaning agents can receive notifications about external events (test failures, deployment completions, code review comments) without polling, which would consume context on each poll cycle.

A practical example: consider a long-running agent that needs to monitor a CI pipeline while simultaneously writing code. Without MCP, the agent would need to periodically run git status and curl commands, consuming context on each check. With an MCP server wrapping the CI API, the server monitors the pipeline and pushes only failure notifications to the agent, consuming zero context until something actually needs attention.

Another powerful pattern is using MCP servers for database interaction during long-running sessions. A coding agent working on a web application often needs to query the database to understand existing data structures, verify that migrations succeeded, or check that seed data matches expected formats. Without MCP, each database query results in the full result set being injected into the context window. A SELECT * FROM users LIMIT 100 might return 50,000 tokens of formatted output. With a PostgreSQL MCP server, the agent can ask structured questions ("what columns does the users table have?", "how many records match this condition?") and receive only the specific answers. Over a multi-hour session with dozens of database interactions, the token savings compound to the point where MCP-mediated database access can extend useful session duration by 3-5x compared to raw SQL output in context.

The same principle applies to log analysis. A long-running agent debugging a production issue might need to search through gigabytes of application logs. Without MCP, the agent runs grep commands and the output floods the context. With a log analysis MCP server (such as the Datadog or Grafana MCP servers now available in the ecosystem), the agent queries aggregated metrics and receives structured summaries. "Show me error rates by endpoint for the last hour" returns a 200-token summary instead of 50,000 tokens of raw log lines. This is not just an optimization. It is the difference between an agent that can debug for 6 hours and one that hits context limits in 45 minutes.

The MCP ecosystem's maturity in 2026 means most common developer workflows already have purpose-built servers. GitHub, GitLab, Jira, Linear, Slack, Docker, Kubernetes, PostgreSQL, MongoDB, Redis, Stripe, and dozens of other services have production-quality MCP implementations. Installing and configuring these servers before starting a long-running agent session is the single highest-leverage preparation step you can take.

For a comprehensive list of available MCP servers and their use cases, see our 50 best MCP servers guide, and for building custom servers tailored to your workflow, the MCP server creation guide.

---

11. Hooks, Headless Mode, and CI/CD Automation

Long-running agents are most powerful when they operate without human supervision. Claude Code's hooks system and headless mode provide the infrastructure for fully autonomous, unattended agent operation in CI/CD pipelines and scheduled tasks - Claude Code Docs.

Hooks are user-defined shell commands that fire at specific points in the agent lifecycle. For long-running agents, the most relevant hook events are:

SessionStart fires when a session begins, with matchers for new, resume, and compact. The compact matcher is critical: it fires after every context compaction, giving you a chance to re-inject instructions that may have been compressed away. This is the single most important hook for maintaining coherent long-running behavior.

{
  "hooks": {
    "SessionStart": [{
      "matcher": "compact",
      "hooks": [{
        "type": "command",
        "command": "echo 'IMPORTANT: Use Bun, not npm. Run bun test before every commit. Target branch is main.'"
      }]
    }]
  }
}

Stop fires when Claude finishes a turn. Prompt-based hooks at this event can evaluate whether to continue working, providing custom logic beyond what /goal's built-in evaluator offers. For example, you could check whether a deployment succeeded by hitting a health endpoint, something the Haiku evaluator cannot do.

PreToolUse fires before any tool call. With exit code 2, you can block specific actions. This is essential for long-running agents that should never touch certain files, never delete production data, or never commit directly to main. A pre-tool hook on Bash can intercept dangerous commands before execution.

Notification fires when Claude needs input. Matchers include permission_prompt, idle_prompt, and others. For unattended operation, hooking this event to send a Slack message or push notification means you can respond to permission prompts from your phone while the agent continues working on everything else.

Headless mode strips Claude Code down to a non-interactive execution engine. The core flags for CI/CD integration - Claude Code Docs:

# Basic headless execution
claude -p "Fix all failing tests in src/auth/" --max-turns 20 --max-budget-usd 5

# With tool restrictions and JSON output
claude -p "Review this PR for security issues" \
  --allowedTools "Read,Grep,Glob" \
  --permission-mode dontAsk \
  --output-format json

# Bare mode for CI (skips all auto-discovery)
claude --bare \
  -p "Generate unit tests for src/utils/" \
  --max-turns 15 \
  --output-format stream-json

The --bare flag is important for CI environments because it skips auto-discovery of hooks, skills, plugins, MCP servers, auto-memory, and CLAUDE.md files. This makes execution deterministic and fast, at the cost of losing the customizations that make interactive sessions more powerful.

For multi-step automation, sessions can be chained:

# Step 1: Fix tests
session_id=$(claude -p "Fix failing tests" --output-format json | jq -r '.session_id')

# Step 2: Continue with the same context
claude -p "Now update the changelog" --resume "$session_id"

This session chaining enables long-running workflows that span multiple CI steps. The agent maintains its understanding of what it did in step 1 when it starts step 2, without re-reading the entire codebase.

The --json-schema flag deserves special mention for long-running automation. It constrains the agent's output to conform to a specific JSON Schema, making the results machine-parseable. Combined with --output-format json (which includes total_cost_usd in the response), you can build automated pipelines that track costs, parse structured results, and make decisions based on agent output without any human interpretation.

Stdin piping is capped at 10 MB as of v2.1.128, which is sufficient for passing build logs, error traces, or test output to the agent:

cat build-error.txt | claude -p 'diagnose the root cause and fix it' > diagnosis.txt

For organizations that want autonomous agents running on schedules rather than in response to CI events, Claude Code's Routines feature (launched April 14, 2026) provides cloud-based automation with scheduled, API, and GitHub event triggers. Pro plans get 5 runs per day, Max gets 15, and Team/Enterprise gets 25.

---

12. Subagents: Parallel Work With Isolated Context

Claude Code's subagent system provides the most fine-grained control over context isolation in any commercial coding agent. Subagents are named, isolated Claude instances running inside your session, each with its own context window, custom system prompt, specific tool access, and optional model selection - Claude Code Docs.

The architecture is defined through markdown files with YAML frontmatter, stored in .claude/agents/ (project-specific) or ~/.claude/agents/ (global):

---
name: researcher
description: "Searches documentation and summarizes findings"
model: haiku
allowed_tools:
  - Read
  - WebSearch
  - Grep
---
You are a research specialist. Search documentation and codebases
thoroughly. Return concise summaries with file paths and line numbers.
Never modify any files.

The critical property for long-running tasks is context isolation. Each subagent gets its own independent context window. When the main session delegates a task to a subagent, the subagent operates in its own context. Large outputs (test results, documentation, log files) are processed in the subagent's context window, and only distilled results return to the main session. This is a direct solution to the context bloat problem: instead of your main session's context filling up with raw test output, a subagent processes the output and returns "3 tests failed in auth/login.test.ts: lines 42, 67, 91."

The model selection field enables cost-aware delegation. Route exploratory research tasks to Haiku (fast, cheap) while keeping implementation work on Opus (capable, expensive). A long-running session that uses Haiku subagents for file search, documentation lookup, and test execution can reduce total costs by 50-70% compared to running everything on Opus.

Worktree isolation (isolation: worktree in the YAML) goes further by giving the subagent its own git worktree. The subagent cannot touch your working directory, and its changes exist on an isolated branch until you choose to merge them. This is the safest model for long-running autonomous work: even if the subagent goes off track and makes terrible changes, your main working directory is unaffected.

The parallel execution pattern is where subagents truly shine for long-running tasks. The main session can spawn multiple subagents concurrently:

Main session: "I need to refactor the auth module, add API tests, and update docs"
  → Subagent 1 (Opus, worktree): Refactors auth module
  → Subagent 2 (Opus, worktree): Writes API tests
  → Subagent 3 (Haiku): Updates documentation

All three work simultaneously. Main session waits for results.

This decomposition solves both the context problem and the duration problem. Instead of one 6-hour session that hits context limits 3 times, you get three 2-hour sessions that each stay well within their context budget. The total wall-clock time drops from 6 hours to 2 hours. The total token cost may be similar or lower (because each subagent's context is focused, not polluted with unrelated information).

The main session's context stays small because it only tracks delegation status and results, not the full implementation details. This is the same architectural principle behind Cursor's planner-worker model, but implemented at the single-developer level rather than requiring a cloud infrastructure team.

Subagents differ from Agent View sessions in an important way. Subagents work within a single session and share a parent-child relationship. Agent View sessions are independent parallel sessions with no built-in communication. For tasks that require coordination (e.g., one agent's output informs another's work), subagents are the right tool. For tasks that are truly independent (e.g., working on separate features that do not interact), Agent View sessions provide better isolation.

---

13. Dreaming, Outcomes, and Self-Improving Agents

The most forward-looking features for long-running agents go beyond single-session optimization. Dreaming, announced at the Code with Claude event on May 6, 2026, enables agents to review past sessions, extract patterns, and create persistent memories that improve future performance - Simon Willison.

The mechanism works by having an agent analyze up to 100 previous sessions, identifying recurring patterns, common errors, project-specific conventions, and successful strategies. These insights are stored as memories that inform future sessions. Harvey, the legal AI company, reported that task completion rates rose approximately 6x with dreaming enabled. The improvement comes from accumulated context that would otherwise be lost at the end of each session: coding standards, architectural decisions, debugging techniques specific to the codebase, and patterns of what works and what does not.

For long-running coding agents, dreaming addresses the "cold start" problem. Every new session starts with zero knowledge of the project beyond what is in the codebase and CLAUDE.md files. Dreaming pre-loads the agent with experiential knowledge: "last time I worked on the auth module, the tests failed because of a timezone issue in the mock data." This accumulated experience reduces the number of wasted iterations in each session, effectively extending the useful work per token spent.

Outcomes (Public Beta) adds a separate grading agent that evaluates task completion against defined rubrics. This is similar to /goal's evaluator but more structured. The grading agent is independent from the working agent, preventing self-assessment bias. Anthropic reported improvements of +10.1% for PowerPoint generation and +8.4% for Word documents with Outcomes enabled. The improvement likely comes from the agent iterating toward higher-quality outputs rather than stopping at "good enough," a pattern familiar to anyone who has used /goal with specific quality criteria.

The combination of Dreaming and Outcomes creates a feedback loop for long-running agent systems. Outcomes tells the agent how well it performed. Dreaming stores those performance insights for future sessions. Over time, the agent gets better at the specific types of tasks your organization cares about. This is the pattern we explored in depth in our self-improving software guide, where autonomous systems iteratively improve their own performance without human retraining.

The architectural implication is that "long-running" is no longer just about a single session. The agent's effective context now spans across sessions through persistent memory. A debugging session today informs a refactoring session tomorrow. A failed deployment teaches the agent patterns it will recognize in future deployments. The unit of agent work is shifting from "one conversation" to "one project over weeks or months."

This cross-session persistence also changes how you should think about context management within a single session. If the agent can store important insights as persistent memories (via dreaming or manual memory creation), it matters less that those insights get compressed away during in-session compaction. The critical information is preserved outside the context window, available for retrieval in future sessions. This decouples session duration from information retention, which is the fundamental advance that makes truly long-horizon agent work possible.

---

14. The Decision Framework: Choosing Your Stack

Selecting the right platform and configuration for long-running coding tasks depends on five structural factors that interact differently depending on your situation. This is not a "which tool is best" comparison. It is a framework for matching your constraints to the architecture that best serves them.

Factor 1: Task decomposability. If your task can be cleanly divided into independent sub-tasks that do not need to share state, parallel execution (Cursor Background Agents, Claude Code Agent View, Codex parallel containers) will outperform a single long-running session. If the task requires maintaining a single thread of reasoning across many steps (deep debugging, complex refactoring with cross-cutting concerns), a single extended session (Claude Code with /goal, Devin) is the better fit.

Factor 2: Security and data sensitivity. Cloud-based execution (Codex, Cursor Background Agents, Devin) means your code leaves your machine. Local execution (Claude Code, aider) keeps everything on your hardware. For codebases with regulatory constraints, trade secrets, or compliance requirements, this distinction is often the deciding factor. Cursor offers self-hosted cloud agents for organizations that need cloud-style parallelism with on-premises data residency.

Factor 3: Verification requirements. If you need full traceability of what the agent did (audit trails, step-by-step reasoning, every file it touched), Devin's session permalink system and Cursor's PR-with-video approach provide the richest audit capabilities. Claude Code's headless mode with JSON output provides structured cost and action tracking for CI environments. If verification is informal ("does it work?"), /goal with a testable condition is the most efficient approach.

Factor 4: Cost sensitivity. Running Claude Opus 4.7 at full 1M-token context for 8 hours is expensive. Running Haiku subagents for routine tasks and escalating to Opus only for complex reasoning cuts costs significantly. Codex's sandbox model caps per-task costs naturally (short-lived containers). Aider's minimal-context approach is the most cost-efficient for individual developers on API budgets. GitHub Copilot's free tier (50 chat requests per month) is the cheapest entry point for light automation.

Factor 5: Integration depth. If you need the agent to interact with databases, local servers, Docker containers, or custom tooling, local execution with MCP servers gives the most flexibility. If the agent only needs to read and write code, cloud sandboxes are simpler to manage. If the agent needs to use a browser for visual verification, Cursor's computer-use-enabled VMs and Devin's VM-based sessions are the most mature options.

The chart above shows maximum observed session durations, but duration alone is misleading. Codex and GitHub Copilot optimize for throughput (many short tasks in parallel) rather than individual session length. A system that runs 100 parallel 30-minute tasks may accomplish more total work than a single 52-hour session. The right metric is useful work per dollar, not hours per session.

For most development teams in 2026, the practical recommendation is a layered approach. Use Claude Code with /goal for single-developer tasks that require deep, sustained reasoning (debugging, refactoring, complex features). Use subagents to decompose work within those sessions and control costs. Use Agent View when you need to parallelize across independent features or modules. Use Codex or GitHub Copilot for CI-integrated automation (PR reviews, changelog generation, test fixes) where short, bounded tasks are the right unit of work. Use Cursor Background Agents when you need the maximum possible autonomous duration with visual verification. Use Devin when audit trails and structured multi-agent orchestration are requirements.

Platforms like O-mega approach this from a different angle entirely, providing an autonomous agent workforce that handles not just coding but also browser automation, research, file management, and cross-domain orchestration. For tasks that span beyond pure code (building a website, researching competitors, managing deployments), a general-purpose autonomous agent platform may be more effective than a coding-specific tool, as we discussed in our agentic business process automation guide.

---

15. What Comes Next

The trajectory of long-running coding agents points toward a future where the "session" abstraction disappears entirely. The agent simply knows your project, understands your goals, and works continuously. Several developments in 2026 hint at this direction.

Cross-session memory (Dreaming, persistent memories, CLAUDE.md conventions) means the agent's effective knowledge already spans beyond any single session. The next step is making this transparent: you open your terminal, the agent already knows what it worked on yesterday, what tests were failing, and what the next priority is. Claude Code's --continue and --resume flags are primitive versions of this. Dreaming is the sophisticated version. The gap between them will close.

Cost compression is making extended sessions economically viable for more use cases. Compaction reduces token waste. Subagent model selection routes cheap work to cheap models. Mem0-style memory extraction cuts 90% of tokens while retaining most accuracy. As these techniques mature, the cost of running an agent for 8 hours will approach the cost that running for 30 minutes costs today.

Reliability engineering for agents is an emerging discipline. When an agent runs for 52 hours, what happens if it crashes at hour 40? How do you resume without losing 40 hours of work? Cursor's cloud-based approach handles this through infrastructure (if the VM crashes, the agent restarts from a checkpoint). Claude Code's filesystem persistence handles it differently (the agent's artifacts exist as real files, so work survives session crashes). But neither approach has the sophistication of traditional distributed systems engineering. Expect frameworks for agent checkpointing, recovery, and idempotent resumption to emerge in the second half of 2026.

Multi-model composition is the most technically interesting frontier. Cursor's finding that different models excel at different roles suggests a future where a single "agent" is actually a team of models. A fast, cheap model plans. A capable, expensive model implements. A specialized model reviews. A reasoning model debugs. Each operates in its own context, communicates through structured interfaces, and the user sees only the aggregate result. This is already happening in a limited way (Claude Code uses Haiku for /goal evaluation), but it will become the default architecture for any long-running system that needs to optimize the cost-quality trade-off.

The fundamental economic question is whether long-running agents generate enough value to justify their cost. A 52-hour Cursor agent session consuming trillions of tokens is only valuable if the resulting code would have taken a human engineer more than 52 hours to produce, and the cost of the tokens is less than the cost of the engineer's time. The early evidence is positive: Cursor's scaling experiments produced functional implementations (Java LSP, Windows 7 emulator, Excel clone) that would take human teams weeks or months. But these were controlled experiments, not production deliveries. The gap between "agent produced a working prototype" and "agent produced production-ready, maintainable, secure code" is where the real test will play out over the coming months.

For developers and engineering organizations, the practical takeaway is that the tooling for long-running agents is ready. The remaining barriers are operational (learning the workflows, tuning the configurations, building the CI integrations) rather than technical. The agents can run for hours. The context management works. The cost controls exist. The question is no longer "can we do this" but "what should we do with it?" That question, as with most questions about AI capability, is better answered by experimentation than speculation.

The shift from "agent as tool" to "agent as colleague" is the structural transformation happening across the industry. Tools respond to requests. Colleagues take ownership of outcomes. Every feature discussed in this guide (goals, dreaming, outcomes, subagents, multi-session orchestration, persistent memory) moves coding agents further along that spectrum. The tools that win in 2026 will be the ones that make autonomous long-horizon work reliable enough that developers trust it, not just tolerate it.

The economic logic is clear. Developer time is the most expensive input in software engineering. If a long-running agent can reliably produce the first 80% of a feature (the scaffolding, the boilerplate, the test coverage, the documentation) while the developer focuses on the remaining 20% (architecture decisions, security review, user experience), the total output per developer hour increases dramatically. The platforms that make this delegation reliable, rather than merely possible, will define the next era of software development.

This guide reflects the long-running coding agent landscape as of May 2026. Capabilities, pricing, and platform features are evolving rapidly. Verify current details with each platform's official documentation before making infrastructure decisions.