juror

Juror is a GitHub Action that asks several frontier models to review each pull request in parallel. It combines duplicate findings into one report and posts the review, merge score, and cost receipt back to GitHub.

Juror Cloud

This repository also contains cloud/, a deployable hosted companion with GitHub and Google sign-in, GitHub App automation, a lean findings and run inbox, isolated Cloudflare Sandbox execution, post-merge staging QA, and transparent Stripe metered billing. The open-source Action and CLI remain independently usable, while repositories connected to Cloud use hosted execution exclusively.

See the Juror Cloud deployment guide for the GitHub App permissions, Cloudflare resources, secrets, billing meter, and verification commands.

ChatGPT, Codex, and MCP

Juror Cloud is also available as a remote, OAuth-protected Streamable HTTP MCP server at https://app.juror.dev/mcp. Add that URL in an MCP-compatible client, sign in with your Juror Cloud account, list your workspaces first, and then inspect concise review summaries.

The integration is intentionally narrower than the GitHub Action and local CLI:

• Juror Cloud MCP / Plugin — inspects workspace-scoped findings and hosted runs. It can prepare and, after explicit user confirmation, start or rerun an existing hosted Juror Cloud review. It never accesses arbitrary local repositories or returns raw diffs, full reports, artifacts, screenshots, credentials, or prompt text.
• Juror Cloud — the hosted service that owns workspace membership, GitHub App access, isolated execution, retention, and billing.
• GitHub Action and CLI — run from your repository or local environment using the configuration you control. Do not run the hosted service alongside a Juror GitHub Action for the same repository.

Starter prompts:

• “Show my Juror workspaces and review findings.”
• “Summarize open P0 and P1 Juror findings in this workspace.”
• “Prepare a hosted review for this open PR; show me the SHA and cost warning before starting.”

The canonical registry metadata is registry/server.json. See the directory submission record for publication status and the required external verification steps.

Add Juror to your repository

Start from the Juror AI listing in GitHub Marketplace: click Use latest version to add it to a workflow. If you prefer to add it directly, create .github/workflows/juror.yml with this ready-to-run workflow:

name: Juror

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

concurrency:
  group: juror-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    # Provider secrets are never exposed to code from forks.
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
        with:
          fetch-depth: 0
          filter: blob:none
      - uses: juror-ai/juror@178a16d6fa3a1b868094bc4236d42fb8e442ea6a # v1.3.3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
        env:
          JUROR_OPENAI_API_KEY: ${{ secrets.JUROR_OPENAI_API_KEY }}
          JUROR_FIREWORKS_API_KEY: ${{ secrets.JUROR_FIREWORKS_API_KEY }}

Then add at least one provider key in Settings → Secrets and variables → Actions. One key starts a review; adding a second provider makes the default fast preset a cross-model jury:

gh secret set JUROR_OPENAI_API_KEY
gh secret set JUROR_FIREWORKS_API_KEY

Commit the workflow and open a pull request. Juror immediately posts a sticky Juror is reviewing… comment, then replaces it with the findings, merge score, and bill. Every Action input besides github-token is optional; see action.yml for preset, models, config, cost-target-usd, post, and pr-number.

The example pins both Actions to immutable commits. The Marketplace's generated snippet is a convenient starting point; use an immutable SHA in the committed workflow to keep the reviewed Action version fixed.

The CLI can generate the same SHA-pinned workflow, inspect the plan first, and optionally upload provider keys through the GitHub CLI:

export JUROR_OPENAI_API_KEY=…
npx juror-ai init --set-secrets

# Or inspect the planned workflow and secrets without changing anything.
npx juror-ai init --dry-run

To review an existing pull request locally without creating a workflow:

npx juror-ai review --pr 1234 --repo owner/name          # prints to your terminal
npx juror-ai review --pr 1234 --repo owner/name --post   # also posts the review

The optional starter preset uses one JUROR_OPENROUTER_API_KEY to reach two model families:

npx juror-ai init --preset starter --set-secrets

---

Benchmark evidence: Juror Fast found 4× more adjudicated P0–P2 defects than Greptile

On the bundled production-PR seed, Juror Fast found 4/6 (66.7%) P0–P2 defects at 100% precision. Greptile found 1/6 (16.7%) at 50% precision.

