Small Prepaid API Test Checklist

Why Use a Small Prepaid Test

Advertised unit prices are estimates based on typical request sizes. Actual cost depends on input length, output length, provider route, retries, failed attempts, tool calls, concurrency and model pricing tier. A small test lets you measure what actually happens before committing a larger budget.

Without a controlled test, you risk discovering unexpected costs only after scaling. With a test, you have actual data to calibrate estimates and decide whether to proceed, adjust, or stop.

What to Decide Before Funding

Before adding any prepaid balance, define the test scope:

• Which provider and model you plan to use in production
• Current unit price for the selected model
• Expected input size in tokens, characters or file size
• Expected output size in tokens, characters or media duration
• For image or video APIs: resolution, format and duration
• Planned request count for the test phase
• Hard concurrency and retry limits
• Hard stop condition — at what balance or failure rate you will halt

Do not use a fixed global amount such as "always deposit $5" or "$1 is enough." Choose a test balance based on the factors above. The goal is to cap exposure, not to assume one amount fits every API.

Define a Controlled Test Case

A representative test case reflects real production usage as closely as possible. If you plan to send 2,000-token inputs, do not test with 100-token inputs.

• Match the input size you expect in production
• Use the same model and provider route you plan to use
• For image or video: use the same resolution and duration
• For agents: include the same tool calls and context you expect to use
• Run the same number of concurrent requests you anticipate

Set a Spending Boundary

Define a maximum budget for the test before funding. This is not a guarantee — it is a personal spending limit you set based on the factors above.

• Calculate the cost of one representative request at current pricing
• Multiply by the number of test requests you need
• Add a buffer for retries, but set an explicit cap
• Set a monitoring check: if balance drops by more than X in Y minutes, stop and investigate

Record Request and Usage Data

For every test request, record these fields in a log or spreadsheet:

• ✓request_id — unique identifier for this request
• ✓timestamp — when the request was sent
• ✓Model and provider route used
• ✓tokens_in — input token count
• ✓tokens_out — output token count
• ✓Cached tokens, if reported
• ✓For image APIs: count and resolution
• ✓For video APIs: duration and format
• ✓tool_calls — number of tool calls made
• ✓retry_count — retries this request triggered
• ✓Reported usage.cost from the response
• ✓Success or failure state

Test Success, Failure and Retry Paths

A complete test covers not only successful requests but also failure and retry behavior.

• Success path — normal request, record cost and output quality
• Retry path — trigger a retriable failure, observe how many retries occur and whether each attempt is billed
• Rate limit path — test what happens at the concurrency or rate limit, record the HTTP 429 response and Retry-After header
• Balance depletion path — observe the exact error code and message when balance runs low
• Invalid request path — send a malformed request, check that it returns the correct error code and does not consume budget

Compare Local Logs With Provider Records

After running the test, reconcile your local records against the provider dashboard:

• Match each request_id to the Activity or usage log
• Compare tokens_in and tokens_out against the dashboard values
• Verify usage.cost per request against the dashboard deduction
• Check whether retries produced duplicate entries in the Activity log
• Identify any requests that were billed but returned unusable output
• For providers that bill at different rates for input and output, verify both separately

Discrepancies do not always mean billing is wrong — some providers apply routing adjustments, cached-token discounts or provider-level corrections. Log evidence before drawing conclusions.

Calculate Cost per Successful Result

Do not estimate production cost from a single request or from advertised unit prices alone. Use this formula for a more accurate estimate:

cost_per_successful_result = total_test_cost / number_of_usable_successful_outputs

The denominator is not the total number of requests. Reduce it when:

• Retries consumed budget without producing output
• Failed or timed-out requests were still billed
• Outputs were discarded as unusable or low quality
• Parallel jobs ran simultaneously, multiplying cost
• Tool calls accumulated overhead beyond the visible output
• Duplicated requests sent the same prompt more than once
• Outputs were larger than expected, consuming more tokens or operations

Check Rate Limits and Concurrency

Before scaling, understand the rate limits that apply to your account or API key:

• Requests per minute or per day
• Tokens per minute, if enforced
• Concurrent request limits
• Whether rate limits apply per API key or per account

A rate limit error (HTTP 429) is different from an insufficient balance error (HTTP 402 for OpenRouter). Do not assume that adding more credits resolves a 429. Reduce request rate or wait for the window to reset.

Image and Video Generation Checks

Image and video generation APIs introduce additional cost variables:

• Resolution and aspect ratio affect per-image cost
• Number of images per request multiplies cost
• Video duration and frame rate affect per-second cost
• Seed values can produce different outputs — record the seed used
• Generation time may have a separate cost component
• Failed or timed-out generations may or may not be billed — check the provider documentation
• Webhook delivery failures may incur retry costs

Agent and Tool-Call Checks

Agent workflows and multi-step tool-call sequences add cost layers beyond a single API call:

• Each tool call sends context back to the model, accumulating tokens_in
• File reads, command output and retrieved context all add to the next request payload
• Parallel agent sessions multiply token cost linearly
• Memory or RAG retrieval can send large context chunks on each turn
• Retry loops within an agent session can escalate cost rapidly

For agent workflows, track tokens_in, tokens_out, tool_calls and retry_count per session turn.

Stop Conditions

Define explicit stop conditions before the test. Halt and investigate if any of these occur:

• ✓Balance drops faster than expected based on your cost estimate
• ✓Usage records do not match your local logs by more than a small margin
• ✓A retry loop continues beyond your defined retry limit
• ✓Duplicate requests appear in your Activity log
• ✓Output quality is unusable for the intended purpose
• ✓Rate limits prevent representative testing at the intended concurrency
• ✓Provider routing changes unexpectedly mid-test
• ✓Request IDs or cost records cannot be reconciled with your local data

After the Test: Scale, Adjust or Stop

Use the data collected during the test to make an informed decision:

• If cost per successful result is within your budget and output quality meets requirements, plan a gradual scale-up
• If costs exceed expectations, investigate the specific cause — it may be addressable through input trimming, model switching or retry limit tuning
• If billing records do not match your logs, use the API Billing Mismatch guide before scaling
• If rate limits prevent representative testing, consider whether the provider's limit is compatible with your use case
• If the provider route is unstable or unpredictable, factor this into your production risk assessment

Small Prepaid Test Checklist

• ✓Define the test scope: model, provider, input size, output size, request count, concurrency, retry limit
• ✓Calculate an estimated cost based on current unit pricing
• ✓Set an explicit spending cap and a balance-monitoring stop trigger
• ✓Fund only the test budget — do not fund a full production budget before testing
• ✓Record request_id, timestamp, model, tokens_in, tokens_out, usage.cost and state for every request
• ✓Test success, retry, rate limit and balance depletion paths
• ✓Compare Activity or usage log against local records after the test
• ✓Calculate cost per usable successful output — not cost per request
• ✓Investigate any stop condition before proceeding to scale
• ✓Use actual test data to calibrate production estimates

Related Guides

Frequently Asked Questions