Skip to main content

Get started with EvalGate in 5 minutes

Start with the release decision. There are two supported ways in, and which one fits depends on what you already have rather than on a product tier. If a repository is already connected, you can inspect it first — one exact commit, read from GitHub, with no local checkout, no scaffold, and no change to your repository. Understand what the system does before deciding what to measure. If you have a checkout and no account, create a deterministic local gate in the repository where the AI behavior changes. This path is designed for a cloud coding agent in an ephemeral sandbox with no browser, no saved account, no GitHub remote, and non-interactive JSON output. Neither is a prerequisite for the other, and either can lead to the other.
Credential-free local evaluation requires no EvalGate account, organization, browser, API key, GitHub remote, or network request. Hosted collaboration is separate: evalgate login stores a revocable human session outside the repository and evalgate link stores only non-secret hosted context. Model- backed workflows use bring your own provider key (BYOK); EvalGate does not bundle inference credits.
init --local establishes only the local project, specs, configuration, and baseline lifecycle; it cannot be mistaken for hosted identity or cloud evidence. In the hosted workflow, login establishes the human session, link establishes the durable organization/repository/root once, and every cloud intake is pinned separately to an exact commit. Branch movement changes checkout status, not repository identity.

Official coding-agent Skills

Browse the official EvalGate Skills repository for the portable evaluation decision framework and setup, gate, trace, repository, and MCP workflows. Preview the collection with npx skills add evalgate/skills --list, then install the complete collection with npx skills add evalgate/skills. The collection is experimental. Skills supply instructions; they do not issue credentials or replace release-policy enforcement. See the coding-agent guide and agent discovery guide.

Prerequisites and completion check

Connected inspection is working when a scan completes for the exact commit you named and every finding it reports carries a source locator. A scan that reports partial completeness has not finished looking, so a negative answer from it is inconclusive rather than clean. The local loop is working when evalgate status --json reports readiness.localGate: true, a non-empty passing run is accepted as the baseline, evalgate gate passes unchanged, and a small intentional break makes the same gate block. Hosted readiness may remain false. Status exit zero means the status document was produced, not that every readiness dimension is true.

Two supported ways to start

Pick by what you have, not by a product tier. Both paths are first-class. Neither is a prerequisite for the other. Connected inspection does not require you to scaffold anything first, and local execution does not require an account.

Connected inspection

If a repository is already connected, you can get evidence-linked understanding of it before writing a single file in your repository. This reads one exact commit and never executes it:
Findings come back bound to source locators at the scanned commit. A detection is a detection: it shows what the source says, not what the running system does. What each step needs. Listing repositories, reading existing scans, and asking a question need eval:read. Starting a scan needs eval:write and organization membership, because it creates durable evidence in EvalGate — a scan run, a graph version, facts and source locators — in the same way accepting a baseline does. A credential with only eval:read can read evidence that already exists but cannot mint new evidence. eval:write is permission to write inside EvalGate. It is not GitHub repository-write access: nothing on this path pushes a branch, opens a pull request, or modifies your repository, and nothing requires an in-repository scaffold. Without a credential the CLI returns a machine-readable envelope — MISSING_API_KEY, exit code 5, with the commands that resolve it — rather than failing on a missing scaffold. Reading never implies authority to execute, patch, push, or merge; each of those is a separate grant. A well-supported “nothing found in the inspected scope” is a real answer, not a failure. Check the scan’s completeness before trusting a negative: a partial or truncated scan has not finished looking.

Local execution (credential-free)

Install the package and initialize local execution:
The first init is a machine-readable preview and writes nothing. The second is the cloud agent’s explicit write authority. Neither command performs a network request or invents a hosted organization/repository/snapshot identity. Later, evalgate login and evalgate link add hosted context without replacing the local specs, config, baseline, reports, or user edits.
In an interactive terminal, bare init previews the exact scaffold and asks before applying it. Explicit init --preview never prompts or writes. In non-interactive or JSON workflows it remains preview-only and requires --apply, preserving deterministic agent safety. init --local needs no hosted link. Plain init is the linked hosted variant and remains usable offline after linking. baseline update runs the suite and accepts the first baseline only when the run is non-empty and passing. Each apply or acceptance remains a separate approval boundary.
A checkout two commits behind its tracked branch remains linked and locally gate-ready. Cloud intake may target that older SHA when GitHub proves it is reachable from the branch; no push is required, and EvalGate does not silently evaluate the newer remote head. Ahead or unpushed work requires pushing the exact commit for cloud-backed evidence. Diverged work requires an explicit appropriate --ref <branch>. A dirty worktree may still run the local gate, but Git SHA alone cannot reproduce its uncommitted changes in the cloud.
After setup, you should have:

Write the first eval from examples

After confirming the product context, create evalgate.quality.json with one realistic input, the preferred response, the response to avoid, and a plain-language description of the problem. If the agent proposes a preferred response or failure mode, keep it labeled as a hypothesis until the builder confirms or edits it. Then preview the drafts:
Preview performs no writes, network calls, model calls, Git changes, baseline changes, or promotions. Apply only after the examples look right:
The resulting cases remain quarantined for review. Follow Write evals with your coding agent for the profile schema and portable Agent Skill.

Package handlers

