Responses API ನಲ್ಲಿ WebSockets ಮೂಲಕ ಏಜೆಂಟ್ ಆಧಾರಿತ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ವೇಗಗೊಳಿಸುವುದು

ನೀವು Codex ಗೆ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲು ಕೇಳಿದಾಗ, ಅದು ಸಂಬಂಧಿತ ಫೈಲ್‌ಗಳಿಗಾಗಿ ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ, ಸಂದರ್ಭವನ್ನು ನಿರ್ಮಿಸಲು ಅವುಗಳನ್ನು ಓದುತ್ತದೆ, ತಿದ್ದುಪಡಿಗಳನ್ನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಬಗೆಹರಿಸುವಿಕೆ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಲು ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ. ಆಂತರಿಕವಾಗಿ, ಇದರ ಅರ್ಥ ಡಜನ್‌ಗಟ್ಟಲೆ ಹಿಂದೆ-ಮುಂದೆ Responses API ವಿನಂತಿಗಳು ನಡೆಯುತ್ತವೆ: ಮಾಡೆಲ್‌ನ ಮುಂದಿನ ಕ್ರಿಯೆಯನ್ನು ನಿರ್ಧರಿಸುವುದು, ನಿಮ್ಮ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಒಂದು ಉಪಕರಣವನ್ನು ಚಾಲನೆ ಮಾಡುವುದು, ಉಪಕರಣದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮತ್ತೆ API ಗೆ ಕಳುಹಿಸುವುದು, ಮತ್ತು ಇದನ್ನು ಪುನರಾವರ್ತಿಸುವುದು.

ಈ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಒಟ್ಟುಗೂಡಿ, Codex ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಬಳಕೆದಾರರು ಕಾಯುವ ಸಮಯ ಕೇವಲ ನಿಮಿಷಗಳಲ್ಲಿರುತ್ತದೆ. ವಿಳಂಬದ ದೃಷ್ಟಿಯಿಂದ ನೋಡಿದರೆ, Codex ಏಜೆಂಟ್ ಲೂಪ್ ತನ್ನ ಹೆಚ್ಚಿನ ಸಮಯವನ್ನು ಮೂರು ಮುಖ್ಯ ಹಂತಗಳಲ್ಲಿ ಕಳೆಯುತ್ತದೆ: API ಸೇವೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು (ವಿನಂತಿಗಳನ್ನು ಮಾನ್ಯಗೊಳಿಸಲು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು), ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ (ಪರಾಮರ್ಶೆ), ಮತ್ತು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸಮಯ (ಉಪಕರಣಗಳನ್ನು ಚಾಲನೆ ಮಾಡುವುದು ಮತ್ತು ಮಾಡೆಲ್ ಸಂದರ್ಭವನ್ನು ನಿರ್ಮಿಸುವುದು). ಇನ್ಫರೆನ್ಸ್ ಎನ್ನುವುದು ಹೊಸ ಟೋಕನ್‌ಗಳನ್ನು ರಚಿಸಲು ಮಾಡೆಲ್ GPU ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಹಂತವಾಗಿದೆ. ಹಿಂದೆ, GPU ಗಳಲ್ಲಿ LLM ಇನ್ಫರೆನ್ಸ್ ಅನ್ನು ನಡೆಸುವುದು ಏಜೆಂಟಿಕ್ ಲೂಪ್‌ನ ಅತ್ಯಂತ ನಿಧಾನವಾದ ಭಾಗವಾಗಿತ್ತು, ಆದ್ದರಿಂದ API ಸೇವೆಯ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಮರೆಮಾಡುವುದು ಸುಲಭವಾಗಿತ್ತು. ಇನ್‌ಫರೆನ್ಸ್ ವೇಗವಾಗುತ್ತಿದ್ದಂತೆ, ಏಜೆಂಟಿಕ್ ರೋಲ್‌ಔಟ್‌ನಿಂದ ಉಂಟಾಗುವ ಸಂಚಿತ API ಓವರ್‌ಹೆಡ್ ಹೆಚ್ಚು ಗಮನಾರ್ಹವಾಗುತ್ತದೆ.

