How Edge Agents Should Work with the Cloud: From Routing to Trajectory-Level Control

Introduction

Edge-cloud inference is often framed as a one-time routing decision: should a request stay on the device or be sent to a more capable cloud model? Long-horizon LLM agents make that framing incomplete. These systems plan, use tools, observe intermediate results, and revise their actions over many steps. Cloud involvement may therefore be interleaved throughout an execution trajectory. Each invocation can affect not only latency and cost, but also what information leaves the local environment and how later decisions are made.

What the study evaluates

The paper introduces EC2-Bench, a benchmark for studying this broader problem. It contains 128 executable tasks set in digital workspaces and evaluates three dimensions together:

• Task performance, including whether the agent completes its objective;
• Resource use, including local inference and cloud API expenditure;
• Privacy exposure, or the information revealed through cloud participation.

The benchmark compares edge-only and cloud-only execution with several collaborative arrangements. These include externally controlled routing, direct cloud execution, and designs in which the edge model decides when to seek cloud help or asks the cloud to provide advice rather than perform the task itself.

Main findings

The first finding is that collaboration can offer a useful middle ground. Cloud-only execution benefits from stronger model capabilities, but typically requires more remote computation and broader data transfer. Edge-only execution offers greater locality and lower dependence on remote services, while potentially sacrificing task quality. In the reported results, collaboration using a 9B edge model reached about 73% of full-cloud performance at roughly 15% of the cloud API cost. This result supports the idea that selective participation can be more practical than choosing either extreme.

The second finding concerns model strength. As edge models improve, collaborative execution moves closer to cloud-only performance and the performance gap between strategies becomes smaller. Privacy exposure, however, does not converge in the same way. It remains strongly shaped by the collaboration policy: a more capable local model does not automatically mean that less information is sent to the cloud.

The third finding is a shift in the preferred division of labor. Weaker edge models are more dependent on externally controlled cloud participation or direct cloud execution. With stronger edge models, the system can give the local agent more control over the trajectory and use the cloud as an advisor. In this arrangement, the cloud supplements local reasoning instead of becoming the primary executor.

Why it matters

The study reframes edge-cloud collaboration as a trajectory-level systems problem rather than a simple model router. For personal devices, enterprise workstations, and privacy-sensitive agents, deployment quality will depend on more than the size of the local model. An agent must decide when help is necessary, what minimum context should be shared, and whether execution can return to the local environment after receiving remote guidance.

EC2-Bench is useful because it places capability, cost, and privacy in one evaluation frame. A strategy that achieves a high completion rate may still be unsuitable if it requires frequent API calls or exposes excessive workspace context. The emerging design pattern is therefore not merely “run locally whenever possible,” but “let the edge retain state and control while using the cloud selectively.” More validation will be needed across task domains, device limits, and privacy requirements, but the benchmark offers a concrete basis for making those trade-offs measurable.

Source: Hugging Face Daily Papers