Agent workloads increasingly need real compute: running models, processing data, driving pipelines. Lanes Compute provides GPUs your agents can use, sized to the task.
Lanes Compute is the GPU side of Lanes: a service in limited early access that rents A100, H100, and H200 SXM cards, plus L40S and other options for lighter jobs, from a single card to multi-node clusters, billed per second. The part that matters for agents is the interface: a CLI and API that drop into existing agents and tooling, so the pipeline that already files issues and calls models can also acquire hardware.
How Lanes Compute does it
- On-demand GPUs. From a single card to a cluster, spun up as work arrives. Environments start in seconds, so a pipeline step that needs a GPU is not parked in a queue behind someone else's training run. When the burst passes, the hardware goes away with it.
- Plug into your agents. Point agent pipelines at compute you control. The CLI and API drop into your existing agents and tooling, so integration takes minutes rather than weeks, and an agent can treat a GPU like any other resource it acquires, uses, and releases.
- Per-second billing. Pay for the work, not for idle capacity. The meter runs while an environment is live and stops at teardown, so a fleet that works in bursts pays in bursts. A quick job costs cents.
- Bring your own stack. Standard frameworks and your own containers. PyTorch, JAX, vLLM, and anything else that runs in a container works out of the box, so the code an agent triggers is the same code you run everywhere else.
Why it matters
Agents that need to train, infer, or crunch data get compute without you pre-provisioning a fleet that sits idle between jobs.
The problem grows with the fleet. One agent needing one GPU is a rental; twenty agents needing hardware at unpredictable moments is a capacity-planning problem, unless capacity is something the agents acquire themselves. With per-second billing, spend stays proportional to what the fleet did, not to what you guessed it might do.
There is also a bridge to the rest of Lanes. If you run coding agents from the Lanes Desktop board, some of their tasks want more than a laptop: an eval pass over a model change, a data crunch, a fine-tune. Compute is where that heavier work runs.
Set it up
Lanes Compute is in limited early access, so setup starts with a short conversation.
- Request access. Fill in the request access form on the Compute page.
- Describe the workload. What the agents run, how much data they touch, and whether jobs need one card or several. That is enough to get matched to hardware.
- Get onboarded. Access usually lands within a day or two.
- Wire in the agents. Point your pipeline at the CLI and API, spin environments up as work arrives, and tear them down when it is done. Billing stops at teardown.
Where this breaks without Lanes
Without on-demand capacity, an agent fleet gets one of two arrangements. It shares a fixed box, and every burst becomes a queue, or you reserve hardware for the peak, and the quiet hours become the bill. Agent demand is spiky by nature, so hardware that cannot follow the spikes is either a bottleneck or a write-off. The failure is quiet, too: agents do not complain about waiting, they just deliver later.
Further reading
- Batch processing and experiments: the same spin-up-and-tear-down loop, driven by people instead of agents.
- The Lanes overview: where Compute sits among the Lanes products.
- Request access: describe your agent workload and get running, usually within a day or two.