StarSling raises $3M and puts code-review agents inside GitHub Actions

StarSling announced a $3 million pre-seed from Bessemer Venture Partners and Y Combinator, plus five more funds, and launched Review Runners in private beta — GitHub Actions jobs that run a team’s own model and repository review skills on every pull request before a person opens it.

SOFTWARE desk — the review gate is becoming agent-native the same way coding agents already are. Paying for runner minutes while you keep your own model is a different business than another per-seat bot.

Why the company says it is doing this now. The post says StarSling Runners launched this past April. On a post dated 22 Sep 2026, that April is 2026. The bottleneck, the post says, had moved from writing code to checking it. Before code reaches production it has to pass two gates: continuous integration, shortened to CI, and code review. CI is the automated checks that run on a proposed change. A pull request, often shortened to PR, is that proposed change. StarSling says it is expanding so both gates are agent-native. An agent, here, is software that takes steps, not only a chat reply. Agent-native means those steps sit inside the gate. These lines are the company’s.

The first gate, as the post describes the product that already exists. StarSling Runners are a drop-in replacement for GitHub Actions’ default ubuntu-latest runners. GitHub Actions is the system that runs jobs when code changes. A runner is the machine that runs the job. ubuntu-latest is GitHub’s default name for that machine. Jobs run on current-generation AMD EPYC hardware, roughly 30 percent faster than GitHub’s, and switching is a label swap. EPYC is AMD’s line of server chips. The Review Runners product page calls the same CI runners 5th Gen AMD EPYC. That generation is the product page’s. Roughly 30 percent is the blog’s. Thirty percent faster means a job that took ten minutes would finish in a bit under eight, if the claim holds. This desk did not time one. The post says most CI services are static, and that StarSling’s is self-improving. Agents read workflows, run logs, and machine telemetry, then open pull requests that repair caching, speed up dependency installs, parallelize build steps, and shard test suites. Caching is saving work so the next run can reuse it. Sharding is splitting a test suite across machines. Every agent-authored change ships as a pull request the team reviews and merges. Cost, the post says, is cut three ways: a lower per-minute rate than GitHub, faster machines that finish in fewer minutes, and agents that remove minutes. Those are the company’s claims.

What the post says customers measured, and whose numbers they are. The chart on the page: Mastra’s test suite falls from 29 minutes 56 seconds to 5 minutes 6 seconds, six times faster. Six times means the suite takes about one sixth as long. Better Auth’s end-to-end suite falls from 2 minutes 22 seconds to 1 minute 4 seconds, twice as fast. Partcl’s queue time falls from 9 minutes 30 seconds to 35 seconds, sixteen times shorter. Queue time is how long a job waits before a machine starts it. A separate sentence says Partcl’s Rust tests got twice as fast within a day of migrating, off a pull request the agents opened. Twice as fast on those tests is not the same figure as sixteen times shorter on the queue. Across the platform the post says it has run over 2 million CI jobs, made CI up to 6 times faster and up to 13 times cheaper, and saved customers like Mastra and the Better Auth team at Vercel over 28,000 hours of compute. Over 28,000 hours is more than three years of one machine running day and night. Up to is a ceiling. The six-times bar matches Mastra. The post does not print the two prices behind “13 times cheaper.” Do not invent them. These figures are StarSling’s. This desk did not rerun the suites. Abhi Aiyer, co-founder and chief technology officer at Mastra, said the team moves so fast that the bottleneck becomes reviews and CI, and that the runners are handled so nobody thinks about CI infrastructure. A quote is not a measured speedup. As of two weeks before this post, tests that need a graphics chip, which the page calls a GPU, get StarSling GPU Runners. One early customer is seeing a 14 times shorter queue. The customer is not named. Do not name one, and do not turn “two weeks ago” into a calendar date.

