GPT-5.5 Codex में reasoning token clustering से प्रदर्शन घट सकता है

 (github.com/openai)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenAI Codex issue #30364 रिपोर्ट करता है कि gpt-5.5 responses के reasoning_output_tokens का 516, 1034, 1552 जैसे fixed values पर जमा होना जटिल Codex tasks की quality में गिरावट से जुड़ा हो सकता है
  • विश्लेषण का आधार 1 फरवरी 2026 से 27 जून 2026 UTC तक का Codex token_count metadata है, जिसमें 390,195 response records और 865 sessions में exact 516 events के 3,363 मामले मिले
  • gpt-5.5 कुल responses का 19.3% था, लेकिन exact-516 events का 82.0% इसी से आया; reasoning_output_tokens >= 516 में exact 516 का अनुपात 44.0% था, जो non-GPT-5.5 के 1.3% से कहीं अधिक था
  • monthly exact-516 ratio फरवरी 2026 में 0.11% से बढ़कर मई में 53.30% और जून में 35.84% हो गया, लेकिन इसी अवधि में average और P90 reasoning token count घटे, इसलिए यह सिर्फ reasoning token usage बढ़ने की घटना नहीं थी
  • बाद के comments में Codex CLI, Codex Desktop और OpenCode में मिलती-जुलती 516 clustering और कुछ गलत answers की reproduction साझा की गई; अस्थायी workaround के तौर पर 518·n−2 pattern detect करके reasoning जारी रखने वाला local proxy भी सुझाया गया

issue की मुख्य समस्या

  • Codex issue #30364 gpt-5.5 responses के token_count metadata में reasoning_output_tokens = 516 पर असामान्य रूप से ज्यादा clustering का pattern रिपोर्ट करता है
  • इसके अलावा 1034, 1552 के आसपास भी fixed boundary जैसी spikes दिखने की बात कही गई
  • उठाया गया मुद्दा यह दावा नहीं है कि hidden chain-of-thought truncation साबित हो गया है
    • ज्यादा सीमित दावा यह है कि Codex telemetry में gpt-5.5 के लिए विशिष्ट fixed token clustering anomaly दिखती है
    • यह pattern threshold-based reasoning budget behavior से consistent दिखता है, इस स्तर की समस्या उठाई गई है
  • संबंधित issue #29353 ने ऐसे task-unit reproduction को संभाला था, जिसमें gpt-5.5 run ठीक 516 reasoning tokens पर खत्म होकर गलत answer लौटाता था; यह issue लंबी अवधि का aggregate evidence जोड़ता है

विश्लेषण environment और data

  • product Codex है, और सबसे संबंधित model gpt-5.5 है
  • data source Codex token_count metadata है
  • analysis period 1 फरवरी 2026 से 27 जून 2026 UTC है
  • aggregate numbers:
    • response-level token records: 390,195
    • sessions: 865
    • exact reasoning_output_tokens = 516 events: 3,363
    • कुल responses में gpt-5.5 का share: 19.3%
    • exact-516 events में gpt-5.5 का share: 82.0%
    • gpt-5.5 exact-516 / >=516 ratio: 44.0%
    • non-GPT-5.5 exact-516 / >=516 ratio: 1.3%

model-wise और monthly patterns

  • model-wise exact 516 / >=516 ratio gpt-5.5 में सबसे ज्यादा prominent है
    • gpt-5.5: 75,401 records, 44.0%
    • gpt-5.4: 25,214 records, 19.8%
    • gpt-5.2: 247,575 records, 0.34%
    • gpt-5.3-codex: 13,333 records, 0.0%
    • gpt-5.3-codex-spark: 26,179 records, 0.0%
  • monthly exact-516 clustering मई 2026 में तेजी से बढ़ती है
    • फरवरी: 0.11%
    • मार्च: 2.45%
    • अप्रैल: 4.25%
    • मई: 53.30%
    • जून: 35.84%
  • उसी अवधि में overall reasoning token intensity घटती है
    • average reasoning tokens: फरवरी 268.1 → मई 106.9 → जून 168.5
    • P90 reasoning tokens: फरवरी 772 → मई 344 → जून 515
  • इस combination की वजह से यह सवाल उठता है कि exact-516 की बढ़ोतरी को सिर्फ reasoning token usage बढ़ने से समझाना मुश्किल है