ಈ ಪೋಸ್ಟ್‌ನಲ್ಲಿ, API ಬಳಸಿ ನಾವು ಹೇಗೆ ಏಜೆಂಟ್ ಲೂಪ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ 40% ಹೆಚ್ಚು ವೇಗವಾಗುವಂತೆ ಮಾಡಿದ್ದೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತೇವೆ, ಇದರಿಂದ ಬಳಕೆದಾರರು ಇನ್‌ಫರೆನ್ಸ್ ವೇಗವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 65 ಟೋಕನ್‌ಗಳಿಂದ ಸುಮಾರು 1,000 ಟೋಕನ್‌ಗಳವರೆಗೆ ಏರಿದ ಅನುಭವವನ್ನು ಪಡೆಯುತ್ತಾರೆ. ನಾವು ಇದನ್ನು ಕ್ಯಾಶಿಂಗ್ ಮೂಲಕ, ಅನಗತ್ಯ ನೆಟ್‌ವರ್ಕ್ ಹಾಪ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ, ಸಮಸ್ಯೆಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಗುರುತಿಸಲು ನಮ್ಮ ಸುರಕ್ಷತಾ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸುಧಾರಿಸುವ ಮೂಲಕ, ಮತ್ತು—ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿ—ಸಿಂಕ್ರೋನಸ್ API ಕರೆಗಳ ಸರಣಿಯನ್ನು ಮಾಡಬೇಕಾಗುವ ಬದಲು Responses API ಗೆ ಶಾಶ್ವತ ಸಂಪರ್ಕವನ್ನು ರಚಿಸುವ ವಿಧಾನವನ್ನು ನಿರ್ಮಿಸುವ ಮೂಲಕ ಸಾಧಿಸಿದ್ದೇವೆ.

Responses API ನಲ್ಲಿ, GPT‑5 ಮತ್ತು GPT‑5.2 ಮುಂತಾದ ಹಿಂದಿನ ಫ್ಲಾಗ್‌ಶಿಪ್ ಮಾದರಿಗಳು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 65 ಟೋಕನ್‌ಗಳ (TPS) ವೇಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದವು. GPT‑5.3‑Codex‑Spark ಎಂಬ ವೇಗವಾದ ಕೋಡಿಂಗ್ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಗಾಗಿ, ನಮ್ಮ ಗುರಿ ಹತ್ತು ಪಟ್ಟು ಹೆಚ್ಚು ವೇಗ ಸಾಧಿಸುವುದಾಗಿತ್ತು: 1,000 ಕ್ಕೂ ಹೆಚ್ಚು TPS, ಇದು LLM ಇನ್‌ಫರೆನ್ಸ್‌ಗೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾದ ವಿಶೇಷ Cerebras ಹಾರ್ಡ್‌ವೇರ್‌ನಿಂದ ಸಾಧ್ಯವಾಯಿತು. ಬಳಕೆದಾರರು ಈ ಹೊಸ ಮಾಡೆಲ್‌ನ ನಿಜವಾದ ವೇಗವನ್ನು ಅನುಭವಿಸಬಹುದೆಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು API ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕಾಯಿತು. 

2025 ರ 11 ನೇ ತಿಂಗಳ (ನವೆಂಬರ್) ಸುಮಾರಿಗೆ, ನಾವು Responses API ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಸ್ಪ್ರಿಂಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಒಂದೇ ವಿನಂತಿಗಾಗಿ ಕ್ರಿಟಿಕಲ್-ಪಾತ್ ಲೇಟೆನ್ಸಿಗೆ ಹಲವು ಆಪ್ಟಿಮೈಜೇಶನ್‌ಗಳನ್ನು ಜಾರಿಗೆ ತಂದೆವು: 

