Responses API ਵਿੱਚ WebSockets ਨਾਲ ਏਜੰਟਿਕ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ

ਜਦੋਂ ਤੁਸੀਂ Codex ਨੂੰ ਕੋਈ ਬੱਗ ਠੀਕ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਇਹ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਸਬੰਧਤ ਫਾਈਲਾਂ ਲੱਭਦਾ ਹੈ, ਸੰਦਰਭ ਬਣਾਉਣ ਲਈ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਸੋਧਾਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜਾਂਚਣ ਲਈ ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ ਕਿ ਸੁਧਾਰ ਕੰਮ ਕਰ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਮਤਲਬ ਹੈ Responses API ਦੀਆਂ ਦਰਜਨਾਂ ਆਉਣ-ਜਾਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ: ਮਾਡਲ ਦੀ ਅਗਲੀ ਕਾਰਵਾਈ ਨਿਰਧਾਰਤ ਕਰੋ, ਆਪਣੇ ਕੰਪਿਊਟਰ 'ਤੇ ਕੋਈ ਟੂਲ ਚਲਾਓ, ਟੂਲ ਦਾ ਆਉਟਪੁੱਟ ਮੁੜ API ਨੂੰ ਭੇਜੋ, ਅਤੇ ਇਹੀ ਪ੍ਰਕਿਰਿਆ ਦੁਹਰਾਓ.

ਇਹ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਮਿਲ ਕੇ ਕਈ ਮਿੰਟ ਬਣ ਸਕਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੌਰਾਨ ਵਰਤੋਂਕਾਰ Codex ਵੱਲੋਂ ਜਟਿਲ ਕੰਮ ਪੂਰੇ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਲੇਟੈਂਸੀ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, Codex ਏਜੰਟ ਲੂਪ ਆਪਣਾ ਵੱਧਤਰ ਸਮਾਂ ਤਿੰਨ ਮੁੱਖ ਪੜਾਅਾਂ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ: API ਸੇਵਾਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨਾ (ਬੇਨਤੀਆਂ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ), ਮਾਡਲ ਇਨਫਰੈਂਸ, ਅਤੇ ਕਲਾਇੰਟ-ਸਾਈਡ ਸਮਾਂ (ਟੂਲ ਚਲਾਉਣਾ ਅਤੇ ਮਾਡਲ ਸੰਦਰਭ ਬਣਾਉਣਾ)। ਇਨਫਰੈਂਸ ਉਹ ਪੜਾਅ ਹੈ ਜਿੱਥੇ ਮਾਡਲ ਨਵੇਂ ਟੋਕਨ ਬਣਾਉਣ ਲਈ GPUs 'ਤੇ ਚਲਦਾ ਹੈ। ਪਹਿਲਾਂ, GPUs 'ਤੇ LLM ਇਨਫਰੈਂਸ ਚਲਾਉਣਾ ਏਜੰਟਿਕ ਲੂਪ ਦਾ ਸਭ ਤੋਂ ਹੌਲਾ ਹਿੱਸਾ ਹੁੰਦਾ ਸੀ, ਇਸ ਲਈ API ਸੇਵਾ ਓਵਰਹੈੱਡ ਨੂੰ ਲੁਕਾਉਣਾ ਆਸਾਨ ਸੀ। ਜਿਵੇਂ-ਜਿਵੇਂ ਇਨਫਰੈਂਸ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਏਜੰਟਿਕ ਰੋਲਆਉਟ ਤੋਂ ਇਕੱਠਾ ਹੋਣ ਵਾਲਾ API ਓਵਰਹੈੱਡ ਕਾਫੀ ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ.

