# October Update: Refer & Earn, and Billing You Can See Coming > September shipped Refer & Earn, which pays both workspaces 10,000 bonus runner minutes, plus overage notices for paid plans and alerts that are on before your runners stop. Source: https://latchkey.dev/blog/refer-and-earn-and-billing-you-can-see-coming Kaveh Alemi Published 2026-10-01 **TL;DR** Refer & Earn gives your workspace and the one you invite 10,000 bonus runner minutes each. Paid plans now hear about overage before and after it starts, the alerts that matter when CI stops are on by default, and how many runners you can run at once follows your plan. ## Shipped in September - **Refer & Earn.** Share a link; when the team you invited finishes setup, both workspaces get 10,000 bonus runner minutes for 30 days. - **Overage notices for paid plans.** The dashboard, email, Slack and push tell a subscribed workspace when it reaches 80% and 100% of its included minutes, with its rates and a running overage estimate. - **Alerts on by default when CI stops.** "Managed runner blocked" and "Free tier running out" now reach email and Slack without opting in. - **Runners at once that follow your plan.** Developer runs up to 20 runners at once, Launch 40 and Scale 80, and the number moves with your plan. - **A clearer minutes meter.** The Cost and Overview pages name your bonus minutes and when they end, and count minutes past your allowance as exactly that. - **Agent view on latchkey.dev.** Every marketing page has a Markdown version for agents, and a Human/Agent switch on the home page shows exactly what an agent receives. Last issue promised two things for September: clearer billing notices when a paid workspace goes past its included minutes, and a referral program. Both shipped, along with a few changes that make the account side of Latchkey say what it is doing before you have to ask. ![Latchkey Ledger No. 10: Refer & Earn, and billing you can see coming, September 2026](/blog/images/ledger-2026-10-cover.png) ## Refer & Earn Last issue I said we were building a referral program. It is live, and it pays in the thing you actually spend with us: runner minutes. ![Refer & Earn: share your link, your friend signs up and finishes setting up their workspace, both workspaces get 10,000 bonus runner minutes for 30 days](/blog/images/ledger-2026-10-refer.png) **How it works.** Open Refer & Earn from the dashboard sidebar and copy your link, or use Email a friend to send it with a short note. When someone signs up through your link and finishes setting up their workspace, both workspaces get 10,000 bonus runner minutes, valid for 30 days, on top of the plan. The reward lands when setup finishes, not at sign-up, because a workspace that never connects a repository has not really started. The modal keeps score for you: how many people signed up with your link, how many completed setup, and how many minutes you have earned. **Where the minutes show up.** Bonus minutes add to your included allowance everywhere it is counted: managed runners, `latchkey run` jobs, the usage page and the notices below. They are spent before anything is metered, so on a paid plan they push overage further away, and on a plan without a card they push the point where new jobs stop. **The rules.** One reward per new workspace and per person behind it, and setup has to finish within 30 days of signing up through the link. Bonus minutes expire at the end of their 30 days; minutes you already ran are never taken back. ## Overage notices for paid plans Every plan includes runner minutes: 2,000 a month on Developer, 4,000 on Launch, 6,000 on Scale. What happens when you run out depends on whether you have a subscription. Without one, new jobs that need a managed runner stop at the allowance, and the dashboard has always warned you at 80% and again at 100%. With a subscription, runners keep running past the allowance and the extra minutes are billed at the per-minute rate for each runner size. That is the behaviour you want from CI, since a busy week should not block a release. But until September, a paying workspace that crossed its allowance heard nothing from us, and the first sign of overage was the invoice. ![The dashboard banner for a paid workspace at 80% and at 100% of included minutes, quoting per-minute rates for the sizes the workspace ran and the estimated overage so far](/blog/images/ledger-2026-10-overage.png) **In the dashboard.** At 80% of your included minutes, a paid workspace now sees a banner that says what happens next: runners keep running, and further minutes meter at the rates it lists. At 100% it says the allowance is used and metering has started. The rates it quotes are only for the runner sizes you actually ran this month, so a team that only uses `latchkey-small` and `latchkey-medium` sees those two rates and nothing else. Once there is overage to report, it adds the estimated overage so far this calendar month and the exact time that estimate was read, so you can hold it up against your invoice. The banner links to your usage rather than asking for a payment method you already added. **In email, Slack and browser push.** The "Free tier running out" notice now has a paid version that carries the same message: whether you crossed 80% or 100%, the rates for your sizes, and the running estimate. A paid workspace gets each level at most once per calendar month, so it is a heads-up, not a drip. What it deliberately does not do: it does not stop your runners, cap your spend or promise which invoice a given minute lands on. The estimate covers metered minutes as of a moment in time; your invoice is the record. ## Alerts on by default when CI stops Most Latchkey notifications start off, because an alert you did not ask for is noise. Two of them were the wrong way round: the ones that tell you CI has stopped, or is about to. ![Notification defaults: Managed runner blocked and Free tier running out now on for email and Slack; trial notices unchanged; other events off by default](/blog/images/ledger-2026-10-alerts.png) Nobody opts in to a notice about compute they do not yet know has stopped. So for every member who has not changed their preferences, "Managed runner blocked" and "Free tier running out" are now on for email and Slack by default. Two kinds of runner block stay off by default: a job on a repository you have not enabled, and a job after an expired trial. Both follow from a choice you made, and the trial already has its own emails. Every default is just a default: Settings, Notifications shows the full matrix, and an explicit choice always wins. The emails and Slack messages now say where that setting lives. ## Runners at once that follow your plan How many runners a workspace can keep busy at the same time is now set by its plan: up to 20 on Developer, 40 on Launch and 80 on Scale, with Enterprise limits set by contract. Every trial starts on Launch, so a new workspace has 40 from its first job. The number moves with the plan. Upgrade to Scale and the next burst can use 80 runners; move to Developer and it is 20. Only busy runners count, so runners waiting warm for your next job never use up a slot. When a burst needs more runners than your plan allows at once, the overflow jobs wait in the queue and start on their own as soon as a slot frees. Nothing errors and nothing is lost; the busiest moments just take a little longer. If your pipelines regularly queue for that reason, the next plan up is the fix. ## A clearer minutes meter Two numbers on the Cost and Overview pages now say more precisely what they mean. If your workspace has bonus minutes, from Refer & Earn or otherwise, the Cost page names them under your free-tier meter with their end date, for example "Includes 10,000 bonus minutes through October 24". You can always see how much of your allowance is borrowed and when it goes back to the plan's number. Past your allowance, the minutes-used figures on the Cost and Overview pages and in billing show the whole period's total under "Minutes used this period", with a second line counting how many of those minutes are past your allowance. Under the allowance, nothing changes. ## Agent view on latchkey.dev Some of the readers evaluating Latchkey are not people. A coding agent asked to "speed up our CI" will read our pages, compare plans and write the `runs-on` line itself. It does not see the layout; it reads text, and on most sites that text is whatever survives stripping the page. So our marketing pages now publish a Markdown version alongside the page, advertised in the page head, with the links intact and the cookie banner and decoration gone. The home page's version also carries a technical reference drawn from our documentation, because that is what an agent needs to act: runner sizes and prices, how to run a first job, how to connect over MCP. You can see it for yourself. A Human/Agent switch sits at the bottom of the home page's first screen; flip it to Agent and the page is replaced by the exact Markdown an agent receives. It is the same file, not a second copy written for show, so what you read is what your agent reads. ## Platform vision: a platform that explains itself If agents are going to drive CI, the platform has to explain itself in plain words, including about money. A human who hits a surprise invoice writes to support. An agent that hits a blocked runner just sees a job that never started and, left to itself, will retry or give up. Both come from the same gap: the platform knew something and did not say it. That is why September's billing work is about notices rather than prices, why the alerts that matter now default to on, and why our pages publish the version an agent actually reads. Where this goes next is the work below: when Latchkey runs a whole pipeline, a job that does not run should say why in a sentence and offer one thing to do about it, for you and for your agent alike. ## Coming next Most of September's engineering went into the direction I flagged last issue: running whole pipelines on Latchkey, not just single commands. We are calling it Latchkey CI. It is not ready to try, but the shape is clear enough to describe as intent: - **A workflow file in your repository.** You commit a Latchkey workflow file, and a push runs the pipeline it declares, at that exact commit, on Latchkey runners. Anything it does not support is refused by name rather than silently ignored. - **Results where you already look.** Runs report back to your pull request as checks, and the dashboard gets a runs list and a run page with each job and its logs. - **Reasons, not silence.** When a job does not run, whether because of your plan, your usage or a refused workflow, it says why in plain words, with the one action that clears it. - **Two ways to start.** A new workspace will be able to begin by connecting a repository or by running a job straight from the CLI. Closer in, the CLI is getting a cache for dependency downloads, so a fresh machine does not start from nothing on every run. GitHub Actions keeps working exactly as it does today. Latchkey CI is another way in, not a migration. If you have a pipeline you would want to run on it, tell us what it needs through the [Support page](/support). Previous issue: [September Update: Meet the Latchkey CLI](/blog/latchkey-cli) --- 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