• ಬಹು-ಟರ್ನ್ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗಾಗಿ ವೆಚ್ಚಬರುವ ಟೋಕನೈಜೇಶನ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳನ್ನು ತಪ್ಪಿಸಲು ರೆಂಡರ್ ಮಾಡಿದ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಮಾಡೆಲ್ ಸಂರಚನೆಯನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಕ್ಯಾಶ್ ಮಾಡುವುದು
• ಮಧ್ಯವರ್ತಿ ಸೇವೆಗಳಿಗೆ ಮಾಡುವ ಕರೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿ (ಉದಾಹರಣೆಗೆ, ಇಮೇಜ್ ಪ್ರೊಸೆಸಿಂಗ್ ರೆಸಲ್ಯೂಶನ್), ಇನ್‌ಫರೆನ್ಸ್ ಸೇವೆಯನ್ನು ನೇರವಾಗಿ ಕರೆಮಾಡುವ ಮೂಲಕ ನೆಟ್‌ವರ್ಕ್ ಹಾಪ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು
• ನಿರ್ದಿಷ್ಟ ಕ್ಲಾಸಿಫೈಯರ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ ಸಂಭಾಷಣೆಗಳನ್ನು ವೇಗವಾಗಿ ಫ್ಲ್ಯಾಗ್ ಮಾಡಲು ನಮ್ಮ ಸುರಕ್ಷತಾ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಸುಧಾರಿಸುವುದು

ಈ ಸುಧಾರಣೆಗಳೊಂದಿಗೆ, ಮೊದಲ ಟೋಕನ್‌ಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯದಲ್ಲಿ (TTFT) ನಾವು ಸುಮಾರು 45% ಸುಧಾರಣೆಯನ್ನು ಕಂಡೆವು—ಇದು API ಎಷ್ಟು ಸ್ಪಂದನಶೀಲವಾಗಿದೆ ಎಂಬುದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ—ಆದರೆ ಈ ಸುಧಾರಣೆಗಳು ಇನ್ನೂ GPT‑5.3‑Codex‑Spark ಗಾಗಿ ಸಾಕಷ್ಟು ವೇಗವಾಗಿರಲಿಲ್ಲ. ಈ ಸುಧಾರಣೆಗಳಿದ್ದರೂ ಸಹ, ಮಾಡೆಲ್‌ನ ವೇಗಕ್ಕೆ ಹೋಲಿಸಿದರೆ Responses API ಓವರ್‌ಹೆಡ್ ತುಂಬಾ ಹೆಚ್ಚಾಗಿತ್ತು—ಅಂದರೆ, ಬಳಕೆದಾರರು ಮಾಡೆಲ್‌ಗೆ ಸೇವೆ ನೀಡುವ GPU ಗಳನ್ನು ಬಳಸುವ ಮೊದಲು ನಮ್ಮ API ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿರುವ CPU ಗಳಿಗಾಗಿ ಕಾಯಬೇಕಾಗುತ್ತಿತ್ತು.

ಆಳವಾದ ಸಮಸ್ಯೆ ರಚನಾತ್ಮಕವಾಗಿತ್ತು: ನಾವು ಪ್ರತಿ Codex ವಿನಂತಿಯನ್ನು ಸ್ವತಂತ್ರವೆಂದು ಪರಿಗಣಿಸಿದ್ದೆವು; ಹೀಗಾಗಿ ಪ್ರತಿ ಮುಂದುವರಿದ ವಿನಂತಿಯಲ್ಲಿ ಸಂಭಾಷಣೆಯ ಸ್ಥಿತಿ ಹಾಗೂ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಇತರ ಸಂದರ್ಭ ಮಾಹಿತಿಯನ್ನು ಮತ್ತೆ ಸಂಸ್ಕರಿಸುತ್ತಿದ್ದೆವು. ಸಂಭಾಷಣೆಯ ಬಹುಭಾಗ ಬದಲಾಗಿರದಿದ್ದರೂ ಸಹ, ಪೂರ್ಣ ಚಾಟ್ ಇತಿಹಾಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಕೆಲಸಕ್ಕೆ ನಾವು ಇನ್ನೂ ವೆಚ್ಚ ಮಾಡುತ್ತಿದ್ದೆವು. ಸಂಭಾಷಣೆಗಳು ದೀರ್ಘವಾಗುತ್ತಿದ್ದಂತೆ, ಆ ಪುನರಾವರ್ತಿತ ಸಂಸ್ಕರಣೆ ಇನ್ನಷ್ಟು ವೆಚ್ಚದಾಯಕವಾಯಿತು.