ਇਸ ਪੋਸਟ ਵਿੱਚ, ਅਸੀਂ ਸਮਝਾਵਾਂਗੇ ਕਿ ਅਸੀਂ API ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਏਜੰਟ ਲੂਪਾਂ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ 40% ਤੇਜ਼ ਕਿਵੇਂ ਬਣਾਇਆ, ਜਿਸ ਨਾਲ ਵਰਤੋਂਕਾਰ 65 ਤੋਂ ਲਗਭਗ 1,000 ਟੋਕਨ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੱਕ ਦੀ ਇਨਫਰੈਂਸ ਗਤੀ ਦਾ ਲਾਭ ਮਹਿਸੂਸ ਕਰ ਸਕੇ। ਅਸੀਂ ਇਸ ਲਈ caching, ਗੈਰ-ਜ਼ਰੂਰੀ ਨੈੱਟਵਰਕ hops ਨੂੰ ਹਟਾਉਣ, ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ flag ਕਰਨ ਲਈ ਆਪਣੀ safety stack ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ, synchronous API calls ਦੀ ਲੜੀ ਕਰਨ ਦੀ ਬਜਾਏ Responses API ਨਾਲ persistent connection ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ 'ਤੇ ਕੰਮ ਕੀਤਾ.

Responses API ਵਿੱਚ, GPT‑5 ਅਤੇ GPT‑5.2 ਵਰਗੇ ਪਿਛਲੇ ਫਲੈਗਸ਼ਿਪ ਮਾਡਲ ਲਗਭਗ 65 ਟੋਕਨ ਪ੍ਰਤੀ ਸਕਿੰਟ (TPS) 'ਤੇ ਚਲਦੇ ਸਨ। ਤੇਜ਼ coding ਮਾਡਲ GPT‑5.3‑Codex‑Spark ਦੇ launch ਲਈ, ਸਾਡਾ ਲੱਖਿਆ ਇਸ ਤੋਂ ਦੱਸ ਗੁਣਾ ਤੇਜ਼ ਸੀ: 1,000 TPS ਤੋਂ ਵੱਧ, ਜੋ LLM ਇਨਫਰੈਂਸ ਲਈ optimized ਖਾਸ Cerebras hardware ਨਾਲ ਸੰਭਵ ਹੋਇਆ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਵਰਤੋਂਕਾਰ ਇਸ ਨਵੇਂ ਮਾਡਲ ਦੀ ਅਸਲੀ ਗਤੀ ਮਹਿਸੂਸ ਕਰ ਸਕਣ, ਸਾਨੂੰ API ਓਵਰਹੈੱਡ ਘਟਾਉਣਾ ਪਿਆ.

ਲਗਭਗ ਨਵੰਬਰ 2025 ਵਿੱਚ, ਅਸੀਂ Responses API 'ਤੇ ਇੱਕ performance sprint ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਇਕੱਲੀ ਬੇਨਤੀ ਲਈ critical-path latency 'ਤੇ ਕਈ optimizations ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ:

• multi-turn responses ਲਈ ਮਹਿੰਗੀ ਟੋਕਨਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਨੈੱਟਵਰਕ calls ਨੂੰ ਛੱਡਣ ਵਾਸਤੇ rendered tokens ਅਤੇ ਮਾਡਲ configuration ਨੂੰ memory ਵਿੱਚ cache ਕਰਨਾ
• ਵਿਚਕਾਰਲੀ ਸੇਵਾਵਾਂ ਨੂੰ calls ਹਟਾ ਕੇ (ਉਦਾਹਰਨ ਲਈ, image processing resolution) ਅਤੇ ਸਿੱਧਾ inference service ਨੂੰ call ਕਰ ਕੇ network hop latency ਘਟਾਉਣਾ
• ਆਪਣੀ safety stack ਨੂੰ ਸੁਧਾਰਨਾ ਤਾਂ ਜੋ ਅਸੀਂ ਗੱਲਬਾਤਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ flag ਕਰਨ ਲਈ ਕੁਝ classifiers ਚਲਾ ਸਕੀਏ

ਇਨ੍ਹਾਂ ਸੁਧਾਰਾਂ ਨਾਲ, ਸਾਨੂੰ time to first token (TTFT) ਵਿੱਚ ਲਗਭਗ 45% ਸੁਧਾਰ ਦਿੱਸਿਆ—ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ API ਕਿੰਨੀ responsive ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ—ਪਰ ਇਹ ਸੁਧਾਰ ਵੀ GPT‑5.3‑Codex‑Spark ਲਈ ਕਾਫੀ ਤੇਜ਼ ਨਹੀਂ ਸਨ। ਇਨ੍ਹਾਂ ਸੁਧਾਰਾਂ ਦੇ ਬਾਵਜੂਦ, Responses API ਦਾ ਓਵਰਹੈੱਡ ਮਾਡਲ ਦੀ ਗਤੀ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਵੱਡਾ ਸੀ—ਅਰਥਾਤ, ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਮਾਡਲ ਨੂੰ serve ਕਰਨ ਵਾਲੇ GPUs ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਡੇ API ਚਲਾਉਣ ਵਾਲੇ CPUs ਦੀ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਸੀ.

