# “Background” requests latency

**URL:** <https://community.openai.com/t/background-requests-latency/1371902>\
**Category:** API\
**Created:** [January 18, 2026, 2:56am UTC](https://community.openai.com/t/background-requests-latency/1371902 "2026-01-18T02:56:51Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![StroeAndre](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/stroeandre/32/517902_2.png) [@StroeAndre](https://community.openai.com/u/StroeAndre)\
**Post date:** [January 18, 2026, 2:56am UTC](https://community.openai.com/t/background-requests-latency/1371902/1 "2026-01-18T02:56:51Z")

</div>

Hi everyone… posting here as a last resort.

For the past few hours, all of my background requests have been taking several minutes to return a response. I checked the API Status page and everything looks normal. I also contacted OpenAI Support, but the only explanation I got was “variable latency”, which hasn’t been very helpful.

At first I assumed it might be related to queueing, so I switched the project to the Priority tier, but it didn’t improve anything. With time passing if anything, it seems even worse…

Non-background requests are working fine, but my entire pipeline relies on sequential backend processing, which is why I use background mode + webhooks.

Is anyone else experiencing this issue with background requests right now?

---

<div class="post-metadata">

**Author:** ![Foxalabs](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/foxalabs/32/738355_2.png) [@Foxalabs](https://community.openai.com/u/Foxalabs)\
**Post date:** [January 18, 2026, 4:01am UTC](https://community.openai.com/t/background-requests-latency/1371902/2 "2026-01-18T04:01:45Z")

</div>

Hi,

When you say background requests, do you mean the lower cost “Batch” API calls? Or regular API calls? Do you have a code snippet that shows the setup and execution of the API call?

---

<div class="post-metadata">

**Author:** ![\_j](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/_j/32/766292_2.png) [@\_j](https://community.openai.com/u/_j)\
**Post date:** [January 18, 2026, 5:21am UTC](https://community.openai.com/t/background-requests-latency/1371902/3 "2026-01-18T05:21:13Z")

</div>

> [@Foxalabs](#):
>
> When you say background requests

On the Responses API, you don’t have to keep a connection open and wait for the output or the stream, or get nothing if the connection closes. You can use “background” parameter to immediately close the connection after it is ingested.

To obtain the response, you can either poll the status of the response ID, or can subscribe to a webhook to know when to check.

Should OpenAI be charging the same and the parameter gives you terrible service? Absolutely not.

> [@Is "Background" stable for heavy usage?](https://community.openai.com/t/is-background-stable-for-heavy-usage/1368364/2):
>
> You have a good question, where the answer must always be: "background": true in Responses will not change the priority of your AI task or how it is run, and there should be no delays except as are inherent in polling or in separately transmitting a webhook. Unlike batches, or with the “service\_tier” parameter, you are not requesting or expecting any different level in service and reliability. You are simply allowing the generation to continue after an initial closed connection, with a method…

One should compare the latency of the model vs a normal API request, to see if the observation is true and repeatable, because gpt-5 simply thinks for way longer than anyone could expect.

---

<div class="post-metadata">

**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\
**Post date:** [March 23, 2026, 3:19pm UTC](https://community.openai.com/t/background-requests-latency/1371902/5 "2026-03-23T15:19:38Z")

</div>

Hey StroeAndre, Can you please confirm if you are still facing latency issue with background requests? If yes, can you please share the request id with us. We are more than happy to help. Thank you!

---

<div class="post-metadata">

**Author:** ![\_j](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/_j/32/766292_2.png) [@\_j](https://community.openai.com/u/_j)\
**Post date:** [March 23, 2026, 3:52pm UTC](https://community.openai.com/t/background-requests-latency/1371902/6 "2026-03-23T15:52:30Z")

</div>

This message was added months ago at [https://developers.openai.com/api/docs/guides/background:](https://developers.openai.com/api/docs/guides/background:)

> Currently, the time to first token you receive from a background response is higher than what you receive from a synchronous one. We are working to reduce this latency gap in the coming weeks.

Hey @OpenAI_Support, Can you please confirm if you are still working to reduce this latency gap. If yes, can you please share the completion date, or if not, share the quality degradation that one may face that is recognized but without mitigation currently?

Then, you have “streaming” of the background response. If attempted, this was terminating the stream connection within five minutes. The same documentation page used to have “resuming the background streaming is coming”, but that future promise of a feature that could make this useful is now gone.

---

<div class="post-metadata">

**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\
**Post date:** [March 30, 2026, 12:04pm UTC](https://community.openai.com/t/background-requests-latency/1371902/7 "2026-03-30T12:04:41Z")

</div>

Thanks for flagging this. The latency gap for background responses is still a known tradeoff, and we don’t have a completion date to share right now. I’m not aware of a model quality degradation specific to background mode; the main difference is request lifecycle and time-to-first-token, not output quality.

For long-running tasks, the most reliable pattern is still to use background mode with polling, or background streaming with reconnect via `starting_after` if your client can support it. Stream disconnects around ~5 minutes are typically caused by idle client/proxy timeouts rather than a hard response limit, so if you’re seeing that consistently, polling is the safer option today.

---

<div class="post-metadata">

**Author:** ![Prashant\_Pardesi](https://avatars.discourse-cdn.com/v4/letter/p/f9ae1b/32.png) [@Prashant\_Pardesi](https://community.openai.com/u/Prashant_Pardesi)\
**Post date:** [April 5, 2026, 2:28pm UTC](https://community.openai.com/t/background-requests-latency/1371902/8 "2026-04-05T14:28:14Z")

</div>

Closed on April 5, 2026, 2:28pm UTC


