Computer use is a loop. A dead GPU is the next step, not a replay.

A computer-use agent takes a screenshot, decides, acts, and does it again. Each step is a request. The prefix is the instructions plus the history. Losing that cache, or losing the GPU under the step, is the outage the user feels.

We have not published a latency, a tokens-per-second figure, or a cost for a computer-use loop. The public H100 numbers are Qwen3.8-27B answering text prompts. They are written up in the benchmark and the 213 tok/s note. They are not this workload. The code prompt in the 23-way test (360 tok/s on that H100, versus 211 on chat) is the closest published split, and it is still one prompt, not a loop of actions.

What the design is careful about

Stickiness. The next step should hit the replica that already holds the prefix, inside one site. llm-d does that. Crossing clouds on every step recomputes the prefix. The cluster note is the longer version.

No silent retry. Once tokens have streamed, replaying the request on another GPU can produce a different action. The caller gets an error. The next step can go to a healthy replica. That is failover. It is not “finish the click somewhere else and hope.”

The node itself is repair: health checks, a disruption budget so you do not drain every replica, then reset, reboot, driver reinstall, or replace a machine the provider will launch. Your own servers get a ticket instead of a new machine. denv cannot buy hardware you did not give it an API for.

GPU availability is the other half. One provider being out of cards is why the cluster has more than one site. You pay each provider. denv does not resell the GPU. See providers.

There is no computer-use recipe on the site, and the MCP server for driving denv from an agent is still marked coming soon. Write to anup@denv.ai. The product is early.