BusDK Update

bus-agent-runtime: self-hosted coding agents on your own GPUs

bus-agent-runtime now has early support for running open-source Codex agents against GPU infrastructure you control. The goal is a self-hostable AI platform where coding work can keep moving without handing every agent turn to a hosted model endpoint.

The first exercised path is intentionally narrow: GPU virtual servers, offload infrastructure for UpCloud GPU capacity billed by the hour, and Gemma 4 as the model used so far. Other hardware and models are plausible, but they should be treated as configuration work until they have the same proof trail.

June 9, 2026bus-agent-runtimeGPU workersself-hostable AI

TL;DR

TL;DR

  • Open-source coding agents can start running against self-hosted GPU-backed infrastructure instead of only remote hosted model APIs.
  • The runtime loop keeps practical agent controls in scope, including autonomous turns, cancellation/resume, and debug log bundles for post-run inspection.
  • This is early support: the UpCloud GPU and Gemma 4 path is the known starting point, while broader hardware and model support still needs configuration and proof.

The useful shift is operational control. A worker can be launched onto GPU-backed infrastructure, run an autonomous coding loop, and still remain inspectable when something stalls or fails. Cancellation and resume are part of the runtime story, so an operator can stop a bad turn without discarding the whole task context.

The GPU work is also tied to offload infrastructure, not just a local experiment. The current path targets UpCloud GPU virtual servers and keeps hourly capacity in mind, so teams can start with bursty agent work instead of committing every workload to always-on hardware. That makes the feature a better fit for the rest of BusDK's self-hostable AI platform.

There are still sharp edges. Gemma 4 is the model that has been used so far, and H100-class proof work does not automatically mean every accelerator, image, driver stack, or model template is ready. Treat the current surface as experimental when you move away from the exercised path, and keep debug bundles attached to runs that matter.

Next stop: the BusDK documentation at docs.busdk.com for supported provider paths, model setup, and operator workflow.