ప్రధాన కంటెంట్‌కి దాటండి
OpenAI

13 ఫిబ్రవరి, 2026

ఇంజనీరింగ్

రేట్ పరిమితులను అధిగమించి: Codex మరియు Sora యాక్సెస్ విస్తరించడం

జోనా కోహెన్, సాంకేతిక సిబ్బంది సభ్యుడు

లోడ్ అవుతోంది…

గత సంవత్సరంలో, Codex మరియు Sora రెండూ వేగంగా స్వీకరించబడ్డాయి, వినియోగం మనం మొదట ఊహించిన దానికంటే త్వరగా పెరిగింది. మేం ఒక స్థిరమైన నమూనాను గమనించాం: వినియోగదారులు లోతుగా ప్రవేశించి, నిజమైన విలువను కనుగొంటారు, ఆ తర్వాత రేట్ పరిమితులను ఎదుర్కొంటారు.

రేట్ పరిమితులు డిమాండ్‌ను క్రమబద్ధీకరించడానికి మరియు న్యాయమైన యాక్సెస్‌ను నిర్ధారించడంలో సహాయపడతాయి; అయితే, వినియోగదారులు విలువ పొందుతున్నప్పుడు, అకస్మాత్తుగా సేవలు నిలిచిపోవడం నిరాశకు గురి చేస్తుంది. సిస్టమ్ పనితీరును మరియు మా విధానంపై వినియోగదారుల నమ్మకాన్ని కాపాడుతూ, వినియోగదారులు కొనసాగించడానికి ఒక మార్గం కావాలని మేం కోరుకున్నాం.

ఈ సమస్యను పరిష్కరించడానికి, మేం వినియోగాన్ని లెక్కించే ఒక రియల్-టైమ్ యాక్సెస్ ఇంజిన్‌ను రూపొందించాం. ఆ ఇంజిన్‌లోని పొరల్లో ఒకటి క్రెడిట్‌లను కొనుగోలు చేయగల సామర్థ్యం. వినియోగదారులు తమ రేట్ లిమిట్స్‌ను మించినప్పుడు, క్రెడిట్‌లు తమ బ్యాలెన్స్‌ను ఉపయోగించుకోవడం ద్వారా మా ఉత్పత్తులను నిరంతరాయంగా వాడేందుకు వీలు కల్పిస్తాయి.

దీని కింద ఒక సంక్లిష్ట వ్యవస్థ ఉంది, ఇది పరిమితులు, రియల్-టైమ్ వినియోగ ట్రాకింగ్, మరియు క్రెడిట్ బ్యాలెన్స్‌లను ఒకే యాక్సెస్ మోడల్‌లో కలిపి ఉంచుతుంది. ఈ పోస్ట్ Codex మరియు Sora స్కేలింగ్ కోసం యాక్సెస్ నియంత్రణను పునరాలోచించాల్సిన కారణాలను, నిరూపణాత్మకంగా సరైన రియల్-టైమ్ సిస్టమ్ ఎలా ప్రతి రిక్వెస్ట్‌కు రేట్ లిమిట్స్ మరియు క్రెడిట్స్‌ను కలిపి ఉపయోగిస్తుంది, ఆ పునాది ఇప్పుడు రెండు ఉత్పత్తులకు అదనపు యాక్సెస్‌ను ఎలా అందిస్తుందనేది వివరిస్తుంది.

ప్రస్తుత యాక్సెస్ మోడల్స్ ఎందుకు విఫలమయ్యాయి

క్లుప్తంగా చెప్పాలంటే, సంప్రదాయ యాక్సెస్ మోడల్స్ ఒక ఎంపికను ఎంచుకోవాలని ఒత్తిడి చేస్తాయి

  • రేట్ పరిమితులు మొదట్లో సహాయపడవచ్చు, అయితే అవి ముగిసిపోయినప్పుడు "తర్వాత రండి" అని చెప్పడం వినియోగదారులకు చేదు అనుభవాన్ని మిగిలిస్తుంది.
  • వినియోగ‑ఆధారిత బిల్లింగ్ అనువైనది, అయితే వినియోగదారులు మొదటి టోకెన్ నుంచే చెల్లించాల్సి ఉంటుంది—ప్రారంభ అన్వేషణకు ఇది అనుకూలం కాదు