ವಿನ್ಯಾಸವನ್ನು ಇನ್ನಷ್ಟು ಸುವ್ಯವಸ್ಥಿತಗೊಳಿಸಲು, ನಾವು ಟ್ರಾನ್ಸ್‌ಪೋರ್ಟ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮರುಚಿಂತನೆ ಮಾಡಿದೆವು: HTTP ಮೂಲಕ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿ ಪ್ರತಿ ಮುಂದುವರಿದ ವಿನಂತಿಗೆ ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆ ಇತಿಹಾಸವನ್ನು ಕಳುಹಿಸುವ ಬದಲು, ನಾವು ನಿರಂತರ ಸಂಪರ್ಕ ಮತ್ತು ಕ್ಯಾಶ್ ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದೇ? ಮೌಲ್ಯೀಕರಣ ಮತ್ತು ಸಂಸ್ಕರಣೆ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಹೊಸ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ, ಮತ್ತು ಸಂಪರ್ಕದ ಪೂರ್ಣಾವಧಿಯವರೆಗೆ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಸ್ಥಿತಿಯನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಕ್ಯಾಶ್ ಮಾಡುವುದು ಆಲೋಚನೆಯಾಗಿತ್ತು. ಇದು ಅನಗತ್ಯ ಕೆಲಸದಿಂದ ಉಂಟಾಗುವ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ನಾವು WebSockets ಮತ್ತು gRPC bidirectional streaming ಒಳಗೊಂಡಂತೆ ಕೆಲವು ವಿಭಿನ್ನ ವಿಧಾನಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ನಾವು WebSockets ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಂಡೆವು, ಏಕೆಂದರೆ ಇದು ಸರಳ ಸಂದೇಶ ಸಾಗಾಟ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿರುವುದರಿಂದ, ಬಳಕೆದಾರರು ತಮ್ಮ Responses API ಯ ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ರಚನೆಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗುವುದಿಲ್ಲ. ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನುಕೂಲಕರವಾಗಿತ್ತು ಮತ್ತು ಹೆಚ್ಚಿನ ವ್ಯತ್ಯಯವಿಲ್ಲದೆ ನಮ್ಮ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಹೊಂದಿಕೊಂಡಿತು.

ಮೊದಲ WebSocket ಮಾದರಿ ಆವೃತ್ತಿಯು Responses API ವಿಳಂಬದ ಬಗ್ಗೆ ನಾವು ಸಾಧ್ಯವೆಂದು ಭಾವಿಸಿದ್ದುದನ್ನೇ ಬದಲಿಸಿತು. Codex ತಂಡದ ಒಬ್ಬ ಎಂಜಿನಿಯರ್, API ಸ್ಟ್ಯಾಕ್‌ನಾದ್ಯಂತ ಆಳವಾದ ಪರಿಣತಿಯನ್ನು ಹೊಂದಿದ್ದು, ರಾತ್ರಿಯಿಡೀ Codex ಏಜೆಂಟ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವ ಮೂಲಕ ಒಂದು ಪ್ರೋಟೋಟೈಪ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಿದರು.

