January Update: Backed by LAUNCH, and Rethinking CI for Agents

This is the first monthly Latchkey update, and because it is the first, it covers the whole of 2025: the news that LAUNCH has invested in Latchkey, how the product went from a pipeline generator to analytics that ends in a pull request, and everything that shipped along the way. It closes with where we are taking the platform in 2026, which is CI that acts on what it finds instead of only reporting it, and what is coming this month.

LAUNCH is backing Latchkey

On December 19 we announced that Latchkey had accepted an investment from LAUNCH. The announcement and a funding banner on the landing page went live that day. LAUNCH was not new to us: in the autumn our landing page carried a Founder University Cohort 11 badge, from LAUNCH's program for early-stage founders.

We are not sharing the terms. The money pays for engineering time: an open beta where anyone can install the GitHub App and get value in the first hour, and room for a bigger swing at the problem, which is the platform vision later in this update.

Platform core: from a pipeline generator to CI analytics

Latchkey did not start as an analytics product. The first version was a CI/CD pipeline generator. You pointed it at a repository, it detected the project type, and it generated a GitHub Actions pipeline for you. The pitch in our own product document was "Zero to Pipeline in 60 seconds" and "No YAML Required". By late July it handled Node projects, Docker projects and Expo (React Native) apps, managed secrets in the target repository, had billing wired in, and even shipped a small self-hosted runner so generated pipelines could run on your own machine.

The trouble was that every framework we added came with a long tail of version combinations, and every combination was a pipeline we had generated and therefore owned. We were writing other people's build systems one template at a time. Worse, the value ended at generation. Once the YAML existed, the interesting questions (why is this slow, why does this fail, what does this cost) were exactly the ones the generator could not answer.

On July 31 we stopped and deleted most of the product. The new target, in our planning note from that day, was "Datadog for CI/CD": observability and cost for the pipelines people already had, instead of pipelines we wrote for them. It is a little funny in hindsight that one of the things we deleted was a runner.

August was the analytics product, and most of it was learning how GitHub Actions really bills. Public repositories run on standard runners for free. Private repositories draw on an included monthly allowance, and minutes are weighted by operating system: a Windows minute counts double, a macOS minute ten times. So "how much did this run cost" has two answers, list price and actual billable cost, and we show both. The budget view switches automatically between "you are spending free minutes" and "you are spending dollars", because the advice is different in each case.

Platform core: from a recommendation to a pull request

By September the dashboard could tell you a workflow was expensive or slow. The obvious next question was "so what do I change?", and that is where the AI came in. AI recommendations read your workflow files alongside their real cost, duration and reliability history, and propose specific changes: this line, this replacement, this estimated saving, this risk. Each one is a small, line-level edit rather than a rewritten file, because a rewritten file is impossible to review. We also taught it to stay quiet about trivia. A recommendation that saves two seconds a month is noise, and noise teaches people to stop reading.

October was about making recommendations something you could act on, and this is the part of 2025 I am proudest of.

1. Latchkey analyzes a repository on a schedule, and again when something notable happens: a workflow file changes, costs jump, or runs start failing.
2. It recommends specific edits to your workflow files, with the evidence and the estimated impact.
3. You tick the recommendations you want and click Review changes. They merge into one updated file, shown as a single diff with the combined estimated savings.
4. Apply changes uses the GitHub App to create a branch, commit the new workflow file and open a pull request.
5. You review and merge it like any other change, or close it.

Nothing lands on your default branch without your merge. That rule came from the design of Apply changes, and it turned out to be the most important decision of the year, for reasons the vision below explains.

November made it a business: billing, a free trial that starts when you install the GitHub App so nobody hits a paywall before seeing their own data, and a month-end spend forecast. December was the busiest month of the year, and most of it is built but not yet serving customers. It goes live this month.

Why the runner layer started to look interesting

One piece of outside news in December changed how we think about where Latchkey should sit.

On December 15 and 16 GitHub announced changes to Actions pricing for 2026: GitHub-hosted runner prices cut by up to 39% from January 1, and a new $0.002 per minute "Actions cloud platform charge" on self-hosted runner usage from March 1 (changelog). The reaction was loud, and on December 17 GitHub postponed the self-hosted charge to re-evaluate it, while keeping the hosted price cut.

Two things stood out. The runner is where the bill is actually decided, and everything we built in 2025 analyzes that bill after the fact, from outside the machine. And GitHub is signalling that the runner and the platform around it are separate things that can be priced separately. If the runner is a line item that can move, then who operates it, what hardware it has and what it does when a job fails are open questions. In July we deleted a runner because it was attached to the wrong product. We have started asking whether it belongs to this one. That is a question, not an announcement.

Platform vision: CI has to act, not only report

Latchkey got good at telling you what was wrong with your CI in 2025, with numbers attached. Every one of those findings still ended in the same place: a person reading it, deciding, and doing something. Apply changes shortened that to one click and a PR review, but a human was still the actuator.

That was acceptable when humans wrote nearly all the code, because the person reading the dashboard was the person who broke the build. It is less acceptable now. A growing share of code, ours included, is written by coding agents. An agent can produce a change in minutes and open a dozen PRs a day. Something has to check all of that, and the thing that checks it is CI. CI stops being a convenience that runs your tests and becomes the verification gate between an agent's output and your main branch.

A verification gate that only reports has two failure modes. It goes red for reasons unrelated to the change (a tool missing from the runner image, a registry timing out, a disk filling up), and someone has to stop, diagnose and push again. Or it stays red on a real failure and the report waits for a person to read it.

So our bet for 2026 is CI that acts. That is a dangerous sentence if it is not bounded, so we are writing the rules down now, before we build anything.

Three rules for a CI that acts

1. Repair the environment, never your code. If a job fails because the machine was missing something or the network had a bad minute, CI may fix the machine and try again. It may not edit your source, your tests or your assertions to get a green check.
2. A real failure stays red. A test that catches a bug is doing its job. The system can diagnose it, explain it and hand it to whoever should fix it, but it can never mask it, skip it or quietly retry until it passes.
3. Permanent changes arrive as PRs you merge. Anything that should outlive a single run, such as a workflow edit, a cache setting or a dependency pin, arrives as a pull request with a diff you review. That is already how Apply changes works, and it stays the rule.

The first piece of this is already built. In December we finished a new AI engine that, for the first time, can look at one specific failed run and explain its root cause: the failing job and step, the error, and whether it keeps happening. What it cannot do yet is anything about it. Closing that gap, inside those three rules, is the work of this year.

Coming next

This month is about getting what we built in December in front of people, and making the product something a whole team can use.

• Failed-run diagnosis goes live. A red run should come with an explanation you can read in a minute, instead of a log you scroll through. This is the first step from reporting toward acting, and the part of the product we most want feedback on.
• The new dashboard becomes the default. We rebuilt the overview, cost, performance and insights views over the winter. It replaces the old one once it matches it on every number, because a dashboard you cannot trust is worse than none.
• Teams. The open beta allows one admin per GitHub organization. We plan to let you invite your team, without per-seat pricing, so the people who fix CI can see the same data as the person who installed the app.
• Clearer docs and pricing. The documentation and the pricing page are being reworked so a new user can get from install to their first insight without asking us anything.

The next issue will report what actually shipped and go further into why agentic development changes what CI is for.

Next issue: February Update: CI/CD in the Agentic Era