FAQ

Questions, answered.

When would you use Klinn?

When update PRs pile up because nobody owns them: a Dependabot or Renovate backlog waiting on someone's sprint, a framework major (SQLAlchemy 2, Werkzeug 3, pydantic v2) that keeps getting postponed because it breaks call sites, or security patches sitting unmerged because an update broke the build last time. One honest limit: Klinn's proof is your own test suite run in a clean sandbox — the supply-chain vetting works on any repo, but the 'nothing broke' guarantee is only as strong as your tests.

How is Klinn different from an engineer fixing update PRs by hand?

Doing it by hand means paying twice: the engineer's time and the AI tools they drive, for work that repeats every week and still waits for their sprint. Klinn is the automation instead — every update PR runs in its own isolated sandbox the moment it opens, the breakage gets fixed with your suite as the referee, and the result is one click to merge (safe bumps can merge themselves). You pay the model compute at cost, typically well under a dollar per cleared update.

Is it safe to auto-merge Dependabot PRs?

Only if something checks the version itself, not just your build. A green CI run proves the update did not break your code; it says nothing about whether the new release is malicious. Klinn adds that missing check: every version waits out a cooldown, is screened against known advisories, and has its published code diff reviewed before your tests run in a clean sandbox. Only updates that pass all of it merge, each with a dossier of the evidence.

What can Klinn touch in my repo?

Only the dependency update PRs that Dependabot or Renovate already opened. Patch and minor bumps on your allowlist can merge; everything else escalates to you with an explanation. In shadow mode, Klinn has zero write access.

How do you know a new version is safe?

Each version waits out a cooldown window, because most supply-chain attacks are caught within days of publish. Klinn then checks it against the OSV advisory database and reads the package's published code diff for malicious patterns. Any failed check holds the merge and leaves the decision to you.

What happens when an update breaks my code?

Klinn runs your test suite against the update in a clean, isolated environment. If tests fail, it repairs your usage of the dependency and verifies again until the suite is green. If it can't, the PR escalates with a plain explanation of what broke and why.

Will it rewrite my code unattended?

No. A gate blocks edits to your tests, CI, and anything beyond the update itself, and caps how many files a fix can touch. A change outside those bounds escalates to you instead of merging.

What is shadow mode?

The full pipeline runs on your real update PRs, but nothing is pushed or merged. You see exactly what Klinn would have done, with the same evidence, before you grant write access.

What access does Klinn need?

A GitHub App scoped to the repos you pick. Shadow mode needs read access only. The agent that touches code runs in an isolated sandbox and never sees your secrets.

How does pricing work?

You pay per fix from a prepaid credit balance, like OpenRouter or Cursor. Each run deducts its compute step by step while you watch: you pay the true compute cost with no markup, and a complicated fix simply uses more of your balance. Watching your repos is free, so connect as many repos as you want. Top up from $5; credits never expire and there is no subscription. New accounts start with $3 of free credits and no card.

Which ecosystems are supported?

Python (requirements.txt) and JavaScript/TypeScript (package.json) today, end to end: bump parsing, sandboxed fixing, clean-environment verification, and package-diff vetting. The advisory screen already covers every major registry through OSV, so Go modules and Rust crates are next on the roadmap — if you need one of them, say so and it moves up.

Clear your backlog with Klinn.

Try Klinn

Starts in shadow mode · zero write access · free to try