Reviewer	P0–P2 recall	Precision
Juror Fast	66.7% (4/6)	100% (4/4)
Greptile	16.7% (1/6)	50% (1/2)

This is a manually adjudicated, one-PR seed—not a statistically sufficient replacement benchmark. Inspect the corpus and methodology, or reproduce it with juror benchmark --file benchmarks/platform-10359.json.

Optional post-merge browser QA

Juror can also watch merged pull requests, plan affected user journeys, and exercise the live staging or branch deployment through Playwright with structured evidence and, for runs without authentication or supplied browser state, videos. Authenticated runs still interact with the product and evaluate plan-bound checkpoints, but each admitted page-dependent browser call returns the same sealed acknowledgement and completed-attempt outcomes stay hidden from the model:

npx juror-ai init --qa --set-secrets --target-url https://staging.example.com

For a product that exposes a fixed-identity synthetic support-session endpoint, Juror can mint a fresh, single-use login URL for every attempt through qa.auth.session_bootstrap. This v1 mode is restricted to the configured canonical staging origin: set qa.target.preview_fallback: false, and do not expect the session to follow a branch deployment with a different origin. Optional qa.auth.browser_secret_headers are injected only into requests to their exact configured origins, which supports a staging Cloudflare Access service token and a separate WAF header without exposing either credential to other hosts. All logical secrets remain inside JUROR_QA_SECRETS_B64; authenticated visual and trace evidence stays off and browser observations stay sealed.

Use the fixed synthetic-session service, not an arbitrary-user testing-login bypass. The post-merge QA quickstart includes a generic staging example and the required gateway prerequisite.

Repositories can also configure trusted qa.testability.early_exit_paths globs for paths that never justify browser QA. Juror returns a neutral, not-scored no_testable_surface result before deployment lookup, secret loading, model startup, or Playwright only when every path in the complete changed-file manifest matches. The default is empty because an infrastructure or docs tree can still affect a product in some repositories.

The target's exact origin is added to the browser allowlist automatically; repeat --allow-origin for any additional API origin the tested product needs. Without either target option, init writes a safely disabled QA policy and explains how to enable it. The released action verifies its container provenance before credential handoff. See the post-merge QA quickstart for the fastest local loop, staging target setup, synthetic login credentials, and result meanings.

By default, a policy without a trusted reset hook runs navigation-only journeys. A change whose affected journey requires interaction is reported as blocked, not as having no browser surface. Reviewed policy can set qa.sandbox.interaction_policy: read_only to enable click, fill, press, select, and check while Juror blocks non-safe HTTP methods and outbound WebSocket messages after the first action. Persistent mutations still require a dedicated synthetic tenant and qa.sandbox.reset. Each checkpoint fixes its assertion kind and exact locator or URL matcher before the browser opens; authenticated or supplied-state scenarios always run a second sealed attempt, and the controller derives the result from its private ledger. The final report necessarily reveals one bounded pass/fail result per predeclared checkpoint, so connect QA only to a synthetic account and tenant containing no production data or other sensitive records.

---

Why

Single-model PR bots have three problems, in order of how much they cost you:

1. Blind spots. Every model misses different bugs.
2. Duplication. Multiple reviewers often describe the same defect in different words.
3. Opacity. You pay per seat or per PR and never see what the inference actually cost.

Juror runs several models, uses code-aware similarity plus a conservative referee to deduplicate reports about the same defect, and defaults to high recall: every unique eligible finding is shown. Teams that prefer fewer, higher-confidence findings can switch review.publish_mode to consensus and use model agreement as a precision filter.

And there is no index and no SaaS. A coding agent doesn't need a prebuilt semantic index: the supported agent harnesses all ship repository read/search tools and will go inspect the callers of the function you changed. You get repo-wide context for the price of a few tool calls, with zero indexing infrastructure, zero staleness, and no code leaving the runner beyond the model API call itself.

Non-goals. Not an autofix bot. Not a linter (yours is better and free). Not a chat interface. It reviews a diff and posts findings.

---

How it works

Each model gets the diff, its own private scratch directory, and read-only access to a clean