The second gate, Review Runners. Hosted review bots let a team customize the reviewer, the post says, but engineers still repeat themselves on every pull request. Review Runners are meant to let the team build its own. The review belongs to the team: the model, the skills, the scripts, and the reviewer responsibilities, versioned with the code and run in CI. A skill, on the product page, packages the context and scripts a team uses to review one part of the codebase. Coding agents already load repository instructions, skills, and tools that change with the code. The post says code review should work the same way. Review Runners run the team’s model, the repo’s review skills and scripts, and the team’s reviewers as GitHub Actions jobs on every pull request, before a person opens it. The product page says that is one workflow file. A workflow file is the recipe GitHub Actions runs.

Three things the team owns, in the post’s order. First, the model. Bring your own provider key. The reviewer calls the model through the team’s account, so the token bill stays with the provider the team already uses. A token is a small chunk of text the model maker bills. A provider key is the secret that lets software call that model. Second, the review code. Skills, scripts, instructions, and reviewer configuration live in the repository, next to the code they review. Merge an update and later reviews use the new version. Third, the reviewers. A team can define reviewers for security, APIs, tests, database changes, or frontend architecture. An API is a door one program uses to talk to another. Each reviewer gets its own responsibilities and skills. The example on the page: a security reviewer can get the security scripts, and an API reviewer can get the API conventions. File the three as the company’s. This desk did not write a reviewer.

How the post says a pull request cannot rewrite its own reviewer. Skills and instructions load from the trusted base branch immediately before the model runs. The base branch is the copy the team already trusts, not the proposed change. The job that runs the model holds a read-only token, a key that can look but not change the repository. A separate step publishes the review. The diff, the title, the description, and the comments are treated as untrusted input. A diff is the line-by-line change. Untrusted means the model is not supposed to treat that text as instructions that rewrite the reviewer. The product page repeats the base-branch rule in shorter form. These lines are the company’s. This desk did not inspect a token.

What each reviewer leaves behind. One structured comment: a verdict, findings by severity, exact path:line references, and a concrete fix. A verdict is the overall call. Severity is how serious a finding is. path:line is the file and the line number. The product page adds that a counts line closes the comment, including zeros when the reviewer finds nothing. A new push cancels any pass still running on the previous commit, so the next finished review covers the latest code. The picture on the blog shows a high-severity finding on auth/session.ts line 142 and a medium one on api/routes/billing.ts line 64, signed by a security reviewer. That is an illustration on the page. It is not a pull request this desk opened.

Who gets paid, and the rate the product page prints. Pay StarSling for the runner. Pay the model provider for the model. The blog says reviews are billed by the minute like any other CI job. The product page is specific. A review runs on the 2 vCPU runner by default, at $0.004 a minute, the same rate card as every StarSling runner, from 2 to 64 vCPU. A vCPU is a slice of a processor. $0.004 is four-tenths of one cent. Billing runs from job start to finish, rounded up to the nearest minute. Queue time is never billed. Concurrency is unlimited, which means the page says there is no cap on how many reviews run at once. Model tokens are billed by the team’s own provider, on the account it already has. These prices are the product page’s. This desk did not receive an invoice. The first month of StarSling Runners, the CI product, includes 2,000 free minutes. The post does not say those free minutes cover Review Runners. Do not move them.

The round, and who the pages name. The post does not say a firm led it. It names Bessemer Venture Partners and Y Combinator first. Additional investors are Vermilion Cliffs Ventures, Precursor Ventures, Cervin Ventures, Outset Capital, and Transpose Platform. That is five more funds, which matches the page description. Angels named on the post: David Cramer, co-founder of Sentry; Zach Holman, described as GitHub’s second engineering hire; Idris Mokhtarzada, co-founder and chief technology officer of Rocket Money; Kulveer Taggar, founder of Phosphor Capital; and engineering and product leaders from OpenAI, Anthropic, ClickHouse, Google, Microsoft, Meta, Coinbase, and Shopify. That last group is unnamed. Do not add names. The page does not print a valuation. A valuation would be a price on the whole company. Do not invent one. Elliott Robinson, partner at Bessemer Venture Partners, said every phase of building software is being rebuilt to be agent-native, and that CI is next. He said Daniel helped build the internal developer platform that the 3,000-plus engineers at Netflix relied on, and that Yonas built StackShare into a community of more than a million developers. More than a million is the quote’s figure. The post is signed Yonas and Daniel. The byline names Yonas Beshawred as co-founder and chief executive. The company about page names Daniel Worku as co-founder and chief technology officer, and names Yonas Beshawred again as co-founder and chief executive. The funding, the post says, will go to compute and to hire additional founding engineers in the San Francisco Bay Area.

