provefab.

Issue text and code needed for a stage go to your configured model providers; Jev receives issue text when configured. Provefab keeps the change record on your machine. Model calls use a supported login; sandboxed commands have no network access.

Codex 0.162.1 accepts supported personal logins stored in files or an API key; workspace and managed modes refuse. Pi 1.0.3's sandboxed Bash was tested with SRT 0.0.79. All Claude stages temporarily refuse before version/auth probes because implicit host context loading is unverified. Select Codex or Pi and replace Claude entries in your catalog; keep user state. Check the docs before choosing a worker.

Builds are available for macOS (Apple Silicon and Intel) and Linux (x86_64 and ARM64), with launchd or systemd user services. Native sandbox enforcement was exercised on Apple Silicon macOS; Linux enforcement remains unverified. SRT must be provisioned separately. A missing or unverifiable runtime stops execution, with no unsandboxed fallback.

Jev rates how hard each issue is, how much planning it needs and how risky a mistake would be. Provefab then runs each stage on the cheapest model that meets that level: your plan first, then your API keys by price. Prices update daily. An implementation that keeps failing moves one tier up.

If you opt in, Provefab runs your repository's commands again on the exact commit its pull request produced. A failing command is rerun once, so a flaky test does not count as a failure. If the failure is confirmed, Provefab checks the current branch: when a later commit already fixed it, it only tells you. Otherwise it can open a revert pull request, but only if the reverted code passes the same commands and the merge can be undone as one commit. Reverts always wait for human review. This checks your commands, not deployments or production health.

A local record of what it observed, what the models claimed and what you decided. Reply /provefab F2 rejected (or accepted, fixed, waived) on a pull request to record your decision on a review finding; only commands from the issue author, and repository owners, organization members and collaborators, count. provefab export writes the record as JSON Lines with free text removed by default; provefab prune deletes the record of finished tasks last updated before a date. It is free, stays on your machine, and is what Pro's calibration report is built from.

Not unless you turn it on. By default a pull request arrives green, with its evidence, and waits for your click. Pro can auto-merge small changes under a policy you set: size cap, excluded paths, a test change required.

Provefab checks which files each round changed. Migrations, CI, dependencies, infrastructure, secret-looking files and paths you name are treated as risky: your extra commands for that area run, the review runs on the frontier tier when a frontier model from another provider is configured (otherwise the usual cross-provider reviewer stays), the pull request gets a Risk section and the issue gets a label. Pro never auto-merges a risky change unless you allow its category, and never when the changed files cannot be determined. This raises scrutiny; it does not prove a change harmless.

Yes. Put the provefab:review label on a pull request, or comment /provefab review (owners, members and collaborators only), and Provefab reviews it with a model from your catalog, your repository rules and the risk policy. It keeps one summary comment on the pull request, updated on each new review, and records the findings so your team can mark them accepted, rejected or fixed. It never approves, requests changes on or merges a person's pull request, and the pull request's code never runs: the reviewer reads the change with read-only commands inside its own checkout.

Yes, through a rules file you control. Write your conventions in .provefab/rules.md, one numbered rule each, optionally limited to some paths: every task reads them from your base branch, the agents follow them and the reviewer reports a violation with the rule's number. Provefab Pro can also propose new rules from the decisions your team records (findings you reject, changes you request when closing a pull request), each backed by at least two of them, in one pull request a week at most; merging it approves the rules, closing it refuses them. Rules guide the agents; they do not guarantee correct code.

Yes, in beta. A repository can take its issues from a Jira Cloud project or a Linear team: the same label hands a ticket to Provefab, which reports progress with labels and comments on the ticket and never changes its status. The code and the pull request stay on GitHub, and the ticket key goes in the branch and the pull request title so your Jira or Linear GitHub integration links them. Sign in once with provefab login jira or provefab login linear; the credentials stay in the macOS Keychain, or on Linux in a file readable by your account only (mode 600), not encrypted. Beta means it is tested against recorded API responses, not yet against live sites.

Pull requests keep opening and each one still shows its cost; the second reviewer, auto-merge, cost reports, calibration reports and rule proposals stop.

Only to renew your key, and you can turn that off. The license check itself never needs the network.

Yes. Your first payment is refunded in full if you ask within 14 days. Renewals are not refunded; you can cancel any time and keep Pro until the end of the paid period.

From the Polar customer portal at polar.sh/provefab/portal: sign in with your purchase email, then cancel. You keep Pro until the end of the paid period. The portal also has your invoices and the provefab-pro download.

You can use, change and share Provefab for anything except a competing product. Each version becomes Apache 2.0 two years after its release.