LobeHub 2.2.20: Device Model Relay and Reviewed Agent Batches

LobeHub released version 2.2.20 on October 18 with device-side model relay and a more structured way to run repeated agent tasks. The stable release packages both changes, but availability needs a qualification: the model relay is disabled by default in the released configuration.

For developers using LobeHub to coordinate agents, these features address two practical questions. Can a server-managed task reach a model available only on the user's machine? And when one procedure will be repeated across many files or services, where does someone review it before execution expands?

Stable desktop packages are available for macOS, Windows and Linux. The release does not announce a pricing change. Hosted subscriptions and credits remain separate from self-hosted infrastructure and provider costs. LobeHub's Community License also includes commercial-derivative restrictions, which matter for teams repackaging the product.

Device-side model calls need an enabled relay

The relay lets supported model requests travel from LobeHub's server to a connected client that can execute them. This is useful when the server cannot directly reach a model endpoint available to the user's browser or desktop app.

The shipped feature-flag configuration sets agent_llm_relay to false. Upgrading to 2.2.20 does not, by itself, establish that every account can use the feature. The deployment must enable it, and the connected client must support the requested provider.

Routing also depends on the provider configuration. Platform-owned providers stay on the server. For device-routed calls, the client must advertise both relay capability and the relevant provider. A missing executor produces an unavailable result rather than making a device-only model magically reachable from the cloud.

The one-shot relay implementation covers calls outside an agent run, such as generating a topic title or translating text. It needs the Agent Gateway and Redis infrastructure, plus a requesting client. Deployments without the relay infrastructure retain the previous server-side path.

This is execution placement, not a blanket privacy guarantee. The client returns the result to the server, and a provider reached from the device can itself be a hosted API. Teams handling sensitive material should map the complete request and response path before describing a workflow as local or offline.

Prepare a Goal before starting it

LobeHub's Goals organize work into tasks and dependencies. The release adds a draft-and-start workflow so a plan can be arranged before its tasks are dispatched.

The versioned CLI makes the scope concrete. Creating a Goal from a conversation with lh goal create --topic requests a draft. Tasks and dependencies can be prepared before lh goal start launches execution.

Standalone creation retains immediate-start behavior. The server also keeps draft creation opt-in for compatibility with older clients. It would therefore be misleading to read the release summary as a universal pause on every newly created Goal.

A draft is a preparation state, rather than a promise that only a human can start it. Supported start paths include the Goal's agent as well as an authorized owner. Teams that require a specific human approval should verify that requirement against their actual workflow.

Review the first larger batch

Batch rollout is intended for work that applies one procedure to many similar units, such as updating a repeated API call across several modules. Representative tasks run first, then the remaining work can proceed in waves.

The released review logic places a human decision at a particular transition: each round's first larger wave waits for the owner to review the probe results and plan.

Later waves can be released by the main Agent or escalated to the owner. If there is no main Agent available to decide, the owner is asked instead. This is not human approval of every wave, and a passed execution gate does not prove that the work is correct.

A useful trial would use a small, reversible migration with explicit acceptance criteria. Inspect the probe outputs, confirm who receives the first release decision, then check what happens when a later wave needs intervention. Those tests reveal more than the presence of an approval button.

The release gives LobeHub users more control over where model calls execute and how repeated work expands. Its value depends on configuring those boundaries deliberately: enabling the right client route, understanding which Goals start immediately, and reserving human review for the decisions that actually need it.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help developer-tool and enterprise AI teams explain agent architecture, product releases and adoption decisions in clear technical stories.

Book a 30-minute call.