मांगे गए internal verification items

  • Codex team से जांच करने का अनुरोध किया गया कि gpt-5.5 के reasoning budget, routing, truncation, fallback, scheduler behavior क्या 516/1034/1552 के आसपास termination पैदा करते हैं
  • अगर यह behavior intended है, तो exact 516 क्या normal termination point, budget cap, degraded tier, या कोई अन्य internal threshold है, यह बताने का अनुरोध भी शामिल है
  • सुझाई गई verification procedure:
    • model-wise reasoning_output_tokens वाले token_count events query करना
    • 0, 516, 1034, 1552 exact-value counts की तुलना करना
    • model और date के हिसाब से count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) calculate करना
    • gpt-5.5 की gpt-5.2, gpt-5.4, और Codex-specific variants से तुलना करना
    • GPT-5.2 और GPT-5.5 पर complex tasks दोबारा run करना, और exact-516 responses तथा longer reasoning responses को अलग करके quality evaluate करना

comments में आए additional reproduction और cross data

  • GitHub Actions ने related duplicate candidate के रूप में #29353 दिखाया
  • कई users ने comments में बताया कि उन्हें भी यही problem हुई, और एक user ने कहा कि यह issue पिछले issue की तुलना में ज्यादा data-driven report है
  • sinnet3000 ने Codex CLI और OpenCode के local session stores से cross-client data पेश किया
    • Codex ~/.codex/sessions और archived_sessions के करीब 22.7k token_count events में gpt-5.5 के records 4,300, >=516 156, exact 516 88, ratio 56.4%
    • OpenCode opencode.db के करीब 32.1k assistant messages में gpt-5.5 के records 6,977, >=516 126, exact 516 90, ratio 71.4%
    • Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen, GLM आदि volume वाले non-OpenAI models के combined करीब 24k records में exact 516 के 0 मामले
    • इस data के साथ caveat था कि answers के सही-गलत का evaluation नहीं किया गया, सिर्फ exact 516 clustering की मौजूदगी check की गई
  • kyleboddy ने Windows 11 Codex Desktop में related behavior difference रिपोर्ट किया
    • 5 fresh projectless Codex Desktop threads में वही candy prompt run किया
    • तेज direct-final_answer runs ने 29 लौटाया, जो गलत answer था
    • धीमे runs, जिनमें पहले commentary आया, उन्होंने 21 लौटाया, जो सही answer था
    • fresh Windows-host Desktop threads में exact reasoning_output_tokens extract नहीं हो सके, इसलिए यह नहीं कहा जा सकता कि वह wrong-answer run ठीक 516 था
  • उसी user ने local session metadata में gpt-5.5 / xhigh की fixed-value clustering भी aggregate की
    • records 16,141, sessions 51, average reasoning 149.7, P90 429
    • =516 438 cases, >=516 1,298 cases, ratio 33.74%
    • =1034 52 cases, =1552 14 cases, =2070 16 cases, =2588 12 cases, =3106 5 cases

Codex Linux CLI reproduction results

  • kyleboddy ने कहा कि उन्होंने Codex Linux CLI पर भी वही candy prompt इस्तेमाल करके reproduce किया
  • environment:
    • product: Codex CLI
    • version: codex-cli 0.142.5
    • platform: Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node: v24.14.0
    • authentication mode: ChatGPT
    • test model: gpt-5.5
    • reasoning efforts: xhigh, high
    • control model: gpt-5.4 xhigh
  • prompt में external tools का इस्तेमाल न करने और touch से shape अलग कर सकने वाले candy bag problem के minimum draw count के बारे में पूछा गया था
  • expected answer brute-force enumeration से स्वतंत्र रूप से 21 confirm किया गया
    • इसमें यह explanation शामिल थी कि shape को touch से distinguish किया जा सकता है, इसलिए 9 round + 12 star candies की योजना बनाई जा सकती है
  • results:
    • gpt-5.5 xhigh के 4 completed runs सभी में reasoning_output_tokens = 516 था, और final answers 23, 26, 28, 15 थे—सभी गलत
    • gpt-5.5 high के 3 runs भी सभी 516 थे, और answers 22, 21, 27 थे—सिर्फ 1 सही
    • gpt-5.4 xhigh के 3 runs ने 6211, 12274, 10876 reasoning tokens इस्तेमाल किए और सभी ने 21 सही answer दिया
  • यह result इस narrow claim को support करता है कि Codex में gpt-5.5 fixed 516-token path में जा सकता है, और वह path task quality degradation से correlated हो सकता है