Codex మరియు Sora కోసం, ఏదీ తగినది కాదు. మేము రేట్ పరిమితులను సులభంగా పెంచితే, ముఖ్యమైన డిమాండ్ స్మూతింగ్ మరియు సమానత్వ నియంత్రణలను కోల్పోతాము మరియు అందరికీ సేవ చేయడానికి సామర్థ్యం తక్కువైపోతుంది. మేం పూర్తిగా అసింక్రోనస్ వినియోగ బిల్లింగ్‌పై ఆధారపడితే, ల్యాగ్, అదనపు ఖర్చులు, లేదా సమన్వయ సమస్యలను పరిచయం చేస్తాం—వినియోగదారులు పనిలో నిమగ్నమైనప్పుడు సరిగ్గా ఇవే సమస్యలను గమనిస్తారు.

దానికి బదులుగా మాకు అవసరమైనది రియల్ టైమ్ పరిమితులతో పాటు వాడినంత చెల్లించే యాక్సెస్ ఉన్న ఏకైక హైబ్రిడ్ సిస్టమ్:

రేట్-లిమిట్లు మరియు క్రెడిట్‌లు అని లేబుల్ చేసిన రెండు బటన్‌లతో డ్యాష్‌బోర్డ్ UI, మరియు క్రెడిట్ ఫాల్‌బ్యాక్‌తో రేట్-లిమిట్ అనే శీర్షికతో కింద ఒక కార్డ్.

ఈ వ్యవస్థ వీటిని చేయాల్సి ఉంది:

  • రేట్ పరిమితులు చేరే until వరకు అమలు చేయడం
  • క్రెడిట్‌లకు సులభంగా మారడం అదే అభ్యర్థనలోనే
  • ఆ నిర్ణయాన్ని రియల్-టైమ్‌లో తీసుకోవడం
  • క్రెడిట్ వినియోగాన్ని ట్రాక్ చేస్తున్నప్పుడు ఖచ్చితంగా మరియు ఆడిట్ చేసేవిధంగా ఉండటం

గేటు కంటే జలపాతం వలే యాక్సెస్ చేసుకోవడం

మేం చేసిన ముఖ్యమైన భావనాత్మక మార్పుల్లో ఒకటి యాక్సెస్‌ను నిర్ణయ జలపాతంగా మోడల్ చేయడం. “ఇది అనుమతించబడిందా?” అని అడగడం కంటే, మేము “ఎంత వరకు అనుమతించబడుతుంది, మరియు ఎక్కడి నుండి?” అని అడుగుతున్నాము వినియోగాన్ని లెక్కించేటప్పుడు, వ్యవస్థ క్రింది క్రమాన్ని అనుసరిస్తుంది:

మా ఫీచర్‌లకు యాక్సెస్‌ను అంచనా వేయడానికి నిర్ణయ వృక్షం

ఈ మోడల్ వినియోగదారులు ఉత్పత్తిని నిజంగా ఎలా అనుభవిస్తారనేది ప్రతిబింబిస్తుంది. రేట్ పరిమితులు, ఉచిత స్థాయిలు, క్రెడిట్లు, ప్రమోషన్లు, మరియు ఎంటర్‌ప్రైజ్ హక్కులు అన్నీ ఒకే నిర్ణయ క్రమంలో లేయర్లు మాత్రమే. వినియోగదారుడి దృష్టికోణం నుండి, వారు “సిస్టమ్‌లను మార్చరు”—వారు కేవలం Codex మరియు Soraని ఉపయోగించడం కొనసాగిస్తారు. అందుకే క్రెడిట్లు కనిపించవు: అవి వాటర్‌ఫాల్‌లోని మరో అంశం మాత్రమే.

మేం దీన్ని ఇన్ హౌస్‌లో ఎందుకు నిర్మించామనేది తెలుసుకోండి

మేం క్రెడిట్ వినియోగాన్ని నిర్వహించడానికి మూడవ పక్ష వినియోగ బిల్లింగ్ మరియు మీటరింగ్ ప్లాట్‌ఫారమ్‌లను మూల్యాంకనం చేశాం. ఇన్‌వాయిసింగ్ మరియు రిపోర్టింగ్‌కు అవి బాగా సరిపోతాయి, అయితే రెండు ముఖ్యమైన అవసరాలను తీరించలేదు:

రియల్-టైమ్ ఖచ్చితత్వం

ఒక వినియోగదారు పరిమితిని చేరినప్పుడు మరియు క్రెడిట్‌లు లభ్యమయ్యేటప్పుడు, సిస్టమ్‌కు తక్షణమే తెలుసుండాలి. ఉత్తమ ప్రయత్నం లేదా ఆలస్యమైన లెక్కింపు అనుకోని బ్లాక్‌లు, అసంగతమైన బ్యాలెన్స్‌లు, తప్పు ఛార్జీలుగా కనిపిస్తాయి. Codex మరియు Sora వంటి ఇంటరాక్టివ్ ఉత్పత్తులలో, ఆ వైఫల్యాలు స్పష్టంగా కనిపించి నిరాశ కలిగిస్తాయి.

