Open a pull request on a repository with the Ship Safe GitHub App installed, and you now get two reviews in one comment: the deterministic Ship Safe scan you already had, and a Kimi K3 read of the same diff.
Every account gets ten Kimi reviews free. Not a trial that expires — ten lifetime credits, and a review that fails to complete costs you nothing.
Why add a model to a scanner
Static analysis is very good at things that have a signature. A hardcoded AWS key has a shape. A dependency with a known CVE has a version range. A pull_request_target workflow that checks out untrusted code is a pattern you can match.
It is much worse at things that require reading intent.
A tool definition whose description quietly widened from "read the current file" to "read project files" is still valid JSON, still passes every rule, and has just changed what an agent is allowed to touch. A prompt template that interpolates a variable is fine until you ask who else can write to that variable. A permission check that looks correct in isolation is wrong if the function above it already returned the object.
None of that has a signature. It needs something that can hold the diff in its head and ask whether the change means what it appears to mean.
What the review actually does
The important design decision: Kimi does not decide whether your code is safe.
The deterministic scanner produces the result. It runs on every pull request regardless of your Kimi balance, and it remains the authoritative finding set. Kimi's output appears as a clearly-labelled advisory section of the same comment. It can add context and it can dispute a finding in writing — it cannot suppress one.
That ordering matters. A model that can silently delete findings is a model that can be talked into deleting findings, and prompt injection through a pull request diff is not a hypothetical for a tool that reads pull request diffs for a living. The scanner is the floor, and the floor does not move.
Here is a real review, from the pull request that shipped this post's own documentation:
Secrets 0
Vulnerabilities 0
Changed-file scan 100/100 (A)
### Kimi K3 triage
Docs-only PR adding a paragraph documenting the large-repository scan
limit and the bounded changed-file fallback behavior. No deterministic
candidate findings were supplied and no executable code changed, so
there is nothing to confirm or dispute.
> Advisory context only (high confidence). The Ship Safe scan remains
> the source of truth.Note what it did there: nothing. A docs-only diff got a two-sentence "nothing to review here" and no invented findings. A reviewer that manufactures work on an empty diff is worse than no reviewer, because you stop reading it.
How credits work
- Ten free reviews per account, lifetime. Your balance is on the settings page.
- A failed review is free. If the provider call fails, times out, or comes back empty, the credit is returned and the comment tells you what happened.
- Retries do not double-charge. Reviews are keyed on the commit, so a redelivered webhook for the same head reuses the existing review. Pushing a new commit is a new review, because it is a different diff.
- Deterministic scans are never gated. Run out of Kimi credits and your pull requests still get the full Ship Safe review.
That last point is the one we care most about. The scanner is the product; Kimi is an addition to it.
What we fixed before shipping
We found three bugs getting this to production, and two of them had been running quietly for weeks. They are worth writing down because they are all the same species: failures that produce no error.
A model finding could destroy the entire review
The semantic review loop rejected the whole batch when any individual finding failed validation. One malformed item and the review returned nothing — not a partial result, nothing. It now skips the bad finding, keeps the rest, and reports the count of what it discarded, so the number is visible instead of implied.
Reviews were produced and never published
This one is our favourite, in the way that a scar is a favourite.
Ship Safe dismisses its previous review when it posts an updated one. The dismissal filter included reviews in the COMMENTED state — and GitHub returns 422 when you try to dismiss a COMMENTED review, because there is nothing to dismiss. The publish step failed, the error was caught, and the run reported success.
The effect: reviews were generated correctly, cost a credit, and were then thrown away. Pull requests kept displaying a review frozen at the first commit. Nothing errored, and no dashboard showed a number that would have looked wrong.
It also poisoned our own metrics. We spent an afternoon investigating what looked like a 43% failure rate before realising we were measuring reviews that had been stuck at their first head for weeks. A bug in your telemetry is worse than no telemetry, because you act on it.
One pull request could exhaust an organisation's API budget
The last one we caught the day of launch, and only because our own repository tripped it.
Ship Safe fetches a repository as a single archive. Above 50MB that is not possible, so it falls back to fetching one file at a time — up to 2,000 GitHub API requests. A pull request runs that fallback twice: once for the head, once for the base it compares against.
GitHub gives an App installation 5,000 API requests an hour.
So a single review of one large repository could spend roughly 4,000 of them, and every subsequent review across every repository in that organisation would fail until the hourly reset. Worse, the failure was reported to users as "Ship Safe could not retrieve the repository contents" — because the classifier tested the error message for rate limit with a space, while the error spelled it rate-limit with a hyphen. It fell through to a branch that matched on the word "GitHub" and told people to fix a network problem that did not exist.
A pull request already had a cheaper path available: scan only the changed files. It now declines the expensive fallback above a 300-request budget and takes that path instead. The check runs before any file is fetched, so declining costs one request rather than thousands.
This is the shape of bug that a quiet launch never finds. It only appears under load, which is to say it appears exactly when you succeed.
Known limits
Repositories over 50MB get a narrower scan. They fall to the changed-files path: no dependency analysis, no base comparison. The comment says so explicitly rather than presenting partial coverage as complete.
We are not quoting a reliability number. Outcome recording only went in this week, so any figure we published today would be invented. We would rather tell you the failure mode: if the model call fails you see Kimi K3 status: failed, you still get the full deterministic review, and you are not charged.
Your diff is sent to a model provider. Kimi K3 runs on Moonshot's API. If that is not acceptable for your codebase, the deterministic scanner runs entirely without it and always has.
Turning it on
Install the Ship Safe GitHub App on a repository and open a pull request. That is the whole setup. The review arrives as a comment, your credit balance is on the settings page, and the CLI remains MIT-licensed and free for unlimited local scans.
Ten reviews is enough to find out whether it is telling you anything you did not already know. That is the number we would want before deciding.
FAQ
How many free Kimi PR reviews do I get?
Ten per account, for the life of the account rather than per month. A review that fails to complete is refunded, and deterministic Ship Safe scans are never gated on your balance.
Can the AI suppress a security finding?
No. The deterministic scanner produces the authoritative result and runs on every pull request. Kimi's output is a clearly-labelled advisory section of the same comment — it can dispute a finding in writing but cannot remove one.
What happens when I run out of credits?
Your pull requests still receive the full deterministic Ship Safe review. The comment reports quota-exhausted and links to upgrading.
Is my code sent to a model provider?
The diff is sent to Moonshot's API for the Kimi review. If that is not acceptable for your codebase, the deterministic scanner runs entirely without it.