With background=True it never uses cache and only uses 1210 input tokens, with background=False it uses 6417 input tokens and 6202 cached_tokens. Pro mode and cache seem not to work with background=True.
from openai import OpenAI
from time import sleep
client = OpenAI()
for _ in range(2):
r = client.responses.create(
model="gpt-5.6-sol",
reasoning={"mode": "pro", "effort": "high"},
background=True,
input="Reply only OK.\n" + "The blue folder contains a simple note about a quiet garden.\n" * 100,
)
while r.status in ("queued", "in_progress"):
sleep(1)
r = client.responses.retrieve(r.id)
print("Tokens:", r.usage)
a significantly longer sleep that 1s or await a finished first job? These could be dispatched in quick series before the input processing of one call is stored and routable, and without stream=true, the background API call should be async and non-blocking;
send a prompt cache key unique to the calls being tested for warm-up and fulfillment
Was this discovered with use of real documentation or text of that kind of length? OpenAI has previously produced an error on too much repeating API input to models; they could potentially let it fly and optimize out duplication also.
(reasoning effort: high and even output larger than max_output_tokens=25 should not be needed in order to test input behaviors)
away from my PC with all my tools and code to easily make the API replication in another form
Yes I tried to wait 10 seconds after receiving the first response, still the same problem. The Pro mode doesn’t seem to turn on when background=True, because the input token usage is so low that it looks like it is using only 1 agent. With background=False the input token usage is 5x bigger because it probably uses 5 agents.
Yes I discovered this in real use where it makes a lot of tool calls and input length goes up to 100k, never got any cache hits and token usage was similar to without pro mode, but if background=False cache works great and token usage is many times more if I enable pro mode (so with background=False it actually seems to be using multiagents, otherwise not).
Tried changing the text and using a prompt cache key, still same problem, no cache usage.
On prior models that actually have -pro in the name, there is no cache discount at all. That of course does not change when batched or by service tier.
API requests never should change from “background”, which is not a priority change but just a different way of receiving a response.
Pro “mode” on 5.6 has a billing paradigm switch. From the price of the model being higher → to the token consumption being higher.
Using more “agents” as you assume needs the beta API for “ultra” performance. “openai-beta”: optional array of “responses_multi_agent=v1”
“pro” mode is using test-time compute of token runs (a phrase for “while inference is running”).
This is an issue of possibly not getting pro if you are requesting pro
the responses API will echo the “mode” value actually employed.
you can see without using background if the switch from pro to non-pro is the exact same usage difference as normal to background, as input billing should be deterministic.
Then, there is cache not working, and whatever OpenAI’s true undocumented intention about delivering it, that the behavior must never change simply from “background”, which is NOT a change in priority or queue position. OpenAI must address this, and I’ll see if I can get an escalation passed on.
Note the source below: It seems that cache performance is simply worse in normal use when mode:pro, not “off” or broken, if you want to classify typical costs. Input usage is also directly magnified, likely employing at least underlying non-determinism in preload. Increased misses may be poor technology in matching kv under multiple parallel internal token run techniques.
Thus, clarified answer: caching is still present, not completely disabled, as you see in your normal use.
You report no cache hits - and no “pro” usage inflation at the same time. Because of the bug, “background” seems not an option until repaired (if you have the budget to pay for pro!)