ಆ ಪ್ರೋಟೋಟೈಪ್‌ನಲ್ಲಿ, ಏಜೆಂಟಿಕ್ ರೋಲ್‌ಔಟ್‌ಗಳನ್ನು ಒಂದೇ ದೀರ್ಘಕಾಲ ನಡೆಯುವ Response ಆಗಿ ಮಾಡೆಲ್ ಮಾಡಲಾಗಿತ್ತು. asyncio ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಿದಾಗ, ಟೂಲ್ ಕರೆ ಸ್ಯಾಂಪಲ್ ಆದ ನಂತರ Responses API ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಲೂಪ್‌ನಲ್ಲಿ ಅಸಮಕಾಲಿಕವಾಗಿ ನಿರ್ಬಂಧಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು Responses API response.done ಈವೆಂಟ್ ಅನ್ನು ಮತ್ತೆ ಗ್ರಾಹಕನಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್‌ಗಳು ಟೂಲ್ ಫಲಿತಾಂಶದೊಂದಿಗೆ response.append ಈವೆಂಟ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸಿ ಕಳುಹಿಸುತ್ತವೆ, ಇದರಿಂದ ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಲೂಪ್‌ನ ಅಡಚಣೆಯನ್ನು ನಿವಾರಿಸಿ ಮಾಡೆಲ್‌ಗೆ ಮುಂದುವರಿಯಲು ಅವಕಾಶ ದೊರೆಯಿತು.

ಇಲ್ಲಿನ ಸಾದೃಶ್ಯ ಎಂದರೆ, ಸ್ಥಳೀಯ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ಹೋಸ್ಟೆಡ್ ಟೂಲ್ ಕಾಲ್‌ನಂತೆ ಪರಿಗಣಿಸುವುದು. ಮಾಡೆಲ್ ವೆಬ್ ಹುಡುಕಾಟವನ್ನು ಕರೆಯುವಾಗ, ಇನ್ಫರೆನ್ಸ್ ಲೂಪ್ ಬ್ಲಾಕ್ ಆಗುತ್ತದೆ, ವೆಬ್ ಹುಡುಕಾಟ ಸೇವೆಯನ್ನು ಕಾಲ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆ ಸೇವೆಯ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮಾಡೆಲ್ ಸಂದರ್ಭಕ್ಕೆ ಸೇರಿಸುತ್ತದೆ. ನಮ್ಮ ವಿನ್ಯಾಸದಲ್ಲೂ ನಾವು ಅದೇ ಕೆಲಸ ಮಾಡಿದೆವು; ಆದರೆ ರಿಮೋಟ್ ಸೇವೆಯನ್ನು ಕಾಲ್ ಮಾಡುವ ಬದಲು, ಮಾಡೆಲ್‌ನ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು WebSocket ಮೂಲಕ ಕ್ಲೈಂಟ್‌ಗೆ ಹಿಂದಿರುಗಿ ಕಳುಹಿಸಿದೆವು. ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದಾಗ, ನಾವು ಕ್ಲೈಂಟ್‌ನ tool call ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಂದರ್ಭಕ್ಕೆ ಸೇರಿಸಿ ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಅನ್ನು ಮುಂದುವರಿಸಿದೆವು.