సమరూపత మరియు నమ్మకం

మేం ప్రతి ఫలితంపై కూడా పారదర్శకతను అందించాల్సి ఉంది:

  • ఒక అభ్యర్థనను ఎందుకు అనుమతించారు లేదా నిరోధించారు
  • ఇది ఎంత వినియోగించబడింది
  • ఏ పరిమితులు లేదా సమతుల్యాలు వర్తించాయి

ఈ సామర్థ్యం మా 'నిర్ణయ క్రమం'లోనే గట్టిగా అనుసంధానించబడాలి; అంతే తప్ప, ఏమి జరుగుతుందో కేవలం ఒక భాగాన్ని మాత్రమే చూసే విడిగా ఉన్న బిల్లింగ్ ప్లాట్‌ఫారమ్‌లో దీనిని పరిష్కరించకూడదు. వినియోగదారులు నమ్మకాన్ని దెబ్బతీయకుండా మా ఉత్పత్తులను యాక్సెస్ చేయడానికి వీలు కల్పించడానికి, సరైనత, సమయపాలన, మరియు పరిశీలనపై మాకు పూర్తి నియంత్రణ అవసరం. అది మమ్మల్ని ఒక ఇన్ హౌస్ పరిష్కారం వైపు నెట్టింది.

పెద్ద స్థాయి వినియోగం మరియు సమతుల్య సిస్టమ్‌ను నిర్మించడం

దీనిని శక్తివంతం చేయడానికి, మేం సమకాలిక యాక్సెస్ నిర్ణయాల కోసం ప్రత్యేకంగా రూపొందించిన పంపిణీ చేసిన వినియోగం మరియు సమతుల్యత వ్యవస్థను నిర్మించాం.

అధిక స్థాయిలో, వ్యవస్థ:

  • ప్రతి యూజర్, ప్రతి ఫీచర్ వినియోగాన్ని ట్రాక్ చేస్తుంది
  • రేట్ పరిమితి విండోలను నిర్వహిస్తుంది
  • రియల్‑టైమ్ క్రెడిట్ బ్యాలెన్స్‌లను నిర్వహిస్తుంది
  • స్ట్రీమింగ్ అసింక్రోనస్ ప్రాసెసర్ ద్వారా బ్యాలెన్స్‌లను ఐడెంపోటెంట్ పద్ధతిలో బిట్ చేస్తుంది

ప్రతి అభ్యర్థన ఒకే మూల్యాంకన మార్గం గుండా వెళుతుంది, ఇది రేట్ పరిమితుల నుండి సమకాలికంగా వినియోగాన్ని తీసుకోవడం ద్వారా మరియు అవసరమైతే తగిన క్రెడిట్‌లు ఉన్నాయా అని ధృవీకరించడం ద్వారా ఎంత వినియోగాన్ని అనుమతించాల అనుమతించాలని రియల్ టైమ్‌లో నిర్ణయం తీసుకుంటుంది. ఆ తర్వాత, ఏవైనా క్రెడిట్ డెబిట్‌లను అసమకాలికంగా సెటిల్ చేస్తూ ఒకే తుది ఫలితాన్ని అందిస్తుంది. ఇది ఉత్పత్తుల అంతటా స్థిరమైన ప్రవర్తనను నిర్ధారించి, టీమ్‌ల మధ్య పునరావృత లాజిక్‌ను తొలగిస్తుంది.

యాక్సెస్ సిస్టమ్: రియల్-టైమ్ రేటు పరిమితులు మరియు అసింక్రోనస్ క్రెడిట్ & బ్యాలెన్స్ ట్రాకింగ్ కలయిక.

నిరూపించదగిన ఖచ్చితమైన బిల్లింగ్ వ్యవస్థ

ఈ వ్యవస్థ ముఖ్యమైన డిజైన్ సూత్రాల్లో ఒకటి ఏమిటంటే, మా బిల్లింగ్ సరిగ్గా ఉందని మేం నిరూపించగలగాలి. ఇది మా క్రెడిట్ మద్దతు మూలాలను ప్రతిబింబిస్తుంది, ఇవి ఎంటర్‌ప్రైజ్ కస్టమర్‌లతో ప్రారంభమయ్యాయి. పై సిస్టమ్ డయాగ్రామ్‌లో, మాకు మూడు వేర్వేరు డేటాసెట్‌లు ఉన్నాయి, అవన్నీ పరస్పరం అనుసంధానించబడ్డాయి:

  • ఉత్పత్తి వినియోగ ఈవెంట్‌లు: యూజర్ వాస్తవానికి ఏమి చేశాడు
  • మోనిటైజేషన్ ఈవెంట్‌లు: వినియోగానికి మేం యూజర్‌ను చార్జ్ చేసే సందర్భాలు
  • బ్యాలెన్స్ అప్‌డేట్‌లు: మేం యూజర్ క్రెడిట్ బ్యాలెన్స్‌ను ఎంత మరియు ఎందుకు సర్దుబాటు చేశాం

