partcl.com
How Partcl cut GitHub Actions costs by 13× and reduced queue time by 16× with StarSling.
Partcl's heaviest CI jobs are 13× cheaper per run than on their old self-hosted setup, their slowest shard dropped from 59-89 min to 5-7 min, and queue time fell 16×. StarSling's agents achieved these wins while Partcl's CI volume grew 6×.
“Within a day of migrating to StarSling Runners, their agents opened up a PR that literally made our Rust CI tests 2x faster!”
- 6×
- More CI jobs per day
~640 → ~3,900 jobs/day
Seed·$5M raised·San Francisco
Intro
GPU-native chip design and a CI pipeline that gets busier every week
Partcl is bringing chip design into the AI era by building GPU-native chip design systems that compress weeks of iteration into seconds. Backed by Khosla Ventures and co-founded by Vamshi Balanaga (CTO), the small San Francisco team is scaling fast: since turning on StarSling on April 2, 2026, CI job volume has grown about 6×, from roughly 640 to nearly 3,900 jobs a day. Their CI runs heavy, long-running compute, so a pipeline that gets busier every week is exactly where compute cost piles up.
“We're a chip company, not a DevOps team. We'd been throwing the most powerful machines we could get at our CI and we didn't have time to sit there and optimize it. When it comes down to priorities, our product always comes first so CI just didn't make the cut.”
Problem
The heaviest jobs were slow to get picked up and expensive
Their heaviest CI jobs don't shrink from a runner swap, the work is the work, and Vamshi wasn't sure if StarSling would move the needle. The first thing StarSling agents attacked was cost: Partcl was running 64-core machines on jobs that didn't need them, hadn't parallelized all its tests, and wasn't caching build artifacts between shards. At a seed-stage startup, every dollar of compute counts, and with volume climbing week over week, that overspend was only going to compound. The second focus of StarSling agents was the wait. On a busy day the CI matrix fanned dozens of jobs out at once against a handful of self-hosted runners. An idle runner picked up instantly, but once the full matrix saturated their fixed fleet the wait blew out, the worst jobs waiting up to 18 minutes for a free machine before a single test could start.
“We build chip design and simulation software that's far faster than traditional methods. StarSling is the same idea pointed at CI.”
Solution
CI that right-sizes its own runners
Partcl turned on self-driving CI in April and over the first five weeks StarSling agents opened eight PRs autonomously: build dependency caching, parallelization of tests, build-artifact caching across the build shards, and right-sizings that moved the heaviest CI jobs off 64-core boxes onto 8-core ones. Each change the StarSling agents made was benchmarked and validated before the PRs were even opened. The test parallelization alone was a large project the team never had time for. The agents scoped it, proved it held, and shipped it on their own.
“The agents went through every workflow we had and did the annoying but valuable work we'd never gotten to: caching builds across shards, parallelizing our tests, right-sizing each job to the machine it actually needed. All on their own. I just reviewed the PRs and merged.”
Results
13× cheaper per run, and the queue time fell 16×
The cost curve bent hard. On their heaviest CI jobs, a full run now costs 13× less than it did on their old self-hosted runners on like-for-like productive compute, and the slowest shard dropped from 59-89 minutes down to 5-7 minutes, about 94× cheaper per shard. Reliability came with it: where roughly one in four self-hosted jobs used to be cancelled and billed anyway, none of StarSling's 500+ sampled jobs were. The wait changed shape too. StarSling runs the CI matrix at far higher concurrency, roughly 35 jobs at once where their self-hosted fleet only allowed 6, so the backlog evaporated: the p95 wait for a runner fell from 9.5 minutes to 35 seconds, about 16× shorter, and the worst case from 18 minutes to about 1 minute. The agents and the runners gave a small team a cost and queue profile it never found the time to build itself.
“Most CI vendors just bill you for faster machines. StarSling's agents actively find ways to cut what each minute costs you, and those savings compound as your volume grows, while you stay focused on your product.”
Compute cost
Where the cost went
Partcl's CI is dominated by heavy, long-running compute, where cost climbs fast, so that's what the agents went after. Cost compares their pre-StarSling self-hosted runners against StarSling as multipliers from GitHub Actions job timings, not absolute spend.
On their heaviest CI jobs, vs their pre-StarSling self-hosted runners, on like-for-like productive compute: 6.75× lower price per minute on about 1.95× fewer billed minutes.
Before · self-hosted
After · StarSling13× cheaper
Relative cost per run
- Slowest shard
- 94×cheaper · 59-89 min → 5-7 min
- Cancelled jobs, billed anyway
- 23%→0%
Methodology
1Cost per run on Partcl's heaviest CI jobs (their most compute-intensive, longest-running jobs, where cost concentrates): GitHub Actions job times priced at each runner's per-minute rate, compared as multipliers. Like-for-like productive compute (jobs that produced a result) fell about 13× per run: 6.75× cheaper per minute on about 1.95× fewer billed minutes (64-core to 8-core).
2Queue: each job's p95 wait for a runner (job.started_at minus the push), success jobs only. It fell from 9.5 minutes, when the fixed self-hosted fleet saturated under the full matrix, to 35 seconds, about 16× shorter.