Init detects npm, pnpm, Yarn Classic, Yarn Modern, Bun, Deno, pip, uv, Poetry, Pipenv, PDM, Conda, Mamba, Hatch, and Pixi as first-class handlers. The legacy yarn ID remains a compatibility alias. For a polyglot project, repeat the override so every declared handler is installed and tested from its owning directory:
Conflicting lockfiles stop the plan instead of silently selecting a winner. For an unsupported build tool, provide an explicit JSON argv command so spaces and quoting remain unambiguous:
From then on, one command is the daily path:
Make a tiny intentional break in an eval or test, run the gate again, and watch it fail. That is the first EvalGate loop: baseline -> change -> regression report -> CI gate. Connect saved production interactions when you want real failures to feed the same loop. If setup needs diagnosis, run npx @evalgate/sdk doctor --quick. It checks the local project without requiring cloud credentials.
Working in Next.js, FastAPI, LangChain, or RAG? Use the framework recipes after this proof when you want automatic run capture that matches the runtime you actually ship.
Local execution is an explicit onboarding mode with no hosted identity. A separately linked repository anchors dashboard/cloud evidence. CI needs an EVALGATE_API_KEY only for authorized hosted automation against an already established context; linking never creates one implicitly.

Optional hosted platform setup

Use hosted setup only for dashboard traces, shared historical runs, repository intelligence, organization policy, or cloud-backed judges/evidence.
Your EvalGate API key authenticates the SDK and REST API. It does not provide model access. LLM judges, synthesis, and other model-backed workflows also require a provider or gateway credential owned by your organization.
1

Activate a repository

Run npx evalgate login, approve the short code in the browser, then run npx evalgate link from the Git checkout. The CLI stores the revocable human session in your operating-system user configuration directory and writes only non-secret version 2 context under .evalgate/project.json: durable organization/repository/root identity plus the last exact activation target and manifest. Branch movement does not unlink the project. CI should use a separately created EVALGATE_API_KEY from its secret store.
2

Connect a model provider when needed

For LLM judges, synthesis, and governed model execution, open Settings → Provider Keys or Settings → Model Gateway and connect your organization’s provider credential. You can skip this step when you only need tracing, deterministic assertions, or local regression gates.Provider inference is billed by the connected provider, separately from your EvalGate plan. Follow Model providers and BYOK for the correct connection path, security boundary, and verification checklist.
3

Install the SDK

Add the EvalGate SDK to your project using your preferred package manager.
The Python SDK is available with pip install evalgate-sdk, but its published CLI currently trails the TypeScript launch path. Verify the installed version before using current-source Python workflows.
4

Configure environment variables

Create a .env file in your project root and add your credentials:
.env
Add .env to your .gitignore immediately to avoid committing secrets:
The SDK reads both variables automatically — no additional configuration required.
5

Initialize the client

Import and initialize the SDK in your application code. Calling AIEvalClient.init() with no arguments auto-loads EVALGATE_API_KEY and EVALGATE_ORGANIZATION_ID from the environment.
6

Create your first trace

A trace represents a single LLM interaction. Spans within the trace capture the individual steps — the model call, tool use, retrieval, or any sub-operation you want to observe.
After running this code, the trace appears in your EvalGate dashboard under Traces.
7

Write your first eval

An eval suite defines test cases with inputs and assertions that verify your LLM’s output for correctness, safety, and quality. The suite runner handles execution, parallelism, and reporting.
EvalGate includes 20+ built-in assertions covering text content, safety and compliance, JSON structure, quality, and numeric thresholds. Each assertion in a failing case surfaces a precise failure reason in run artifacts, the dashboard, and GitHub annotations when you use the platform check --format github path.

Turn repository evidence into evaluation coverage

After the local gate is working and your GitHub connection is authorized, scan one immutable commit before installing recommended coverage:
Repository Intelligence reads the protected source tree without executing repository code. Review the evidence-linked findings first; installing a pack then creates governed Dataset Hub coverage and a release-gate evaluation.

Scan a repository

Inspect one exact commit, review completeness, and ask evidence-bounded questions.

Install an evaluation pack

Turn reviewed recommendations into versioned datasets and release coverage.

Add a CI regression gate

Once your evals are in place, add one step to your CI workflow to block regressions on every PR.
.github/workflows/evalgate.yml
The CI step discovers your eval specs automatically, runs all specs by default, writes run artifacts to .evalgate/, and compares results against the base branch when --base is provided. Add --impacted-only to run only specs affected by the current diff. With --format github, the command writes a GitHub step summary and emits annotations for failed or regressed specs. The process exit status is the shell/CI result; JSON reports may also carry effectiveExitCode and releaseReady. Use evalgate capabilities --format json for the version-bound exit-code contract.

What’s next

TypeScript SDK reference

Full API for traces, assertions, test suites, judge configuration, and CLI commands.

Python SDK reference

Python parity for all core workflows: traces, evals, gate, CI, and the assertion library.

CI/CD integration guide

Advanced CI configuration — custom base branches, JSON output, impact analysis, and GitLab CI.

Framework recipes

Copyable setup paths for Node, Next.js, Python, FastAPI, LangChain, and RAG applications.

Repository Intelligence

Scan one exact connected commit and inspect evidence-linked AI-system findings.

Evaluation packs

Install governed first-party coverage for coding, support, legal, healthcare, and finance.

Authentication

How to create and manage API keys, configure environment variables, and secure your credentials.