# Latchkey vs StarSling for AI on GitHub Actions

> Latchkey vs StarSling: both put AI on your CI, at opposite ends of the failure. One fixes the running job, the other opens a pull request.

Source: https://latchkey.dev/learn/runners/latchkey-vs-starsling  
Updated: 2026-09-22

Latchkey and StarSling both put AI agents on GitHub Actions CI, at opposite ends of the failure. StarSling analyses finished runs and opens pull requests a human reviews and merges; Latchkey fixes the failing step on the runner while the job is still executing. The pricing difference, $0.0025 a minute against $0.004 at 2 vCPU, is the less important half of the comparison.

StarSling sells AI-native GitHub Actions runners at $0.004 a minute for 2 vCPU and $0.008 at 4 vCPU, with 2,000 free minutes in the first month and queue time it publishes as never billed. Its agents read your workflows and open pull requests that restructure them: sharding tests, fixing cache configuration, reordering jobs. Those land as changes a developer reviews and merges.

Latchkey sells managed runners at $0.0025 a minute for 2 vCPU and 8 GB, with an agent that runs on the machine during the job. When a step fails for a transient reason it diagnoses the failure, applies a fix and retries the step, so the run finishes green without anyone being interrupted. It does not currently open unprompted pipeline-restructuring pull requests.

The StarSling cells were read from starsling.dev on 18 August 2026, the Latchkey cells on 20 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.

## Comparison

|  | StarSling | Latchkey |
| --- | --- | --- |
| Where the AI acts | After the run, as a pull request to review | On the runner, during the job |
| Human needed to recover a failed build | Yes, someone reviews and merges the pull request | No, the step is diagnosed and retried automatically |
| Price per minute, 2 vCPU Linux x64 | $0.004 | **$0.0025** (2 vCPU, 8 GB RAM, 100 GB disk) |
| Price per minute, 4 vCPU Linux x64 | $0.008 | **$0.005** (4 vCPU, 16 GB RAM, 100 GB disk) |
| Opens pipeline-restructuring pull requests | Yes: test sharding, cache fixes, job ordering | Not as an unprompted pull request today |
| Queue time billed | Published as never billed | Not published |
| Free tier | 2,000 minutes in the first month | 30-day trial, then 2,000 included minutes a month on Developer, 4,000 on Launch, 6,000 on Scale |
| Billing granularity | Not published | Per minute |
| Runner sizes and OS | Not published beyond the 2 and 4 vCPU rates | 2, 4, 8 and 16 vCPU, Ubuntu 24.04 on x86_64 only. arm64, Windows and macOS are not offered |
| Cache: type, limit, persistence | Not published | Size not published. `latchkey-dev/cache-action@v1` swaps one line for `actions/cache`, keeping `path`, `key` and `restore-keys`; entries are isolated per organization, versioned by OS, kept 14 days; a failed restore warns rather than failing the job |
| Cost and performance analytics | Not published | Built in |
| Self-healing or retries | Not on the runner; fixes arrive as pull requests | Built in: transient failures are diagnosed and retried inside the run |
| Setup change required | Not published | A `runs-on` label change. GitHub organization accounts only |

## The difference is timing, not capability

Both products will tell you they use AI to make your CI better, and both are telling the truth about different moments. StarSling looks at runs that have finished and proposes structural changes to the pipeline: shard this test suite, fix this cache key, reorder these jobs so the slow one starts first. Those are real improvements to the shape of the pipeline, and they arrive as pull requests somebody reads.

Latchkey looks at the step that is failing right now, on the machine it is failing on, and tries to make it pass. A registry timeout gets retried with backoff, an OOM kill gets more headroom, a missing tool gets installed. The run finishes green and the report says what was done.

So the question is not which AI is better. It is whether the thing hurting you is a pipeline that is shaped badly, or builds that go red for reasons nobody wants to read about. Those have different answers and you may well have both problems.

## What StarSling publishes, and what it does not

StarSling publishes its per-minute rates and the fact that queue time is never billed, which is a genuinely good commitment and one Latchkey does not make in public. Beyond that its public pages are thin on the specifics this cluster normally compares: runner sizes and operating systems, cache type and limits, concurrency, and where jobs physically run are not published at the time of reading.

