Skip to main content
An experiment is an immutable snapshot of an evaluation run — permanently stored, comparable over time, and shareable across your team. Unlike playground runs, which overwrite previous results for fast iteration, experiments preserve exact results so you can measure improvements, catch regressions, and build confidence in your changes.

Run locally

Run evaluation code locally to create an experiment in Braintrust and return summary metrics, including a direct link to your experiment. See Interpret results for how to read it.
Install the SDK and dependencies:
Create the eval code:
Run your evaluation with the bt eval CLI:
Use --watch to re-run automatically when files change:
Benefits of using the CLI:
  • Automatic .env loading — reads .env.development.local, .env.local, .env.development, and .env
  • Multi-file support — pass multiple files or directories: bt eval [file or directory] .... Running bt eval with no arguments runs all eval files in the current directory.
  • TypeScript transpilation — no build step required; the CLI handles it
You can pass a parameters option to make configuration values (like model choice, temperature, or prompts) editable in the playground without changing code. Define parameters inline or use loadParameters() to reference saved configurations. See Write parameters and Test complex agents for details.

Run in UI

Create from scratch

Create and run experiments directly in the Braintrust UI without writing code:
  1. Go to Experiments.
  2. Click + Experiment or use the empty state form.
  3. Select one or more tasks to evaluate: prompts, workflows, or remote evals and sandboxes.
  4. Choose or create a dataset:
    • Select existing dataset: Pick from datasets in your organization
    • Upload CSV/JSON: Import test cases from a file
    • Empty dataset: Create a blank dataset to populate manually later
  5. Optional: Click Filter under the dataset field to scope the experiment to a subset of records. Filter by input, expected, metadata, tags, or any custom column using SQL expressions. The experiment runs only against records matching the filter, and the filter is recorded on the experiment.
  6. Use the Scorers field to add scorers and classifiers to score and label outputs.
  7. Click Create to execute the experiment.
UI experiments run without a time limit on cloud and on self-hosted deployments running data plane v2.0 or later.

Promote from a playground

Playground runs are mutable — re-running overwrites previous results. When you’ve iterated to a configuration worth keeping, promote it to an experiment to capture an immutable snapshot:
  1. Run your playground.
  2. Select + Experiment.
  3. Name your experiment.
  4. Access it from the Experiments page.
Each playground task maps to its own experiment. Experiments created this way are comparable to any other experiment in your project.

Run in CI/CD

Integrate evaluations into your CI/CD pipeline to catch regressions before they reach production.

GitHub Actions

Use the braintrustdata/eval-action to run evaluations on every pull request:
Set runtime to node, python, or go to match your project. The action automatically posts a comment with results to the pull request, which requires the pull-requests: write permission shown above.

Other CI systems

For other CI systems, use bt eval directly:
Create an API key under Settings > API keys and set it as BRAINTRUST_API_KEY in your CI environment. Use --no-input to suppress prompts and --json for machine-readable output. Use --first N or --sample N to run a non-final smoke test on pull requests and reserve the full run for merges:

Configure experiments

Customize experiment behavior with options:
In the TypeScript, Python, and Ruby SDKs, you can set each inline eval case’s origin field to link it back to its source dataset row. This populates the dataset performance view, which only shows experiments whose eval traces set origin.

Run without uploading results

Sometimes you want to run your evaluation locally without creating an experiment in Braintrust — while iterating on a new scorer, wiring up a new eval pipeline, or running in an environment without a Braintrust API key. Your tasks and scorers still run and print a summary to your terminal; results just aren’t uploaded.
Via the CLI:
Or in code:

Run trials

Run each input multiple times to measure variance and get more robust scores. Braintrust intelligently aggregates results by bucketing test cases with the same input value:
To analyze trial results and compare variance across inputs, see Compare trials.

Override trial count per case

Individual data rows can set their own trial count to override the global default. Use this when a few inputs need extra trials to measure variance, while the rest don’t:
Per-case values take precedence over the global trialCount / trial_count / TrialCount. If neither is set, the input runs once.

Enable hill climbing

