> ## 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.

# Quick scan: quality and cost

> Find what to investigate before running a full bench.

## Copy this into your coding agent

Paste into Cursor, Codex, Claude Code, or another coding agent in your project.

```text theme={null}
Help me interpret this Bench scan using https://docs.usebench.ai/guides/quick-scan.
Read the findings and their source evidence. Prioritize what could affect the app's outcome.
Separate source warnings, possible cost savings and failures actually measured by tests.
For the highest-priority finding, show the smallest test that could confirm or reject it.
Do not claim a tool works or a fix is verified without execution evidence.
```

Connecting a repository reads its code and finds prompts, models, tools and workflows.
Open a finding in Feed, Findings or a system’s Results to see its right sidebar: what Bench found, the source evidence and the next step. Close it to return to the same list.
A missing test input or an untested tool is a gap in coverage, not a confirmed defect.

## What the scan checks

| Finding               | What it means                                                | What to do                                                              |
| --------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------- |
| Missing prompt values | Part of the prompt is filled in when your app runs.          | Set up Real app testing to check the full prompt with your app’s tools. |
| Tools not tested      | Bench found tool definitions but has not called those tools. | Use Real app testing to check their results.                            |
| Model not identified  | The model is selected outside the code Bench could read.     | Review the detected configuration.                                      |
| Lower-priced model    | Another model has lower listed token prices.                 | Start a bench to compare quality and estimated cost.                    |

The scan does not execute your application or produce a measured quality score.
AI review suggestions cite their evidence and remain suggestions until tested.
An AI review cannot prove that an unexecuted tool works.

An additional **Evidence review**, when available, checks whether cited sources
support the AI review's claims. Its percentage is an estimate of evidence
agreement, not your application's quality score. Missing or oversized evidence
stays unavailable; it does not become a passing check.

## Potentially lower model cost

**Potentially 86% lower model cost** means a candidate model has a lower price for
the same input and output volume. It does not mean your production bill has fallen.

For example, standard text prices checked on 19 September 2026 are:

| Model      | Input per million tokens | Output per million tokens |
| ---------- | ------------------------ | ------------------------- |
| GPT-5.2    | \$1.75                   | \$14.00                   |
| GPT-5 Mini | \$0.25                   | \$2.00                    |

Both prices are about 86% lower for GPT-5 Mini. At an illustrative 1,000 input
and 500 output tokens per call, that is about **$8.75 versus $1.25 per 1,000 calls**.
This example assumes identical usage, standard text requests, and no caching,
batch discounts, tools, hosting or negotiated rates. Different models can use
different numbers of tokens, retries or tool calls.

Sources: [GPT-5.2 pricing](https://developers.openai.com/api/docs/models/gpt-5.2)
and [GPT-5 Mini pricing](https://developers.openai.com/api/docs/models/gpt-5-mini).

The finding sidebar identifies both models and links to their price sources.
If input and output prices fall by different percentages, Bench shows a range.
Missing models and stale prices remain unknown, not zero. Quick-scan prices
expire after 30 days unless refreshed.

## Turn an opportunity into evidence

1. Bench the original setup against system-specific criteria and cases.
2. Test supported candidates against the same cases.
3. Compare quality, failures and estimated model cost per call.
4. Validate the proposed change on independent cases before rollout.
5. Use production usage after deployment to verify the real impact.

A cheaper model is not automatically a better choice. The recommendation must
meet the quality and regression checks. A quick-scan comparison also does not
guarantee that the named alternative is enabled in the current candidate set.

During evaluation, Bench calculates model cost from recorded input/output usage
and its price catalog. Judge and test-generation spend are separate from the
customer workflow's projected cost. These are estimates, not imported invoices.
See [evaluation results](/guides/evaluations) and [production checks](/sdk/production-checks).

## Why there is no predicted quality percentage before testing

Repository structure and model price do not establish answer quality. A quality
gain needs a baseline and a candidate evaluated on the same representative cases.
A small preliminary test can support a provisional result, but it must show its
sample size and cannot stand in for a full benchmark or independent validation.

Learn about [real app testing and simulation testing](/guides/testing-modes), including what each can verify.