Skip to main content

Copy this into your coding agent

Paste into Cursor, Codex, Claude Code, or another coding agent in your project.
CI runs your tests automatically when someone opens or updates a pull request. Bench can record these runs and, in JavaScript and TypeScript, check application outcomes. Installing the SDK does not create a CI workflow or a required PR check.

Prepare the test suite

Complete your language setup and commit its dependency lockfile. During the preview, the CI runner also needs access to the SDK installation source shown in Bench. A successful local installation does not grant your runner access to a private Git repository. For JavaScript and TypeScript, create the cases and application adapter described in application testing. Keep the same cases, business criteria and test data when comparing a change. Include at least one normal task, one reproduced failure and one previously working behavior. The following ESM script expects your tests/bench-suite.mjs to export createBenchSuite(bench). That is your application adapter, not an SDK export. It returns contextRevision, cases, run, and, when needed, observe and timeoutMs. Pass the same Bench instance to your instrumented application. Save as scripts/bench-ci.mjs:
For scripted conversations, call bench.simulateSystem with your session adapter instead. The report and pass/fail gate have the same shape. A failed check can still have summary.status: 'completed', so checking that field alone is not enough.

Add a GitHub Actions job

Set BENCH_API_KEY as a repository secret and BENCH_API_BASE_URL as a repository variable using the values from Bench. The default SDK key is sufficient for tracing and saving application reports. These operations do not consume Bench evaluations. Your application’s model calls can still have provider costs. Save as .github/workflows/bench.yml, alongside your existing tests:
The source revision records the commit actually checked out by CI. On a pull request, that can be GitHub’s test merge commit. Add this job as a required check in your repository rules if failed outcomes should block merging. GitHub does not supply repository secrets to forked pull requests or Dependabot runs. This script fails clearly when the key is missing. Use a reviewed, trusted run for those contributions; never switch to pull_request_target to execute untrusted PR code with secrets. See GitHub’s secrets documentation.

Python, Go and Rust

Wrap application operations in your existing tests with the matching SDK. Keep assertions in the test runner, read actual test database or tool state, and flush the client before the test process exits. Use environment: ci to separate these events from staging and production. These clients record traces. They do not turn a failing application test into a passing one or create a Bench application report automatically. Trace delivery also does not determine application correctness; inspect client delivery statistics separately if telemetry receipt is a requirement of your integration test.

Verify the setup

  1. Run a correct fixture and confirm the job passes.
  2. Change one expected outcome and confirm the job fails with a saved report.
  3. Remove an assertion or force a timeout and confirm incomplete work cannot pass.
  4. Restore the case, rerun, and inspect the saved report artifact.
To display a TypeScript report under Application tests, explicitly call bench.publishSystemEvaluation(systemId, report) with the correct system ID. Uploading an Actions artifact alone does not publish it to Bench. See application testing for report limits and examples. The JavaScript application-test helpers capture spans inside the report; flushing does not upload those spans as production events. Ordinary tracing around Python, Go or Rust tests sends events you can find in Bench’s ci environment.