Hill climbing lets you improve iteratively without expected outputs by using a previous experiment’s output as the expected for the current run. To enable it, use BaseExperiment() in the data field. Autoevals scorers like Battle and Summary are designed specifically for this workflow.
Braintrust automatically picks the best base experiment using git metadata if available or timestamps otherwise, then populates the expected field by merging the expected and output fields from the base experiment. If you set expected through the UI while reviewing results, it will be used as the expected field for the next experiment. To use a specific experiment as the base, pass the name field to BaseExperiment():
When hill climbing, use two types of scoring functions:
  • Non-comparative methods like ClosedQA that judge output quality based purely on input and output without requiring an expected value. Track these across experiments to compare any two experiments, even if they aren’t sequentially related.
  • Comparative methods like Battle or Summary that accept an expected output but don’t treat it as ground truth. If you score > 50% on a comparative method, you’re doing better than the base on average. Learn more about how Battle and Summary work.

Create custom reporters

When you run an experiment, Braintrust logs results to your terminal, and bt eval returns a non-zero exit code if any eval throws an exception. Customize this behavior for CI/CD pipelines to precisely define what constitutes a failure or to report results to different systems. Define custom reporters using Reporter(). A reporter has two functions:
Any Reporter included among your evaluated files will be automatically picked up by the bt eval CLI command.
  • If no reporters are defined, the default reporter logs results to the console.
  • If you define one reporter, it’s used for all Eval blocks.
  • If you define multiple Reporters, specify the reporter name as an optional third argument to the eval function.

Include attachments

Braintrust allows you to log binary data like images, audio, and PDFs as attachments. Use attachments in evaluations by initializing an Attachment object in your data:
You can also store attachments in a dataset for reuse across multiple experiments. After creating the dataset, reference it by name in an eval. The attachment data is automatically downloaded from Braintrust when accessed:
To forward an attachment to an external service like OpenAI, obtain a signed URL instead of downloading the data directly:

Trace your evals

Add detailed tracing to your evaluation task functions to measure performance and debug issues. Each span in the trace represents an operation like an LLM call, database lookup, or API request.
Use wrapOpenAI/wrap_openai to automatically trace OpenAI API calls. See Trace LLM calls for details.
Each call to experiment.log() creates its own trace. Do not mix experiment.log() with tracing functions like traced() - this creates incorrectly parented traces.
Wrap task code with traced() to log incrementally to spans. This example progressively logs input, output, and metrics:
This creates a span tree you can visualize in the UI by clicking on each test case in the experiment.

Troubleshooting

If your evaluations are slower than expected when using maxConcurrency, you may be on an older SDK version that flushes logs after every single task completion. Upgrade to TypeScript SDK v3.3.0+ for up to an 8x performance improvement. The SDK now uses byte-based backpressure for better flushing performance.You can tune the flush threshold with the BRAINTRUST_FLUSH_BACKPRESSURE_BYTES environment variable. See Tune performance for all available configuration options.
When the task function throws, the C# eval framework catches the exception, records it on the task span and root span (with ActivityStatusCode.Error), and calls ScoreForTaskException on every scorer instead of Score. The eval continues — no cases are skipped.By default, ScoreForTaskException returns a single score of 0.0. Override it on your IScorer to return a custom fallback score, return an empty list to omit scoring for that case, or re-throw to abort the eval.
#skip-compile
The task span and root eval span both receive an OTel exception event with exception.type, exception.message, and exception.stacktrace attributes, visible in any OTel-compatible backend connected to Braintrust.
When a scorer’s Score method throws, the exception is recorded on that scorer’s span (with ActivityStatusCode.Error and an OTel exception event) and ScoreForScorerException is called as a fallback. Other scorers continue running unaffected.By default, ScoreForScorerException returns a single score of 0.0. Override it to return a custom fallback, return an empty list to omit the score, or re-throw to abort the eval.
#skip-compile
Score spans are named score:<scorer_name> (e.g. score:my_scorer), making individual scorer traces distinguishable in Braintrust and any connected OTel backend.

Next steps