ਅਸਲ ਸਮੱਸਿਆ ਢਾਂਚਾਗਤ ਸੀ: ਅਸੀਂ ਹਰ Codex ਬੇਨਤੀ ਨੂੰ ਸੁਤੰਤਰ ਮੰਨਦੇ ਸੀ, ਅਤੇ ਹਰ follow-up ਬੇਨਤੀ ਵਿੱਚ conversation state ਅਤੇ ਹੋਰ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ context ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਸੀ। ਭਾਵੇਂ ਗੱਲਬਾਤ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਨਹੀਂ ਬਦਲਿਆ ਹੁੰਦਾ ਸੀ, ਫਿਰ ਵੀ ਅਸੀਂ ਪੂਰੇ history ਨਾਲ ਜੁੜੇ ਕੰਮ ਦੀ ਕੀਮਤ ਭਰਦੇ ਰਹਿੰਦੇ ਸੀ। ਜਿਵੇਂ-ਜਿਵੇਂ ਗੱਲਬਾਤਾਂ ਲੰਬੀਆਂ ਹੁੰਦੀਆਂ ਗਈਆਂ, ਇਹ ਦੁਹਰਾਈ ਹੋਈ ਪ੍ਰੋਸੈਸਿੰਗ ਹੋਰ ਮਹਿੰਗੀ ਬਣਦੀ ਗਈ.

ਡਿਜ਼ਾਇਨ ਨੂੰ ਹੋਰ ਸਖ਼ਤ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ transport protocol ਬਾਰੇ ਮੁੜ ਸੋਚਿਆ: ਕੀ ਅਸੀਂ persistent connection ਅਤੇ cache ਕੀਤੀ state ਰੱਖ ਸਕਦੇ ਸੀ, ਬਜਾਏ ਇਸਦੇ ਕਿ HTTP ਉੱਤੇ ਹਰ follow-up ਬੇਨਤੀ ਲਈ ਨਵੀਂ connection ਬਣਾਈਏ ਅਤੇ ਪੂਰੀ conversation history ਭੇਜੀਏ? ਵਿਚਾਰ ਇਹ ਸੀ ਕਿ ਸਿਰਫ਼ ਉਹੀ ਨਵੀਂ ਜਾਣਕਾਰੀ ਭੇਜੀ ਜਾਵੇ ਜਿਸਨੂੰ validation ਅਤੇ processing ਦੀ ਲੋੜ ਹੋਵੇ ਅਤੇ connection ਦੀ ਮਿਆਦ ਦੌਰਾਨ memory ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਣ ਵਾਲੀ state ਨੂੰ cache ਕੀਤਾ ਜਾਵੇ। ਇਸ ਨਾਲ ਦੁਹਰਾਏ ਕੰਮ ਤੋਂ ਹੋਣ ਵਾਲਾ ਓਵਰਹੈੱਡ ਘੱਟ ਹੋਵੇਗਾ.

ਅਸੀਂ ਕੁਝ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਸੋਚੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ WebSockets ਅਤੇ gRPC bidirectional streaming ਸ਼ਾਮਲ ਸਨ। ਅਸੀਂ WebSockets 'ਤੇ ਟਿਕੇ ਕਿਉਂਕਿ ਇੱਕ ਸਧਾਰਨ message transport protocol ਹੋਣ ਕਰਕੇ, ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਆਪਣੇ Responses API ਦੇ input ਅਤੇ output shapes ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਸੀ। ਇਹ developer-friendly ਸੀ ਅਤੇ ਘੱਟ ਵਿਘਨ ਨਾਲ ਸਾਡੀ ਮੌਜੂਦਾ architecture ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਸੀ.