ಈ ವಿನ್ಯಾಸವು ಏಜೆಂಟ್ ನಿಯೋಜನೆಯಾದ್ಯಂತ ಪುನರಾವರ್ತಿತ API ಕೆಲಸವನ್ನು ನಿವಾರಿಸಿದ್ದರಿಂದ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿತ್ತು. ನಾವು ಪ್ರೀಇನ್‌ಫರೆನ್ಸ್ ಕೆಲಸವನ್ನು ಒಮ್ಮೆ ಮಾಡಬಹುದು, ಟೂಲ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗೆ ವಿರಾಮ ನೀಡಿ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಪೋಸ್ಟ್‌ಇನ್‌ಫರೆನ್ಸ್ ಕೆಲಸವನ್ನು ಒಮ್ಮೆ ಮಾಡಬಹುದು.

ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಕಡಿಮೆ ಪರಿಚಿತ ಮತ್ತು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ API ವೆಚ್ಚದ ಸ್ವರೂಪದಲ್ಲಿ ಬಂದಿತು. ಡೆವಲಪರ್‌ಗಳು ಹೊಸ ಸಂವಹನ ವಿಧಾನಕ್ಕೆ ತಮ್ಮ API ಒಕ್ಕೂಟವನ್ನು ಮರುಬರೆಯಬೇಕಾಗದೆ, WebSocket ಬೆಂಬಲವನ್ನು ಸುಲಭವಾಗಿ ಸೇರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಲಿ ಎಂದು ನಾವು ಬಯಸಿದ್ದೇವೆ.

ನಾವು ಬಿಡುಗಡೆ ಮಾಡಿದ ಆವೃತ್ತಿಗಾಗಿ, ನಾವು ಪರಿಚಿತವಾದ ರೂಪಕ್ಕೆ ಹಿಂತಿರುಗಿದ್ದೇವೆ: ಅದೇ ಬಾಡಿಯೊಂದಿಗೆ response.create ಅನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಿ, ಮತ್ತು ಹಿಂದಿನ ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ಥಿತಿಯಿಂದ ಸಂಭಾಷಣೆಯ ಪ್ರಾಸಂಗಿಕತೆಯನ್ನು ಮುಂದುವರಿಸಲು previous_response_id ಅನ್ನು ಬಳಸಿ.

WebSocket ಸಂಪರ್ಕದಲ್ಲಿ, ಸರ್ವರ್ ಹಿಂದಿನ ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ಥಿತಿಯ ಸಂಪರ್ಕ-ವ್ಯಾಪ್ತಿಯ ಇನ್-ಮೆಮೊರಿ ಕ್ಯಾಶ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಅನುಸರಣೆ response.create ನಲ್ಲಿ previous_response_id ಸೇರಿದ್ದರೆ, ಪೂರ್ಣ ಸಂಭಾಷಣೆಯನ್ನು ಶೂನ್ಯದಿಂದ ಮರುನಿರ್ಮಿಸುವ ಬದಲು ನಾವು ಆ ಸ್ಥಿತಿಯನ್ನು ಕ್ಯಾಶ್‌ನಿಂದ ಪಡೆಯುತ್ತೇವೆ.

ಆ ಕ್ಯಾಶ್ ಮಾಡಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ಇವು ಒಳಗೊಂಡಿವೆ:

• ಹಿಂದಿನ response ಆಬ್ಜೆಕ್ಟ್
• ಹಿಂದಿನ ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಐಟಂಗಳು
• ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳು ಮತ್ತು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು
• ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಮಾದರಿಗಳು, ಹಿಂದೆ ರೆಂಡರ್ ಮಾಡಿದ ಟೋಕನ್‌ಗಳಂತಹವು

ಇನ್-ಮೆಮೊರಿಯಲ್ಲಿರುವ ಹಿಂದಿನ ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ಥಿತಿಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಮೂಲಕ, ನಾವು ಹಲವಾರು ಪ್ರಮುಖ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಯಿತು:

