[Feature]: Pluggable durable execution backend for long-running agent tasks

Is there an existing feature request for this?

• I have searched existing issues and feature requests, and this is not a duplicate.

Problem or Use Case

As a developer using OpenHands on real codebases, some agent tasks naturally take longer than a normal sandbox/session window.

Examples:

• installing large dependency trees
• running full test suites
• building large projects
• running benchmarks
• executing long shell commands
• generating artifacts
• running GPU-backed or compute-heavy tasks

When these tasks are tied too tightly to the current sandbox/runtime window, the agent can lose execution context, fail because of timeout limits, or leave the user without clear lifecycle state, logs, or output artifacts.

The use case I want to enable is:

OpenHands should be able to hand off heavier execution steps to a durable job runner, then continue tracking status, logs, and artifacts without the agent needing to babysit infrastructure directly.

Proposed Solution

Add a pluggable external execution provider interface for long-running agent tasks.

The default OpenHands runtime can remain unchanged, but users could optionally configure an external execution backend for heavier jobs.

A good provider interface could support:

• estimating a job before running, if supported
• submitting a job asynchronously
• returning a job_id immediately
• getting job status
• streaming or fetching logs
• cancelling a job
• listing output artifacts
• retrieving artifact download URLs

This would let OpenHands keep the agent/coding workflow, while the external execution backend handles long-running compute, lifecycle tracking, logs, and artifacts.

One possible backend for this could be Jungle Grid, which is built as an execution layer for AI agents and developer workloads.

An OpenHands integration could submit slow installs, builds, tests, benchmarks, or GPU-backed tasks to Jungle Grid, then let OpenHands poll status/logs and return artifacts when complete.

The important design point is that this should be async-first:

• submitting a job should not block until completion
• the provider should return a job_id quickly
• OpenHands should monitor execution state over time
• logs and artifacts should remain accessible after the job finishes

Alternatives Considered

No response

Priority / Severity

High - Significant impact on productivity

Estimated Scope

Medium - New feature with moderate complexity

Feature Area

Agent / AI behavior

Technical Implementation Ideas (Optional)

No response

Additional Context

This feature is mainly about separating agent reasoning from long-running execution.

For small commands, the current runtime is fine. But for heavier tasks, it would be useful for OpenHands to have a durable job abstraction instead of depending entirely on the current sandbox/session window.

Examples where this could help:

• large dependency installs
• full project builds
• long test suites
• benchmark runs
• browser automation runs
• code generation jobs that produce artifacts
• GPU-backed inference or fine-tuning tasks
• tasks where logs and outputs need to remain available after completion

I am building Jungle Grid — https://junglegrid.dev — and this is the kind of execution layer it is designed for: agents or developer tools submit workloads, then track status, logs, lifecycle state, and artifacts asynchronously.

The request is not for OpenHands to depend on Jungle Grid specifically. The broader feature request is for OpenHands to support a pluggable durable execution backend, where Jungle Grid could be one possible implementation.

No files, tests, or entry points are identified; start by locating the SDK's runtime and task-execution abstractions. Define the scope of an optional provider interface around asynchronous submission, job IDs, status, logs, cancellation, and artifacts. Done should preserve the default runtime while allowing heavier jobs to be tracked after submission.