ਪਹਿਲੇ WebSocket prototype ਨੇ ਇਹ ਬਦਲ ਦਿੱਤਾ ਕਿ ਅਸੀਂ Responses API latency ਬਾਰੇ ਕੀ ਸੰਭਵ ਸਮਝਦੇ ਸੀ। Codex ਟੀਮ ਦਾ ਇੱਕ engineer, ਜਿਸਨੂੰ API stack ਭਰ ਵਿੱਚ ਡੂੰਘੀ ਮਹਾਰਤ ਸੀ, ਨੇ ਇੱਕ Codex ਏਜੰਟ ਰਾਤੋਂ-ਰਾਤ ਚਲਾ ਕੇ prototype ਤਿਆਰ ਕਰ ਲਿਆ.

ਉਸ prototype ਵਿੱਚ, ਏਜੰਟਿਕ rollouts ਨੂੰ ਇੱਕ ਇਕੱਲੇ long-running Response ਵਜੋਂ ਮਾਡਲ ਕੀਤਾ ਗਿਆ ਸੀ। asyncio ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਜਦੋਂ ਕੋਈ tool call sample ਹੁੰਦੀ ਸੀ ਤਾਂ Responses API sampling loop ਵਿੱਚ asynchronously block ਕਰ ਜਾਂਦੀ ਸੀ, ਅਤੇ Responses API ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ response.done event ਭੇਜਦੀ ਸੀ। tool call ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ, ਕਲਾਇੰਟ response.append event ਨਾਲ tool result ਵਾਪਸ ਭੇਜਦੇ ਸਨ, ਜਿਸ ਨਾਲ sampling loop unblock ਹੋ ਜਾਂਦੀ ਸੀ ਅਤੇ ਮਾਡਲ ਅੱਗੇ ਜਾਰੀ ਰਹਿੰਦਾ ਸੀ.

ਇੱਥੇ ਇੱਕ ਉਪਮਾ ਇਹ ਹੈ ਕਿ local tool call ਨੂੰ hosted tool call ਵਾਂਗ ਲਿਆ ਜਾਵੇ। ਜਦੋਂ ਮਾਡਲ web search ਨੂੰ call ਕਰਦਾ ਹੈ, inference loop block ਹੁੰਦੀ ਹੈ, web search service ਨੂੰ call ਕਰਦੀ ਹੈ, ਅਤੇ service response ਨੂੰ ਮਾਡਲ context ਵਿੱਚ ਰੱਖਦੀ ਹੈ। ਸਾਡੇ ਡਿਜ਼ਾਇਨ ਵਿੱਚ, ਅਸੀਂ ਵੀ ਇਹੀ ਕੀਤਾ; ਪਰ remote service ਨੂੰ call ਕਰਨ ਦੀ ਥਾਂ, ਅਸੀਂ ਮਾਡਲ ਦੀ tool call ਨੂੰ WebSocket ਰਾਹੀਂ ਮੁੜ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜ ਦਿੱਤਾ। ਜਦੋਂ ਕਲਾਇੰਟ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਅਸੀਂ ਕਲਾਇੰਟ ਦੀ tool call response ਨੂੰ context ਵਿੱਚ ਰੱਖਿਆ ਅਤੇ sampling ਜਾਰੀ ਰੱਖੀ.

ਇਹ ਡਿਜ਼ਾਇਨ ਬੇਹੱਦ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਇੱਕ ਏਜੰਟ ਰੋਲਆਉਟ ਦੌਰਾਨ ਦੁਹਰਾਏ API ਕੰਮ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ। ਅਸੀਂ preinference ਕੰਮ ਇੱਕ ਵਾਰ ਕਰ ਸਕਦੇ ਸੀ, tool execution ਲਈ pause ਕਰ ਸਕਦੇ ਸੀ, ਅਤੇ ਅੰਤ ਵਿੱਚ postinference ਕੰਮ ਇੱਕ ਵਾਰ ਕਰ ਸਕਦੇ ਸੀ.

ਦੁਰਭਾਗਵਸ਼, ਇਸ ਦੀ ਕੀਮਤ ਇੱਕ ਘੱਟ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਅਤੇ ਹੋਰ ਜਟਿਲ API ਰੂਪ ਵਿੱਚ ਚੁਕਾਉਣੀ ਪਈ। ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ developers ਨਵੇਂ interaction mode ਦੇ ਆਲੇ-ਦੁਆਲੇ ਆਪਣੀ API integration ਮੁੜ ਲਿਖਣ ਬਿਨਾਂ ਹੀ WebSocket support ਜੋੜ ਸਕਣ.