• ನಮ್ಮ ಕೆಲವು ಸುರಕ್ಷತಾ ವರ್ಗೀಕರಣಗಳು ಮತ್ತು ವಿನಂತಿ ಮೌಲ್ಯೀಕರಣಗಳು ಪ್ರತಿ ಬಾರಿ ಸಂಪೂರ್ಣ ಇತಿಹಾಸವನ್ನಲ್ಲ, ಕೇವಲ ಹೊಸ ಇನ್‌ಪುಟ್ ಅನ್ನು ಮಾತ್ರ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಂತೆ ಮಾಡುವುದು
• ಅಗತ್ಯವಿಲ್ಲದ ಟೋಕನೈಜೇಶನ್ ಅನ್ನು ತಪ್ಪಿಸಲು, ನಾವು ಸೇರಿಸುತ್ತಿರುವ ರೆಂಡರ್ ಮಾಡಿದ ಟೋಕನ್‌ಗಳ ಇನ್-ಮೆಮೊರಿ ಕ್ಯಾಶ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ
• ವಿನಂತಿಗಳಾದ್ಯಂತ ನಮ್ಮ ಯಶಸ್ವಿ ಮಾಡೆಲ್ ನಿರ್ಧಾರ/ರೌಟಿಂಗ್ ತರ್ಕವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು 
• ಮುಂದಿನ ವಿನಂತಿಗಳೊಂದಿಗೆ ಬಿಲ್ಲಿಂಗ್‌ನಂತಹ ತಡೆಹಿಡಿಯದ ಇನ್‌ಫರೆನ್ಸ್ ನಂತರದ ಕೆಲಸವನ್ನು ಅತಿಕ್ರಮಿಸುವಂತೆ ನಡೆಸುವುದು

ಗುರಿಯು ಕನಿಷ್ಠ ಓವರ್‌ಹೆಡ್ ಹೊಂದಿರುವ ಪ್ರೋಟೋಟೈಪ್‌ಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಾಗಿರುವುದಾಗಿತ್ತು, ಆದರೆ ಡೆವಲಪರ್‌ಗಳು ಈಗಾಗಲೇ ಅರ್ಥಮಾಡಿಕೊಂಡು ಅದರ ಸುತ್ತ ನಿರ್ಮಿಸಿಕೊಂಡಿದ್ದ API ರೂಪವನ್ನು ಹೊಂದಿರಬೇಕಾಗಿತ್ತು.

WebSocket ಮೋಡ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಎರಡು ತಿಂಗಳ ಸ್ಪ್ರಿಂಟ್ ನಂತರ, ನಾವು ಪ್ರಮುಖ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಿಗೆ ತಮ್ಮ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್‌ಗೆ ಏಕೀಕರಿಸಲು ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಿಸಲು ಅನುಮತಿಸುವ ಆಲ್ಫಾ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆವು. ಆಲ್ಫಾ ಬಳಕೆದಾರರು ಇದನ್ನು ಬಹಳ ಮೆಚ್ಚಿದರು ಮತ್ತು ತಮ್ಮ ಏಜೆಂಟ್ ವರ್ಕ್‌ಫ್ಲೋಗಳಲ್ಲಿ 40% ವರೆಗೆ ಸುಧಾರಣೆಗಳನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ವರದಿ ಮಾಡಿದರು. ಸಕಾರಾತ್ಮಕ ಆಲ್ಫಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಗಮನಿಸಿದರೆ, ನಾವು ಬಿಡುಗಡೆ ಮಾಡಲು ಸಿದ್ಧರಾಗಿದ್ದೇವೆ.

ಪ್ರಾರಂಭದ ಫಲಿತಾಂಶಗಳು ತಕ್ಷಣವೇ ಕಂಡುಬಂದವು. Codex ತಮ್ಮ Responses API ಟ್ರಾಫಿಕ್‌ನ ಬಹುಪಾಲನ್ನು WebSocket ಮೋಡ್‌ಗೆ ತ್ವರಿತವಾಗಿ ಸ್ಥಳಾಂತರಿಸಿತು, ಇದರಿಂದ ಲೇಟೆನ್ಸಿಯಲ್ಲಿ ಗಮನಾರ್ಹ ಸುಧಾರಣೆಗಳನ್ನು ಕಂಡಿತು. GPT‑5.3‑Codex‑Spark ಗಾಗಿ, ನಾವು ನಮ್ಮ 1,000 TPS ಗುರಿಯನ್ನು ತಲುಪಿದೆವು ಮತ್ತು 4,000 TPS ವರೆಗೆ ಏರಿಕೆಯ ಸ್ಫೋಟಗಳನ್ನೂ ಕಂಡೆವು, ಇದರಿಂದ ನೈಜ ಉತ್ಪಾದನಾ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ಇನ್ನಷ್ಟು ವೇಗವಾದ ಇನ್‌ಫರೆನ್ಸ್‌ಗೆ Responses API ಹೊಂದಿಕೊಂಡು ಸಾಗಬಲ್ಲದು ಎಂಬುದು ತೋರಿತು. ಈ ಪರಿಣಾಮವು ಡೆವಲಪರ್ ಸಮುದಾಯದಲ್ಲಿಯೂ ತ್ವರಿತವಾಗಿ ಗೋಚರಿಸಿತು:

