Token counts read off the response, not estimated
Caching saved 69%.
A smaller model saved more.
One question, asked four ways against 27.6 thousand characters of context. Every token count below came out of the usage block of a real response. Nothing here is a calculator.
The four answers are printed further down, because a saving you cannot check against the output is a number without a claim attached to it.
| model | cached | fresh | out | cost | time | |
|---|---|---|---|---|---|---|
| cold unique prefix, nothing to match | gpt-4.1 | 0 | 7,444 | 130 | $0.015928 | 4.9s |
| priming the call that put the prefix in the cache, paid at full price | gpt-4.1 | 0 | 7,418 | 110 | $0.015716 | 2.3s |
| warm identical prefix, moments later | gpt-4.1 | 7,296 | 122 | 122 | $0.004868 | 1.7s |
| cheaper model same question, smaller model | gpt-4.1-mini | 0 | 7,418 | 95 | $0.003119 | 2.2s |
Caching cut the cost by 69.4% and the wait by 2.9 times
The warm call reused 7,296 tokens and paid full price for 122. Same model, same question, same context. $0.015928 became $0.004868.
The smaller model, with no cache at all, was cheaper than the big one with a full cache
$0.003119 against $0.004868, which is 80.4% off the cold price. Read the four answers below and decide whether it cost anything. This is the result I was not looking for: I set out to measure caching and the bigger lever was the model.
Switching model threw the cache away
The smaller model ran on the identical prefix and still reported 0 cached tokens, because the cache is keyed per model. So routing to a cheaper model and caching aggressively are partly in competition, and which one wins depends on how often the same prefix repeats.
The four answers, so you can price the difference yourself
The question was: In one short paragraph, using only the material above: what does the address guard do that a check on the hostname string does not?
The address guard resolves the actual IP address of a hostname and checks that address against a list of private and reserved ranges, ensuring that requests cannot reach internal networks or sensitive endpoints—even if an attacker uses tricks like trailing dots (e.g., `localhost.`), domains with A records pointing to private IPs, IPv6/IPv4-mapped addresses, or hex representations. In contrast, checking the hostname string alone is like a spell check: it can be fooled by alternate spellings or DNS records, and would miss cases where the hostname looks safe but actually resolves to a blocked address, leaving the application vulnerable to internal port scanning and metadata service access.
The address guard goes beyond simply matching patterns on the hostname string by actually resolving the hostname to its underlying IP address and checking if that address is private or reserved, blocking requests to internal or sensitive networks (like 127.0.0.1 or 169.254.169.254) even if they are hidden behind custom hostnames or tricky spellings. It ensures that outbound requests connect only to validated, safe addresses and prevents attacks such as DNS rebinding or use of misleading hostnames, which a string-based check alone cannot reliably stop.
The address guard actually resolves and validates the final IP address before making a connection, ensuring that a request cannot reach private, reserved, or internal networks—even if the hostname is cleverly crafted (like `localhost.` with a trailing dot) or points to a blocked IP via DNS. In contrast, a check on the hostname string is just pattern-matching; it can easily be bypassed by alternate spellings, attacker-controlled domains pointing to forbidden IPs, or DNS rebinding, allowing requests to sensitive internal resources. Only the address guard—by checking and connecting to the exact validated IP—provides real protection.
The address guard verifies the resolved IP addresses of a hostname to ensure none belong to private, reserved, or internal network ranges before connecting, while a hostname string check merely matches patterns and can be easily bypassed with tricks like trailing dots or attacker-owned domains pointing to internal addresses. By resolving and validating the actual IP address, then connecting only to that pinned address, the guard prevents security breaches such as internal metadata service scanning and rebinding attacks that hostname string checks cannot reliably stop.
What this measurement does not tell you
It ran once, on 2026-09-07. The page reads the file that run wrote rather than calling the API when you load it, because doing that would spend money on every visitor to show a number that barely moves.
The token counts are measured. The prices are list prices, read on 2026-09-07, and they live in one constant in the script so there is a single thing to correct when they change.
This provider caches automatically on anything over about a thousand tokens, with no premium to write and no way to ask for it. Anthropic does the opposite: you place the breakpoint yourself and pay more to write than to read. The cost shape here is real and the strategy is not transferable, so the same script runs against both and this is the half that had credit on it.
One question is not a benchmark. Four answers that read equally well tell you the smaller model handled this, not that it handles everything.
Reproduce it with node scripts/prompt-cache-cost.mjs openai. The MCP server scopes what an agent may change, the eval scores the audit engine on precision and recall, the guard is a box you can attack, and every defect any of it has had is written down.