ਜੋ ਵਰਜਨ ਅਸੀਂ launch ਕੀਤਾ, ਉਸ ਲਈ ਅਸੀਂ ਮੁੜ ਜਾਣ-ਪਛਾਣ ਵਾਲੇ ਰੂਪ 'ਤੇ ਆ ਗਏ: ਉਹੀ body ਨਾਲ response.create ਵਰਤਦੇ ਰਹੋ, ਅਤੇ ਪਿਛਲੇ response ਦੀ state ਤੋਂ conversation context ਜਾਰੀ ਰੱਖਣ ਲਈ previous_response_id ਵਰਤੋ.

WebSocket connection 'ਤੇ, server ਪਿਛਲੀ response state ਦੀ connection-scoped, in-memory cache ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ follow-up response.create ਵਿੱਚ previous_response_id ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਅਸੀਂ ਪੂਰੀ conversation ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਮੁੜ ਬਣਾਉਣ ਦੀ ਥਾਂ ਉਹ state cache ਤੋਂ ਲੈ ਲੈਂਦੇ ਹਾਂ.

ਉਸ cache ਕੀਤੀ state ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:

• ਪਿਛਲਾ response object
• ਪਿਛਲੇ input ਅਤੇ output items
• Tool definitions ਅਤੇ namespaces
• ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਣ ਵਾਲੇ sampling artifacts, ਜਿਵੇਂ ਪਹਿਲਾਂ ਤੋਂ rendered tokens

memory ਵਿੱਚ ਮੌਜੂਦ ਪਿਛਲੀ response state ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਕੇ, ਅਸੀਂ ਕਈ ਵੱਡੀਆਂ optimizations ਲਾਗੂ ਕਰ ਸਕੇ:

• ਆਪਣੇ ਕੁਝ safety classifiers ਅਤੇ request validators ਨੂੰ ਹਰ ਵਾਰ ਪੂਰੀ history ਦੀ ਥਾਂ ਸਿਰਫ਼ ਨਵਾਂ input ਪ੍ਰੋਸੈਸ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ
• rendered tokens ਦੀ ਇੱਕ in-memory cache ਰੱਖਣਾ, ਜਿਸ ਵਿੱਚ ਅਸੀਂ append ਕਰਦੇ ਰਹੀਏ ਤਾਂ ਜੋ ਗੈਰ-ਜ਼ਰੂਰੀ ਟੋਕਨਾਈਜ਼ੇਸ਼ਨ ਛੱਡ ਸਕੀਏ
• ਬੇਨਤੀਆਂ ਵਿੱਚ ਆਪਣੇ ਸਫਲ model resolution/routing logic ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਾ
• billing ਵਰਗੇ non-blocking postinference ਕੰਮ ਨੂੰ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ overlap ਕਰਨਾ

ਲੱਖਿਆ ਇਹ ਸੀ ਕਿ developers ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣੀ API ਰੂਪ-ਰੇਖਾ ਨੂੰ ਕਾਇਮ ਰੱਖਦੇ ਹੋਏ, ਘੱਟ ਤੋਂ ਘੱਟ ਓਵਰਹੈੱਡ ਵਾਲੇ prototype ਦੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਉਨ੍ਹਾਂ ਨੇੜੇ ਪਹੁੰਚਿਆ ਜਾਵੇ.

WebSocket mode ਬਣਾਉਣ ਲਈ ਦੋ ਮਹੀਨੇ ਦੀ sprint ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਮੁੱਖ coding agent startups ਨਾਲ ਇੱਕ alpha launch ਕੀਤਾ ਤਾਂ ਜੋ ਉਹ ਇਸਨੂੰ ਆਪਣੇ infrastructure ਵਿੱਚ integrate ਕਰ ਸਕਣ ਅਤੇ traffic ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਧਾ ਸਕਣ। Alpha ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਇਹ ਬਹੁਤ ਪਸੰਦ ਆਇਆ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਆਪਣੀਆਂ ਏਜੰਟਿਕ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ 40% ਤੱਕ ਸੁਧਾਰ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਸਕਾਰਾਤਮਕ alpha feedback ਦੇ ਮੱਦੇਨਜ਼ਰ, ਅਸੀਂ launch ਲਈ ਤਿਆਰ ਸੀ.

