> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usebench.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How Bench works

> Connect your AI system, test its behavior and review improvements.

## 1. Connect your system

Connect a GitHub repository or upload a prompt. Bench finds supported prompts,
models, tools and workflows, then groups them into AI systems. Open a system to
see the code it found and correct its name or scope.

A [quick scan](/guides/quick-scan) reads the code. It can identify missing test
inputs and lower-priced model options, but it does not run your application.

## 2. Tell Bench what good behavior means

Open **Understanding** to review the context Bench collected. Add your product's
purpose, rules and examples. For a refund assistant, that might include the refund
window, exceptions and when to ask a person for help.

Bench keeps context with the system it describes. Your stated rules take priority
over patterns in recorded behavior. Adding context does not start a paid evaluation.

## 3. Start a bench

Choose **Start benching**. Bench creates test cases and criteria, includes enabled
cases from your test library, measures the current prompt and model, then tests
possible improvements against the same cases.

A green pulsing dot means the bench is active. You can leave the page and return.
Use **Stop bench** on the system page to stop its active and queued prompts.
Completed results stay available.

To check the application's tool calls and final outcome together, use
[Real app testing](/sdk/system-evaluation). A prompt comparison alone cannot tell
you whether a tool changed a database or whether a workflow finished successfully.

See [real app testing and simulation testing](/guides/testing-modes) for a side-by-side comparison and setup links.

## 4. Understand the result

Open **History**, select a bench and choose **View details**. Review the cases,
criteria, failures, quality change and estimated model cost. Missing evidence is
shown as missing; it is not counted as a passing result.

A cheaper model may give worse answers. Compare both quality and cost before
changing your application. Previous results keep the context and cases used at
the time, so you can understand why results changed.

## 5. Review a fix

In **Fixes**, compare the original prompt with the proposed change. Copy a fix
prompt for your coding agent, or download a fix brief with the relevant evidence.
Review changes and rerun important cases before merging or deploying them.
An opened pull request is a proposed fix, not a change to your live application.

## 6. Learn from production

The SDK can record real interactions in **Production**. Review an unexpected
interaction, add the intended outcome and save it as a test case. Future benches
can include it. New interactions do not automatically rewrite your rules or
turn an incorrect response into an expected answer.

Continue with [SDK setup](/sdk/quickstart), [test cases](/guides/test-library),
[production checks](/sdk/production-checks) or [code fixes](/guides/automatic-fixes).