Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If your test suite sends real requests to an API, each run can incur usage charges. The dependable fix is to make routine tests offline: replace the provider at a controllable client or request boundary with deterministic test doubles, intercepted responses, or recorded fixtures. Keep a small live integration check separate so it runs only when you intend it to.
Why a test run can spend API credits
A test costs API usage when the code path it exercises sends a real request to a billable provider. This can happen in unit tests, workflow tests, or browser tests if they inherit an API key and reach the production SDK or HTTP client. Replacing a model response in one part of the test does not guarantee that every other network or telemetry boundary is offline.
Start by locating where the application creates its provider SDK, HTTP client, and dependencies. Also inspect test setup for credentials or shared fixtures that might route tests to a live environment. The goal is to substitute the external boundary—not to make assertions depend on variable live output.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose an offline boundary that fits the test
| Approach | Best suited to | What to watch |
|---|---|---|
| In-process test double or fake client | Application logic and agent workflows where you want scripted outputs and direct call inspection | It validates the behavior represented by the double, not current provider compatibility |
| Request interception | Browser or HTTP behavior where the test should see a known response without reaching the API | Define the expected request and response explicitly; a handler that fetches live data and then edits it is not offline |
| Recorded response fixtures | Cases where provider-shaped payloads matter and deterministic replay is useful | Review fixture matching and refresh them intentionally; fixture behavior depends on the implementation |
| Shared programmable mock service | Teams that need a common mock endpoint or want to simulate delays, rate limits, and errors in CI | It adds a service dependency and setup; vendor-documented capabilities are not a neutral comparison of cost or reliability |
Use test doubles for application logic
Inject a fake client or transport into the code under test and script the responses the scenario needs. OpenAI’s Agents SDK testing guide documents deterministic in-memory doubles for agent workflows, sandbox sessions, and Realtime sessions; it says those doubles make no model, sandbox-provider, or Realtime API requests. See the Agents SDK testing documentation.
#1 Best Overall
Use the fake to assert the request shape, call order, and application-level result. If your application retries or falls back, script failures such as a timeout, rate limit, or provider error and verify that logic directly. A stable scripted response is more useful for this purpose than a live model response that can vary between runs.
Intercept browser requests before they leave the test
For browser tests, register a route that matches the API request and fulfill it with known JSON. Playwright’s documentation says its fulfilled mock-request example makes no API requests. A handler that first fetches the real response and then modifies it still performs a live request. If captured traffic is what you need, Playwright also supports recording and replaying HAR files. See Playwright’s network mocking guide.
Replay fixtures when payload shape matters
Recorded fixtures can preserve provider-shaped responses while keeping routine runs deterministic. One implementation pattern documented by llm-mock is to record deliberately, replay in normal tests, and make a missing fixture visible instead of silently calling the network. Treat this as that project’s documented approach, not an independent validation of its feature claims. Keep fixture creation and refresh intentional, and arrange a separate manual or scheduled live check if current provider compatibility matters.
Make sure the whole test is offline
Replacing model or API calls does not necessarily disable tracing, analytics, or other network activity. The OpenAI Agents SDK testing guide specifically notes that tracing is a separate boundary: disable it in tests intended to be fully offline. Review other clients and background exporters as well, and ensure an accidental live call fails clearly rather than quietly using inherited production credentials. See the SDK guidance on testing and tracing.
Rank #3
Keep live integration tests deliberate
Some tests should verify the provider boundary itself—for example, that request serialization still works or that the current provider remains compatible. Put those checks in a separate command or CI job rather than running them with every unit and browser test. Restrict their credentials to the needed environment and control when they run. This preserves a place for real-provider validation without making every routine test run depend on the network or accrue usage.
- Make the default test command use fakes, intercepted responses, or replayed fixtures.
- Create a separate integration-test command for the small set of checks that need a live provider.
- Give that job only the scoped credentials it needs and run it manually or on a deliberate schedule.
- Make fixture misses and unexpected outbound requests fail visibly in the offline suite.
Prompt caching can lower eligible input cost, but it does not make tests offline
Prompt caching concerns repeated eligible input prefixes; it does not prevent a test from sending a request. OpenAI’s current API guide says matching prefixes and compatible settings are required. It currently states a minimum cacheable prompt length of 1,024 tokens for GPT-5.6 and later, with thresholds varying for earlier models. Model eligibility and rates can change, so consult the current prompt-caching guide before relying on those details.
The same guide currently describes cache writes at 1.25× the ordinary input rate and cache reads at 0.1× for most GPT-5.6-and-later models, or 0.05× for GPT-6.1 Sol. Under its illustrative assumptions, one write followed by nine full reads across ten requests costs 2.15× the uncached cost of one request, versus 10× for ten uncached repetitions. These are documented, model-specific rate mechanics—not a guaranteed saving for a test suite. For Responses API requests on supported GPT-5.6-and-later models, OpenAI recommends checking cached tokens, cache-write tokens, and total cost across representative requests; see its cache-usage diagnostics. Any extra baseline or retry requests used for comparison are still billed normally.
Quick Recap
A practical checklist before the next test run
- Find the SDK, HTTP client, and dependency-injection points used by the tested code.
- Replace provider calls for routine tests with scripted doubles, intercepted responses, or explicitly replayed fixtures.
- Assert request content and application behavior; simulate errors where retry or fallback behavior matters.
- Disable tracing and other exporters if the suite must make no external requests.
- Separate live integration checks, credentials, and run cadence from the default test command.
- Use cache metrics only to understand eligible live-request costs, not as evidence that a request was avoided.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