• Codex ತಮ್ಮ ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಅನ್ನು WebSockets ಗೆ ಅತ್ಯಂತ ವೇಗವಾಗಿ ವರ್ಗಾಯಿಸಿತು. GPT‑5.3‑Codex⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮುಂತಾದ ಇತ್ತೀಚಿನ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿರುವ Codex ಬಳಕೆದಾರರು, GPT‑5.4⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಮತ್ತು ಅದರಾಚೆಯೂ WebSocket ಮೋಡ್‌ನ ವೇಗವರ್ಧನೆಯಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತವೆ.
• Vercel AI SDKಗೆ WebSocket ಮೋಡ್ ಅನ್ನು ಏಕೀಕರಿಸಿತು ಮತ್ತು ಲೇಟೆನ್ಸಿ 40% ವರೆಗೆ ಕಡಿಮೆಯಾದುದನ್ನು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಗಮನಿಸಿತು.
• Cline ಯ ಬಹು-ಫೈಲ್ ವರ್ಕ್‌ಫ್ಲೋಗಳು 39% ಹೆಚ್ಚು ವೇಗವಾಗಿವೆ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ).
• Cursor ನಲ್ಲಿ OpenAI ಮಾಡೆಲ್‌ಗಳು 30% ವರೆಗೆ ವೇಗವಾದವು⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ).

WebSocket ಮೋಡ್ ಎಂಬುದು Responses API ನಲ್ಲಿ ಮಾರ್ಚ್ 2025 ರಲ್ಲಿ ಪ್ರಾರಂಭವಾದ ನಂತರದಿಂದ ಅತ್ಯಂತ ಮಹತ್ವದ ಹೊಸ ಸಾಮರ್ಥ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. OpenAI ಯ API ಮತ್ತು Codex ತಂಡಗಳ ನಡುವಿನ ನಿಕಟ ಸಹಯೋಗದ ಮೂಲಕ, ನಾವು ಕೇವಲ ಕೆಲವು ವಾರಗಳಲ್ಲಿ ಆಲೋಚನೆಯ ಹಂತದಿಂದ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಹಂತಕ್ಕೆ ತಲುಪಿದ್ದೇವೆ. ಇದು ಏಜೆಂಟ್ ರೋಲೌಟ್ ಲೇಟೆನ್ಸಿಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸುವುದಷ್ಟೇ ಅಲ್ಲ, ಡೆವಲಪರ್‌ಗಳ ಹೆಚ್ಚುತ್ತಿರುವ ಅಗತ್ಯವನ್ನೂ ಬೆಂಬಲಿಸುತ್ತದೆ: ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ ವೇಗವಾಗುತ್ತಿದ್ದಂತೆ, ಈ ಲಾಭಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ತಲುಪಿಸಲು ಇನ್ಫರೆನ್ಸ್ ಅನ್ನು ಸುತ್ತುವರೆದಿರುವ ಸೇವೆಗಳು ಮತ್ತು ವ್ಯವಸ್ಥೆಗಳೂ ಸಹ ವೇಗಗೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.