{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibbbjchgwcmoxwpileax3ihwysh7vneckekeqzteu7cuxmm6jjcui",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mibojcrz6n72"
  },
  "path": "/t/background-requests-latency/1371902#post_7",
  "publishedAt": "2026-03-30T12:04:41.000Z",
  "site": "https://community.openai.com",
  "textContent": "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.\n\nFor 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.",
  "title": "“Background” requests latency"
}