अस्थायी workaround का प्रस्ताव

  • dzshzx ने upstream fix का इंतजार करते समय Codex के सामने लगाने के लिए local Responses proxy codexcomp सुझाया
  • इसका working style 518·n−2 pattern को truncation मानकर reasoning जारी रखने का है
    • reasoning_tokens == 518·n − 2, यानी 516, 1034, 1552 आदि पर खत्म हुए round को truncated माना जाता है
    • tentative output को discard करके, उस round के reasoning items और encrypted_content को अगले input में replay किया जाता है
    • phase:"commentary" और "Continue thinking..." message साथ में डाले जाते हैं
    • सभी rounds को एक downstream response में fold करके Codex को complete answer जैसा दिखाया जाता है
  • configuration official top-level openai_base_url key का इस्तेमाल करती है
    • example: openai_base_url = "http://127.0.0.1:8787/v1";
    • कहा गया कि built-in openai provider बरकरार रहता है, इसलिए session grouping, remote compaction, remote-control चलते रहते हैं
  • actual log example में दो लगातार 516 के बाद तीसरे round में clean termination और final answer सही होने का case दिखाया गया
    • round 1: reason=516 → continue
    • round 2: reason=516 → continue
    • round 3: reason=291 → clean
  • caveat:
    • यह unofficial workaround है और upstream के non-contractual behavior पर निर्भर है
    • continuation round अतिरिक्त real tokens इस्तेमाल करता है
    • n window और 3-continuation cap से सीमित है
    • यह loopback-only, auth passthrough है और credentials पढ़ता या store नहीं करता बताया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • यह काफी गंभीर लगता है, और codex cli में भी आसानी से reproduce हो जाता है
    reasoning की जरूरत वाला puzzle prompt देने पर कभी-कभी यह अचानक कट गया हो ऐसा लगता है और ठीक 516 thought tokens ही इस्तेमाल करके गलत जवाब दे देता है
    6000–8000 thought tokens इस्तेमाल करने पर सही जवाब देता है
    यह adaptive thinking से जुड़ी समस्या हो सकती है, और इस मायने में local models को एक और वोट जाता है कि उन्हें चुपचाप होने वाले server-side बदलावों की चिंता नहीं करनी पड़ती
    वही prompt 10 बार चलाया तो 4 बार यह 516-token वाली समस्या आई, और उन चारों में जवाब गलत था। sample छोटा है, लेकिन लगता है कि 5.5 xhigh करीब आधी संभावना में short-circuit होकर performance गिरा सकता है

    • adaptive thinking में मुझे दार्शनिक तौर पर भी समस्या दिखती है। यह सोचने से पहले अनुमान लगाता है कि reasoning budget कितना allocate करना है, लेकिन LLM context में पहले से यह जानने का लगभग कोई तरीका नहीं लगता कि कितनी reasoning, यानी कितने tokens generate करने होंगे
      problem space अनंत रूप से बड़ा है, और सिर्फ prompts के बीच similarity के आधार पर यह तय करना मुश्किल है कि कितना सोचना चाहिए। model तो reasoning budget तक पहुंचने से पहले भी सोचना बंद कर देता है
      समझ नहीं आता कि adaptive thinking implement करने में इतना effort क्यों लगाया जा रहा है; बेहतर तो यह होगा कि model को end-of-thinking token बेहतर तरीके से emit करने के लिए train किया जाए
      यह patchwork जैसा लगता है। model को उचित मात्रा में reasoning करने के लिए train किया जाना चाहिए: reasoning → बची हुई uncertainty का estimate → जारी रखना है या नहीं तय करना → और reasoning → repeat
    • local models में भी configuration errors की चिंता करनी पड़ती है। experts भी गलती करते हैं, इसलिए provider के हिसाब से local model performance काफी inconsistent होती है
    • time zone या weekday के हिसाब से tests में कोई pattern दिखता है या नहीं, यह जानना दिलचस्प होगा। जैसे business hours के peak पर short-circuit ज्यादा बार होता है या नहीं देखा जा सकता है
    • अगर उन wasted tokens का खर्च भी user ही दे रहा है, तो refund request करना बेहतर हो सकता है

  • लगभग हर दिन quality को सीढ़ीनुमा तरीके से गिरते हुए महसूस किया, और आम तौर पर xhigh इस्तेमाल करता था
    इस साल की शुरुआत में Codex की शानदार meticulous coding पर भरोसा करने वाला अनुभव खत्म हो गया, और बीच-बीच में absurdly dumb implementations आने लगे, इसलिए जब तक OpenAI इस समस्या को गंभीरता से नहीं लेता, मैं Claude पर switch कर गया
    व्यक्तिगत तौर पर मैं इसे कई महीनों से देख रहा हूं, लेकिन OpenAI इसे गंभीरता से लेता दिखा नहीं

    • 3 महीने पहले Claude बहुत बेवकूफ हो गया था, इसलिए मैं Codex पर गया, और 6 महीने पहले उल्टा हुआ था। Codex हो या Claude, आखिरकार दोनों कभी न कभी परेशान करते हैं। फिर भी Codex शायद कम खराब है
    • जून की शुरुआत से मुझे अपने अनुभव में 5.5 की reliability Claude के स्तर तक गिरती लगी
      इसलिए मैं 5.5 high → 5.5 xhigh → 5.4 high पर आ गया
      5.4 high पिछले 3 हफ्तों से पूरी तरह stable रहा है, और फिलहाल मैं उससे संतुष्ट हूं
      कभी-कभी 5.5 xhigh पर काम चलाकर देखता हूं कि क्या वह 100% stable state में वापस आया है, लेकिन अभी लगता है कि वे इस reliability issue को ठीक करने के बजाय 5.6 release का इंतजार कर रहे हैं
    • मैं इसे technical problem नहीं मानता। इसे ठीक करना महंगा पड़ेगा, और users पर्याप्त भुगतान नहीं कर रहे, इसलिए मुझे यह performance घटाने का business decision लगता है

  • déjà vu जैसा लग रहा है। अप्रैल में हुई Claude Code performance regression जैसी ही बात दिखती है। तब मैंने Claude subscription छोड़कर Codex पर switch किया था
    अब सोच रहा हूं कि दोनों को per-token billing पर इस्तेमाल करूं, ज्यादातर काम के लिए Fireworks का GLM 5.2 इस्तेमाल करूं और जरूरत पड़ने पर ही बड़े models पर पैसा खर्च करूं। हालांकि break-even point सही बैठेगा या नहीं, पक्का नहीं

    • per-token billing पर मेरी भी यही प्रतिक्रिया थी, लेकिन दोनों labs के लिए customers को per-token consumption पर shift कराना आर्थिक रूप से फायदेमंद है, इसलिए सिद्धांततः मैं इससे बचना चाहता हूं
      चाहे यह जानबूझकर न हो, मैं ऐसी structure को स्वीकार या enable नहीं करना चाहता जिसमें degraded-quality product से profit मिलता हो
      ChatGPT launch के बाद किसी भी समय की तुलना में अभी open source models और open execution environments, जैसे Pi वगैरह, कहीं ज्यादा आकर्षक लग रहे हैं
    • सही। उसी वजह से मैंने भी Claude Code छोड़कर Codex अपनाया था
      अब सोच रहा हूं कि ऐसी बकवास की फिर चिंता न करनी पड़े, इसके लिए अतिरिक्त 65,000 डॉलर कैसे कमा सकता हूं। OpenRouter जैसी चीजों की economics मुझे पता है
      करीब 2008 की याद आती है, जब “cloud” marketing term के तौर पर उभर रहा था। यह rich clients की expectations कम करने और local ownership को घटाने वाले subscription model के जरिए companies के margins बढ़ाने की packaging जैसा दिखता था
      उसके बाद “सच्चे free/open-source software” को लेकर उत्साह और absolutism से ऊबकर मैंने सोचा कि मैं तब छोटा था, और आगे बढ़ गया
      सच तो यह है कि कई subscription models को मैं कुछ हद तक समझ या सह सकता हूं। software बनाना महंगा है, और 2026 में Photoshop के annual upgrade की value 200 डॉलर मानना शायद fair न हो। लेकिन 20 साल से अच्छी तरह चल रही UI को मनमाने ढंग से बदलना और classic color swatches जैसी चीजों को पूरी तरह हटा देना मूर्खता है
      तब मैं महीने के 200 डॉलर वाले काम के जरूरी tool Codex से classic swatches plugin बना सकता हूं
      मेरे token usage के लिए महीने के 200 डॉलर fair हैं? बहुत ज्यादा इस्तेमाल वाले महीनों में शायद मैंने करीब 1 billion tokens इस्तेमाल किए हों
      लेकिन यही तो समस्या है। उन्हें ठीक-ठीक कौन-सी profitability चाहिए यह जाने बिना वे लगातार levers खींचते रहेंगे, और debt maturities जैसी tea leaves पढ़ें तो कम से कम 2030 या 2032 तक ऐसा ही लगता है
      मैं ऐसी चीजों के बारे में बिल्कुल सोचना नहीं चाहता। model preferences और performance degradation का मूल्यांकन करना, और जिन outputs को मैं असल में पैसे लेकर बनाता और maintain करता हूं उन पर कौन-से mysterious backend experiments चल रहे हैं, उसके हिसाब से AI से बात करने की nuance लगातार update करना नहीं चाहता
      AI tool और collaborator के बीच कहीं है, लेकिन reasoning stage में खराब तरह समझे गए knobs और levers से छेड़छाड़ के कारण होने वाले erratic “personality” बदलाव पागल कर देते हैं। इसलिए मैं कोने में रखे box की ओर इशारा करके यह ठीक-ठीक जानना चाहता हूं कि output quality कैसी होगी, जिसे मेरे अलावा कोई नहीं बदलेगा
    • Fireworks?
    • “feels-based” Claude Code performance regression ही है। non-deterministic system से consistent performance की उम्मीद नहीं करनी चाहिए। performance degradation को support करने वाला कोई empirical data नहीं है
      हाल में जो stepwise change हुआ है, वह model performance में नहीं बल्कि coders की whining और complaints की मात्रा में है

  • Codex open source है, इसलिए ऐसे issues सार्वजनिक रूप से सामने आकर address किए जा सकते हैं—यह अच्छी बात है

    • लेकिन यह तो model behavior है, और public issue tracker होने की बात code न होने के अलावा Claude Code जैसी ही लगती है। ऐसे मामले में https://github.com/anthropics/claude-code से यह कैसे अलग है, समझ नहीं आता
      कुल मिलाकर Codex के open source होने के लिए आभारी हूं, लेकिन इस तरह की समस्या में model अब भी बंद है, इसलिए इसका बहुत मतलब नहीं दिखता
    • मुझे लगता है OpenAI कुल मिलाकर Anthropic से कहीं ज्यादा खुला और सचमुच enterprise जैसा है। Anthropic बस एक black box है

  • हो सकता है मेरी याददाश्त खराब हो, लेकिन token usage और code quality के हिसाब से 5.3 सबसे अच्छा था। 5.5 ज्यादा बेहतर काम तो करता है, लेकिन tokens पूरी तरह चबा जाता है

    • सिर्फ मेरे साथ ऐसा नहीं है। मेरे हिसाब से 5.3-codex output quality और cost के balance में शानदार model था
      5.5 या Opus के उलट, यह लगभग हर task के लिए इस्तेमाल करने लायक सस्ता और efficient था, फिर भी काफी अच्छा था, और मैं इसे Sonnet से ज्यादा पसंद करता था
    • कुछ हफ्ते पहले 5.3 मेरे लिए unusable हो गया था। बस रुक जाता था या बहुत खराब जवाब देता था

  • कुछ दिन पहले यहां किसी ने कहा था कि OpenAI ने एक breakthrough optimization से compute cost आधी कर दी है; क्या यह वही है?

    • वह The Information का article था, लेकिन वह बहुत अच्छा लिखा हुआ नहीं लगा। ऐसा नहीं लगा कि लेखक LLM कैसे काम करते हैं, यह पर्याप्त रूप से जानने वाला technical expert है जो internal rumors को भरोसेमंद तरीके से evaluate कर सके: https://www.theinformation.com/newsletters/ai-agenda/openai-...
      उसमें यह बात थी कि चर्चा से परिचित एक व्यक्ति के मुताबिक, “OpenAI engineers ने इस महीने की शुरुआत में कुछ colleagues से कहा कि newly discovered optimization की वजह से उन्होंने existing models चलाने, यानी inference की cost को आधे से ज्यादा घटाने का तरीका ढूंढ लिया है”
    • मैंने उस rumor को ऐसे समझा था कि breakthrough OpenAI ने खुद नहीं, बल्कि OpenAI से बाद में निकले groups में से किसी एक—शायद Thinking Machines—ने बनाया है और वे इसे OpenAI को propose कर रहे हैं। मुझे नहीं लगता OpenAI ने अभी सच में इसे implement किया है

  • मेरे मामले में encrypted reasoning content को base64 string length से देखने पर यह effect दिखता है। लेकिन server द्वारा report किए गए reasoning tokens में यह नहीं दिखता
    इसलिए मैंने सोचा कि यह purely encryption या obfuscation का हिस्सा है, असली problem नहीं
    GPT की सबसे बड़ी कमजोरी यह है कि thought process encrypted है, इसलिए यह Kimi, GLM, DeepSeek से भी ज्यादा black box है। फिर भी thought summary मिल जाती है, इसलिए अटपटा होने पर भी usable है

  • क्या यह उन दुर्लभ मामलों में से है जहां “model को dumb बना दिया” कहना आम user delusion नहीं, बल्कि सचमुच model को dumb बना देने का मामला है?

    • यह बल्कि inference engine या agent execution environment की defect या configuration error जैसा दिखता है
      issue details intentional stealth weakening का evidence नहीं हैं, बल्कि लगभग उल्टा ही हैं। root cause भद्दा है, और इतना गुप्त भी नहीं कि एक आम user independently verifiable precise details के साथ report न कर सके
      “आम user delusion” कहना न तो fair है और न ही मेरी पसंद का। जब आपके पास बस ऐसा API endpoint हो जो context window निगलकर आगे का output उगलने वाला magic sink जैसा हो, तो subjective judgment, guesswork और शक ही बचते हैं
      standardized model test suite होने पर भी, stealth weakening का दावा अंततः कंपनी के लोगों की intent पढ़ने जैसा है। explicit intent या underlying infrastructure downgrade के बिना भी model quality गिर सकती है
      मजाकिया conspiracy theory या वास्तविक weakening की संभावना पर विचार करना अपने-आप में mental illness नहीं है। psychological diagnosis terms का इस तरह misuse करने का trend मुझे पसंद नहीं
      हां, कुछ लोग ऐसे judgments को लेकर जरूरत से ज्यादा certain होंगे, और उन पर यह लागू हो सकता है, लेकिन वे minority हैं। आखिर में यह बस exaggeration है, और किसी के काम नहीं आता

  • frontier model subscription बेचकर समय के साथ उसे तेजी से nerf करते जाना और कोई इस पर बात न करे—यह मजेदार है
    server side पर चुपचाप reasoning intensity घटाई जाए तो कम से कम discount तो देना चाहिए
    दूसरी तरफ, मैं 5.5-high को रोज parallel multi-task workflows में इस्तेमाल कर रहा हूं, और weekly limit मुश्किल से पूरी खर्च कर पाता हूं। planning और implementation सब पढ़कर follow करने के लिए मैं Human-as-a-Service के रूप में काफी तेज नहीं हूं। यह पहलू भी है

  • throughput optimization के लिए reasoning inference को 512-token multiples में group करके batch processing करना साफ दिखता है

    • मेरा पहला thought, llama.cpp के आधार पर, यह था कि inference budget parameter की tuning से ऐसा result आ सकता है। लेकिन OpenAI की announcement के बिना ठीक-ठीक जानने का तरीका नहीं है
      peak hours demand के हिसाब से scale करने का यह बेहद dishonest तरीका भी हो सकता है। मुझे पता है कि इस topic में model performance के subjective feel का मजाक उड़ाने वाले लोग पहले से हैं, लेकिन कम से कम मई के पूरे महीने मेरे tests में, जब US online आता था तब model कम smart लगता था
      कुछ हफ्ते पहले company blog post में भी overlapping time periods में यह ज्यादा consistent pattern की तरह महसूस हुआ, इसलिए लगा कि इसे point out करना चाहिए। आगे analysis के लिए session logs save कर लेने चाहिए थे https://webesque.agency/blog/2026-06-19-llms.html
    • क्या standard तो continuous batching इस्तेमाल करना नहीं है? अगर continuous batching इस्तेमाल हो रही है, तो generation token length क्यों मायने रखती है और length के हिसाब से group क्यों करते हैं, यह जानना चाहूंगा। अगर नहीं, तो क्यों नहीं इस्तेमाल करते और उसके trade-offs क्या हैं, यह जानना चाहूंगा