# Test the integration first, then compare models with the same workload

> A useful prototype separates plumbing from model evaluation. Prove authentication and response parsing with the free model, then run the same bounded task against paid candidates and compare the evidence your product actually needs.

_Last reviewed 2026-08-15 · [Editorial review](https://keeprouter.com/editorial-policy#editorial-team)_

## Day one: prove the path

Create a key restricted to the published free model and follow the [quickstart](/docs/quickstart). Verify a non-streaming response, then streaming if the product uses it. Save the request ID and inspect measured usage. This confirms DNS, authentication, SDK configuration, response parsing, and the gateway route without mixing in paid-model selection.

## Day two: define the evaluation

Choose a real user task with a fixed input, expected output, maximum tokens, timeout, and pass criteria. If the product uses tools, include a complete tool round trip. Select two or three compatible candidates from the [live catalog](/models); do not choose solely from a generic benchmark label.

## Day three: compare evidence

For each model, record canonical ID, date, route, completion status, input and output tokens, latency, charge, and product-quality score. Repeat enough times to expose obvious variance, but label the result as your workload sample—not a universal benchmark.

## Turn the prototype into a product boundary

Move the model ID and key into environment configuration. Create separate development and production keys, apply an allowlist and spend limit, set explicit timeouts, and document retry behavior. Link price displays to the live catalog instead of copying the number into code.

## Know when the prototype has answered enough

The goal is not to try every model. Stop when one option meets the task contract, its cost is acceptable on measured usage, and the team has a rollback. Re-evaluate when the workload, provider revision, price, or route behavior materially changes.

## Frequently asked questions

### What should we test with the free model?

Use it to prove authentication, SDK configuration, response parsing, and logging—not to infer paid-model quality.

### How many paid models should a prototype compare?

A small shortlist that matches the route and task is more useful than testing the whole catalog without criteria.

### Should we copy prices into the prototype?

No. Link to or read the live catalog because price and availability can change.

### When is the prototype ready for production?

When the full client path, task criteria, spend boundary, failure behavior, and rollback have all been tested.

## Sources reviewed

1. [KeepRouter OpenAPI](https://keeprouter.com/api/openapi.json)
2. [KeepRouter live model catalog](https://keeprouter.com/models)

## Related guides

- [quickstart](https://keeprouter.com/docs/quickstart.md)
- [Unified LLM API](https://keeprouter.com/features/unified-llm-api.md)
- [How to evaluate an AI gateway with a proof-based scorecard](https://keeprouter.com/blog/evaluate-ai-gateway.md)
- [How do I use one API for multiple LLMs?](https://keeprouter.com/answers/how-to-use-one-api-for-multiple-llms.md)

## Start with one bounded request

Create a key scoped to the free model, prove the client path, then approve paid models from the live catalog.

[Create a free key](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree) · [Live models and pricing](https://keeprouter.com/models.md)