ఈ డేటాసెట్‌లు సాధారణ ఉప-ఉత్పత్తి కావు; అవి నిజంగా వ్యవస్థను నడిపిస్తాయి, ప్రతి డేటాసెట్ తరువాతి దానిని ప్రేరేపిస్తుంది. ఏమి జరిగింది, సంబంధిత ఛార్జీలు, మరియు మేం డెబిట్ చేసిన వాటిని వేరు చేయడం ద్వారా, ప్రతి లేయర్‌ను స్వతంత్రంగా ఆడిట్ చేయడం, రీప్లే చేయడం, మరియు సరిచూసుకోవడం సాధ్యమవుతుంది. ఇది మేం ఉద్దేశపూర్వకంగా చేసుకున్న రాజీ; దీని ద్వారా క్రెడిట్ బ్యాలెన్స్ అప్‌డేట్‌లు స్వల్పంగా ఆలస్యమైనప్పటికీ, నిరూపించదగిన ఖచ్చితత్వానికి మేం ప్రాధాన్యత ఇస్తున్నాం. మేం దీన్ని ఎలా సాధించామో ఇలా ఉంది:

  • క్రెడిట్ వినియోగాన్ని ప్రేరేపించినా లేకపోయినా, అన్ని యూజర్ కార్యకలాపాల కోసం ప్రొడక్ట్ వినియోగ ఈవెంట్‌లు ప్రచురించబడతాయి. ఇది వినియోగదారుల కార్యకలాపాలకు ఆడిట్ ట్రయల్‌ను అందిస్తుంది మరియు మేం క్రెడిట్‌లను ఎందుకు వసూలు చేశామో లేదా చేయలేదని వివరించగలుగుతాం.
  • ప్రతి ఈవెంట్ ఒక స్థిరమైన ఐడెంపోటెన్సీ కీ ఉంటుంది, కాబట్టి రీట్రైలు, రీప్లేలు లేదా వర్కర్ రీస్టార్ట్‌లు జరిగినప్పుడు బ్యాలెన్స్ నుండి రెండుసార్లు డెబిట్ అవ్వదు, ఇది డబుల్ ఛార్జింగ్‌ను నివారిస్తుంది. ఇది మా పనిని ఆఫ్లైన్‌లో ధృవీకరించడానికి బ్యాచ్ సమన్వయాన్ని నిర్వహించడానికి కూడా మమ్మల్ని అనుమతిస్తుంది.
  • మేం ఆడిట్ ట్రయల్ సృష్టించడానికి సింక్రోనస్ అప్‌డేట్‌లకు బదులుగా అసింక్రోనస్ (కానీ ఇంకా దాదాపు రియల్-టైమ్) బ్యాలెన్స్ అప్‌డేట్లు చేస్తాం. సిస్టమ్ సరిగ్గా పనిచేస్తోందని నిరూపించడానికి మరియు మా వినియోగదారులకు తప్పుడు బిల్లింగ్ చేయడం లేదని భరోసా ఇవ్వడానికి, బ్యాలెన్స్ అప్‌డేట్ చేయడంలో మేం స్వల్ప ఆలస్యాన్ని అంగీకరిస్తాం. ఆ స్వల్ప ఆలస్యం వల్ల మేం వినియోగదారుడి క్రెడిట్ బ్యాలెన్స్‌ను మించి ఖర్చు చేస్తే, మేం దానిని ఆటోమేటిక్‌గా రీఫండ్ చేస్తాము; కఠినమైన అమలు కంటే నిరూపించగల కచ్చితత్త్వం మరియు వినియోగదారుల నమ్మకాన్ని మేం ఎంచుకుంటాం.
  • మేం క్రెడిట్ బ్యాలెన్స్ తగ్గించి, ఒకే అటామిక్ డేటాబేస్ లావాదేవీలో బ్యాలెన్స్ అప్‌డేట్ రికార్డును చేర్చుతాం. ప్రతి ఖాతాకు బ్యాలెన్స్ అప్‌డేట్‌లు సీరియలైజ్ చేయబడతాయి, అందువల్ల సమకాలీన అభ్యర్థనలు ఒకే క్రెడిట్‌లను ఖర్చు చేయడానికి ఎప్పటికీ పోటీ పడవు. బ్యాలెన్స్ అప్‌డేట్ రికార్డ్‌లో డెబిట్ మొత్తం మరియు అప్‌డేట్‌ను ప్రేరేపించిన మోనిటైజేషన్ ఈవెంట్‌కు సంబంధించిన అట్రిబ్యూషన్ రెండూ ఉంటాయి; దీన్ని ఒకే డేటాబేస్ లావాదేవీలో చేర్చడం ద్వారా క్రెడిట్ బ్యాలెన్స్‌లో ప్రతి సర్దుబాటు కోసం మనకు ఆడిట్ ట్రయల్ ఉంటుందని హామీ ఇస్తుంది.

ఈ కఠినత అంతా ఒకే లక్ష్యాన్ని మద్దతు ఇస్తుంది: యాక్సెస్‌ను సులభంగా మరియు సురక్షితంగా చేయడం. ప్రజలు సృష్టిస్తున్నప్పుడు లేదా కోడింగ్ చేస్తున్నప్పుడు, ఒక అభ్యర్థన పూర్తవుతుందా, వారికి అధికంగా ఛార్జ్ చేస్తారా, లేదా వారి బ్యాలెన్స్ సరిగ్గా ఉందా అని ఆలోచించాల్సిన అవసరం ఉండకూడదు. వినియోగం, బిల్లింగ్, మరియు బ్యాలెన్స్‌లు నిరూపణీయంగా సరిగ్గా ఉండేలా చేయడం ద్వారా, మేము యూజర్లకు వారి అనుభవాన్ని దృష్టి మళ్లించని ఒక సిస్టమ్‌ను అందిస్తున్నాము. అదే మాకు హార్డ్ స్టాప్‌లను నిరంతర యాక్సెస్‌తో భర్తీ చేయడానికి అనుమతిస్తుంది—మరియు అదే క్రెడిట్‌లను కేవలం ఇన్వాయిస్‌లోనే కాకుండా, నిజమైన పనిలో కూడా ఉపయోగించేలా చేస్తుంది.

వేగానికి సేవ చేసే ఆర్కిటెక్చర్

మా విధానం వెనుక ఉన్న మార్గదర్శక సూత్రం ఏమిటంటే, వినియోగదారు పని వేగాన్ని కాపాడటం. ప్రతి ఆర్కిటెక్చరల్ నిర్ణయం యూజర్‌కు కనిపించే ఫలితానికి అనుసంధానించబడుతుంది: రియల్-టైమ్ బ్యాలెన్సులు అనవసరమైన అంతరాయాలను నివారిస్తాయి, అటామిక్ వినియోగం డబుల్-చార్జింగ్‌ను నివారిస్తుంది, మరియు ఏకీకృత యాక్సెస్ లాజిక్ ముందుగా అంచనా వేయగల ప్రవర్తనను నిర్ధారిస్తుంది. దీని ఫలితంగా, ప్రజలు కఠినమైన ఆపివేతలు లేదా ముందస్తు ప్రణాళిక మార్పులను ఎదుర్కోకుండా ఎక్కువసేపు పని చేయగలరు, లోతుగా అన్వేషించగలరు, ప్రాజెక్ట్‌లను మరింత ముందుకు తీసుకెళ్లగలరు.

వినియోగదారులు నిమగ్నమై ఉన్నప్పుడు, సిస్టమ్ వారికి కొనసాగడంలో సహాయపడాలి, అడ్డంకిగా మారరాదు. పరిమితులు మరియు క్రెడిట్‌లు బ్యాక్‌గ్రౌండ్‌లో కలిసిపోతాయి.

ఆ అనుభవాన్ని సృష్టించడానికి యాక్సెస్, వినియోగం, బిల్లింగ్‌ను ఒకే వ్యవస్థగా పునరాలోచించడం, అలాగే సరైనతను ప్రథమ శ్రేణి ఉత్పత్తి లక్షణంగా పరిగణించే మౌలిక సదుపాయాలను నిర్మించడం అవసరం. అదే పునాది కాలక్రమేణా మరిన్ని ఉత్పత్తులకు విస్తరించవచ్చు; Codex మరియు Sora కేవలం ఆరంభం.

రచయిత

Jonah Cohen

కృతజ్ఞతలు

క్రెడిట్స్‌ను రూపొందించిన మొత్తం FinEng బృందానికి ప్రత్యేక ధన్యవాదాలు.