That is why half the rows in the table say "not published" rather than carrying a number. It is not a criticism of the product, it is a limit on what an honest comparison can assert, and the cells stay empty rather than getting filled with an inference from a neighbouring vendor.

## Speed

Not benchmarked yet; the runner benchmark report will replace this section. We have not run the same workload on these runners ourselves, and until we have, there is no number here worth quoting.

The cheap way to get a real answer is to point one slow job at each candidate for a week, because runner selection is per job and the Actions run log gives you the timings for free.

## Cost: one worked month

Ten thousand Linux minutes a month at 2 vCPU is $40 on StarSling and $25 on Latchkey, a 37.5% difference at the published rates. StarSling's 2,000 free minutes apply in the first month only, so they change the first invoice and not the steady state.

Latchkey's own plan is $5 to $49 a month on top of that compute, and its 2,000 to 6,000 included minutes are not netted off, so the figure is gross on both counts.

If StarSling genuinely never bills queue time and your jobs spend real time queued, the effective gap narrows by whatever that queue time is worth. Latchkey does not publish a position on billing queue time, so this page cannot tell you what that comparison comes to.

## Reliability

Neither vendor publishes an uptime SLA or a concurrency limit on its public pages, so there is nothing to compare on either axis.

On failure handling the two are not on the same axis at all. A build that fails under StarSling has failed: someone re-runs it, and separately an agent may later propose a change that stops it happening again. A build that fails under Latchkey for a transient reason is repaired in place and finishes green, and nothing reaches your team. The first is a slower loop with a structural payoff; the second is an immediate recovery with no structural change.

## When to choose StarSling

Choose StarSling if your pipeline is structurally slow rather than flaky, and you have the review capacity to take agent-authored pull requests seriously. Test sharding and cache configuration are exactly the kind of work that never reaches the top of a backlog, and an agent that opens those as reviewable changes is doing something Latchkey does not do today. Its published position on queue time is also worth having if your jobs queue.

## When to choose Latchkey

Choose Latchkey if the pain is red builds rather than slow ones, and if the thing you want back is the interruption rather than a few minutes of wall clock. The agent runs during the job, so the failure never becomes somebody's problem to triage. On the two sizes both vendors publish, it is also the cheaper machine.

## Switching

Switching is a label change on the jobs you choose, not a migration. Leave the rest of the workflow alone, move one slow job first, and read the timings out of the run log before you move the others.

```Adopting Latchkey from GitHub-hosted runners
jobs:
  build:
-   runs-on: ubuntu-latest
+   runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v4
```

## The verdict

These are complements sold as competitors, and the awkward part is that they compete for the same `runs-on` line, so in practice you pick one. If your builds are red too often, put the AI on the runner and get the failure fixed before anyone sees it. If your builds are green but slow and nobody has time to restructure the pipeline, an agent that opens those pull requests is solving a problem Latchkey does not solve. On price, at the two sizes both publish, Latchkey is 37.5% cheaper.

## FAQ

### What is the difference between Latchkey self-healing and StarSling AI agents?

Timing, and who acts. The Latchkey agent runs on the runner while the job is executing: it diagnoses the failing step, applies a fix and retries, so the run finishes green with no human involved. StarSling agents analyse completed runs and open pull requests that a developer reviews and merges. One recovers the build in front of you, the other proposes a change for next time.

### Which is cheaper, Latchkey or StarSling?

Latchkey, on the sizes both vendors publish: $0.0025 a minute at 2 vCPU against $0.004, and $0.005 at 4 vCPU against $0.008. Both are list prices read from the vendors' own pricing pages, StarSling on 18 August 2026 and Latchkey on 20 September 2026.

### Does Latchkey open pull requests too?

It opens fix pull requests for failures it cannot repair on the runner, and it surfaces cost and reliability findings with the concrete change to apply. It does not currently open unprompted pipeline-restructuring pull requests the way StarSling does.

### Can I run both StarSling and Latchkey?

Technically yes, but they compete for the same `runs-on` line, so in practice you pick one runner provider per job. You could split by job, sending the flaky ones to one and the slow ones to the other, but that is a lot of complexity for a benefit you should measure first.

## References

- [StarSling](https://starsling.dev/)
- [Latchkey pricing](https://latchkey.dev/pricing)
- [GitHub: re-running workflows and jobs](https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt