Skip to main content

​
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 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. 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 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, test cases, production checks or code fixes.