# Dynamic Routing (/runners/dynamic-routing)
StarSling runs its GitHub Actions runners and agentic compute on multiple high-performance sandbox providers. StarSling Runner labels automatically select the highest-performance environment for the workload you run. You pick a [label](https://docs.starsling.dev/runners/instance-types) for the size of the job. Dynamic routing selects the environment behind it.
## Distributed & Resilient Compute
Most CI providers buy hardware and lock you into a specific hardware shape. StarSling does the opposite. Our agents distribute your CI jobs across high-performance sandbox providers in multiple regions and failover at the job level in under 1 second.
A regional power or cooling failure at a single-operator datacenter can take down every runner hosted there. StarSling routes around that failure: when a provider cannot start a sandbox, the job falls back to another provider. The result is higher resilience and availability than a CI platform that depends on a limited number of datacenters.
Failover is automatic. If a provider rejects a job or has an outage, the job goes to the next healthy provider.
## Telemetry Drives Routing
The same granular telemetry StarSling's AI agents use to open [optimization PRs](https://docs.starsling.dev/ai-agents/optimizations) also determines the fastest environment for each job. Routing keeps a preferred provider for each workflow, and provider weights for the organization. Both update from jobs that have already run, and both place the next job.
## High-Performance Wall-Clock Time
The wall-clock time of a CI job is queue time plus the job's own execution time. Dynamic routing optimizes that total.
The examples below are illustrative. The timings are hypothetical, and they do not describe a specific customer or a measured result.
### Queue time between phases
A workflow with several dependent jobs, chained with `needs:`, waits in queue again at every handoff.
```yaml
jobs:
install:
runs-on: starsling-ubuntu-24.04
test:
needs: install
runs-on: starsling-ubuntu-24.04
package:
needs: test
runs-on: starsling-ubuntu-24.04
```
In a hypothetical three-job chain, each job runs for 60 seconds, and each `needs:` handoff waits 45 seconds in queue. Those two handoffs add 90 seconds of queue time to 3 minutes of execution, so a third of the wall clock is waiting between phases. For an organization whose workflows look like this, dynamic routing shifts that organization's provider weights toward a provider with a faster time-to-start.
### Disk-bound jobs on the same CPU
Two sandbox providers can run the same bare-metal CPU and still finish a disk-bound CI job at different speeds. The job is limited by disk I/O — installing dependencies, writing a large build output, or running tests that create thousands of files — so it is not waiting on the CPU. Suppose the same job takes 3 minutes on one provider and 5 minutes on the other. Dynamic routing places it on the faster provider. For disk-bound workloads, StarSling Runners may also provision sandboxes with extreme disk performance, such as tmpfs (RAM-backed) workspaces.
## Zero Configuration
StarSling believes agent-native CI should be automatic and feel like magic. Dynamic routing is zero-configuration. It is enabled by default on StarSling Runner labels, and it needs no YAML change. Keep the `runs-on` label you already use:
```yaml
runs-on: starsling-ubuntu-24.04
```
## Need exotic hardware for your CI?
If a workload needs hardware performance the existing StarSling Runner labels do not provide, contact [founders@starsling.dev](mailto:founders@starsling.dev).
StarSling's dynamic routing architecture enables us to source specialized hardware. The industry-leading [GPU Runners](https://docs.starsling.dev/runners/compute-sizing#gpu-specifications) started exactly this way.
## FAQ
### Do I have to change my workflows?
No. Dynamic routing needs no configuration. The only change is the `runs-on` label that moves a job onto StarSling Runners. If your jobs already use a StarSling Runner label, there is nothing to change.
### Can I pin a provider or region?
Yes. If a workload needs a specific provider or region, contact [founders@starsling.dev](mailto:founders@starsling.dev).
### What happens during a provider outage?
Jobs waiting to start go to a healthy provider first. A provider that rejects jobs or has no capacity is skipped, and a degraded provider is tried only after the healthy ones, as described in [Distributed Compute](#distributed-compute). No workflow change is needed.