Launch ਦੇ ਨਤੀਜੇ ਤੁਰੰਤ ਸਾਹਮਣੇ ਆਏ। Codex ਨੇ ਤੇਜ਼ੀ ਨਾਲ ਆਪਣੀ Responses API traffic ਦਾ ਵੱਡਾ ਹਿੱਸਾ WebSocket mode 'ਤੇ ਲਿਆਇਆ ਅਤੇ ਮਹੱਤਵਪੂਰਨ latency ਸੁਧਾਰ ਵੇਖੇ। GPT‑5.3‑Codex‑Spark ਲਈ, ਅਸੀਂ ਆਪਣਾ 1,000 TPS ਦਾ target ਹਾਸਲ ਕੀਤਾ ਅਤੇ 4,000 TPS ਤੱਕ ਦੇ bursts ਵੇਖੇ, ਜਿਸ ਨਾਲ ਇਹ ਸਾਬਤ ਹੋਇਆ ਕਿ Responses API ਅਸਲੀ production traffic ਵਿੱਚ ਕਾਫੀ ਤੇਜ਼ inference ਨਾਲ ਕਦਮ ਮਿਲਾ ਸਕਦੀ ਹੈ। ਇਸਦਾ ਅਸਰ developer community ਵਿੱਚ ਵੀ ਜਲਦੀ ਦਿੱਸਿਆ:

• Codex ਨੇ ਤੇਜ਼ੀ ਨਾਲ ਆਪਣੀ ਵੱਧਤਰ traffic ਨੂੰ WebSockets 'ਤੇ ਲਿਆਇਆ। GPT‑5.3‑Codex⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), GPT‑5.4⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), ਅਤੇ ਇਸ ਤੋਂ ਅੱਗੇ ਦੇ ਤਾਜ਼ਾ ਮਾਡਲ ਚਲਾਉਣ ਵਾਲੇ Codex ਵਰਤੋਂਕਾਰ ਸਭ WebSocket mode ਦੀ ਗਤੀ-ਵਾਧੇ ਦਾ ਲਾਭ ਲੈਂਦੇ ਹਨ.
• Vercel ਨੇ WebSocket mode ਨੂੰ AI SDK ਵਿੱਚ integrate ਕੀਤਾ ਅਤੇ latency ਵਿੱਚ 40% ਤੱਕ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੀ ਕਮੀ ਵੇਖੀ.
• Cline ਦੇ multi-file workflows 39% ਤੇਜ਼⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹਨ.
• Cursor ਵਿੱਚ OpenAI ਮਾਡਲ 30% ਤੱਕ ਤੇਜ਼⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੋ ਗਏ.

ਮਾਰਚ 2025 ਵਿੱਚ launch ਤੋਂ ਬਾਅਦ Responses API ਵਿੱਚ WebSocket mode ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਨਵੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। OpenAI ਦੀ API ਅਤੇ Codex ਟੀਮਾਂ ਦੇ ਘਣਿਸ਼ਟ ਸਹਿਯੋਗ ਨਾਲ ਅਸੀਂ ਸਿਰਫ਼ ਕੁਝ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਵਿਚਾਰ ਤੋਂ production ਤੱਕ ਪਹੁੰਚ ਗਏ। ਇਹ ਨਾ ਸਿਰਫ਼ ਏਜੰਟ ਰੋਲਆਉਟ latency ਨੂੰ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਸੁਧਾਰਦਾ ਹੈ, ਸਗੋਂ builders ਦੀ ਇੱਕ ਵਧਦੀ ਲੋੜ ਨੂੰ ਵੀ ਪੂਰਾ ਕਰਦਾ ਹੈ: ਜਿਵੇਂ ਮਾਡਲ ਇਨਫਰੈਂਸ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਇਨਫਰੈਂਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਵੀ ਇਹ ਲਾਭ ਵਰਤੋਂਕਾਰਾਂ ਤੱਕ ਪਹੁੰਚਾਉਣ ਲਈ ਤੇਜ਼ ਹੋਣਾ ਪੈਂਦਾ ਹੈ.