How a team starts, and where the page stops. Three paths. StarSling Runners: install the GitHub App, swap one job to a StarSling label, and compare the run. The first month includes 2,000 free minutes. Review Runners: sign up for early access and say which models you run and how much you spend on code review. The product page says tell StarSling which repositories and which model, and the company will set the organization up. GPU Runners: contact the company and say which graphics chips you need, and at what scale. Early access is not a date the page prints for the end of the beta. The post does not print a price for a review beyond the per-minute runner rate on the product page, and it does not name a customer who turned Review Runners on today.

Plain English for the rest of the card: pre-seed = the earliest private check. The page does not print a valuation. private beta and early access = a limited trial. The page does not call Review Runners generally available. CI = continuous integration, the automated checks on a proposed change. pull request = that proposed change. GitHub Actions = the system that runs the jobs. runner = the machine that runs a job. ubuntu-latest = GitHub’s default runner name. EPYC = AMD’s server-chip line. 5th Gen is the product page’s word for the CI runners. roughly 30 percent faster is the blog’s comparison with GitHub. agent = software that takes steps. skill = the instructions and scripts a team commits for one kind of review. token = a small chunk of text the model maker bills. provider key = the secret that calls the model on the team’s account. base branch = the trusted copy, not the proposed change. read-only token = a key that can look but not change the repo. diff = the line-by-line change. verdict = the reviewer’s overall call. severity = how serious a finding is. path:line = file and line number. vCPU = a slice of a processor. $0.004 a minute = four-tenths of one cent, the default 2 vCPU rate on the product page. 2,000 free minutes = the first month of the CI runners, not a Review Runners allowance the post states. GPU = a graphics chip. This filing is the 22 Sep announcement.

PRIMARY here: StarSling’s 22 Sep 2026 post, “Announcing Our $3M Pre-Seed Round and StarSling Review Runners,” at starsling.dev/blog/pre-seed — Tier A PRIMARY, the company’s own record. The visible date is September 22, 2026. The page does not print an hour. The $3 million pre-seed from Bessemer Venture Partners, Y Combinator, and several other investors, the five named funds, the named angels, the private-beta line in the page description, the early-access signup, the April launch of StarSling Runners, the two gates, the EPYC and roughly-30-percent lines, the self-improving pull requests, the Mastra, Better Auth, and Partcl chart, the over-2-million jobs, the up-to-6-times and up-to-13-times lines, the over-28,000 hours, the Aiyer quote, the GPU Runners line, the three things the team owns, the base-branch load, the read-only token, the separate publish step, the untrusted diff, the one structured comment, the cancel-on-push rule, the minute billing, the 2,000 free CI minutes, the Robinson quote, the Beshawred byline, the Yonas and Daniel sign-off, and the Bay Area hiring line are the post’s. The 2 vCPU default, the $0.004 rate, the 2-to-64 vCPU card, the round-up rule, the unpaid queue time, the unlimited concurrency, the skill definition, and the 5th Gen EPYC line are the Review Runners product page’s. Daniel Worku’s title as co-founder and chief technology officer is the company about page’s. NOT claimed: that a firm led the round, a valuation, general availability, an hour stamp, that this desk ran a review or timed Mastra, Better Auth, or Partcl, the two prices behind 13 times cheaper, a name for the GPU customer, that the illustration is a real pull request, that the 2,000 free minutes cover Review Runners, a stock tip, or investment advice. Distinct from the already-filed rabbit-os3, subconscious-51m, and lumos-mcp-governance.