2026 ജനുവരി 23

Codex ഏജന്റ് ലൂപ്പ് അൺറോൾ ചെയ്യുന്നു

Michael Bolin, സാങ്കേതിക സ്റ്റാഫിലെ അംഗം

ലോഡിംഗ്…

Codex CLI⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഞങ്ങളുടെ ക്രോസ്-പ്ലാറ്റ്ഫോം ലോക്കൽ സോഫ്റ്റ്‌വെയർ ഏജന്റ് ആണ്, നിങ്ങളുടെ മെഷീനിൽ സുരക്ഷിതമായും കാര്യക്ഷമമായും പ്രവർത്തിക്കുന്ന പക്ഷം ഉയർന്ന നിലവാരമുള്ളതും വിശ്വസനീയവുമായ സോഫ്റ്റ്‌വെയർ മാറ്റങ്ങൾ സൃഷ്ടിക്കാവുന്ന രീതിയില്‍ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നു. ഏപ്രിലിൽ ഞങ്ങൾ ആദ്യമായി CLI പുറത്തിറക്കിയതുമുതൽ ഒരു ലോകോത്തര സോഫ്റ്റ്‌വെയർ ഏജന്റ് എങ്ങനെ നിർമ്മിക്കാമെന്നതിനെക്കുറിച്ച് ഞങ്ങൾ കൂടുതലായി പഠിച്ചിട്ടുണ്ട് CLI ആദ്യമായി ഏപ്രിലിൽ പുറത്തിറക്കിയതുമുതൽ⁠. ആ ഉൾക്കാഴ്ചകൾ വിശദമായി മനസിലാക്കുന്നതിനുവേണ്ടി, Codex പ്രവർത്തിക്കുന്നതിന്റെ വിവിധ വശങ്ങളും, ബുദ്ധിമുട്ടി നേടിയ പാഠങ്ങളും ഞങ്ങൾ പരിശോധിക്കുന്ന ഒരു പരമ്പരയിലെ ആദ്യ പോസ്റ്റാണ് ഇത്. (Codex CLI എങ്ങനെ നിർമ്മിച്ചിരിക്കുന്നുവെന്ന് കൂടുതൽ സൂക്ഷ്മമായി കാണാൻ, ഞങ്ങളുടെ ഓപ്പൺ സോഴ്‌സ് റിപ്പോസിറ്ററി https://github.com/openai/codex⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) പരിശോധിക്കുക. നിങ്ങൾക്ക് കൂടുതൽ അറിയണം എന്നുണ്ടെങ്കില്‍, ഞങ്ങളുടെ ഡിസൈൻ തീരുമാനങ്ങളിലെ സൂക്ഷ്മമായ പല വിശദാംശങ്ങളും GitHub issues-ലും പുൾ റിക്വസ്റ്റുകളിലും ആയി രേഖപ്പെടുത്തിയിട്ടുണ്ട്.)

ആരംഭത്തില്‍, Codex CLI-യിലെ പ്രധാന ലോജിക്കായ ഏജന്റ് ലൂപ്പ് എന്നതിൽ ഞങ്ങൾ ശ്രദ്ധ കേന്ദ്രീകരിക്കും, ഇതാണ് ഉപയോക്താവ്, മോഡൽ, മോഡൽ ഉപയോഗിക്കുന്ന ഉപകരണങ്ങൾ എന്നിവ തമ്മിലുള്ള അർത്ഥവത്തായ സോഫ്റ്റ്‌വെയർ പ്രവർത്തനങ്ങളെ ഏകോപിപ്പിക്കുന്നത്. ഈ പോസ്റ്റ് ഞങ്ങളുടെ ഏജന്റ് (അഥവാ “harness”) LLM ഉപയോഗിക്കുന്നതിൽ വഹിക്കുന്ന പങ്കിനെക്കുറിച്ച് നിങ്ങൾക്ക് നല്ലൊരു അവബോധം നൽകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

നാം മുന്നോട്ട് പോകുന്നതിന് മുമ്പ്, പദപ്രയോഗത്തെക്കുറിച്ച് ഒരു ചെറിയ കുറിപ്പ്: OpenAI-ൽ, “Codex” എന്നത് Codex CLI, Codex Cloud, Codex VS Code എക്സ്റ്റൻഷൻ എന്നിവ ഉൾപ്പെടുന്ന സോഫ്റ്റ്‌വെയർ ഏജന്റ് ഓഫറിംഗുകളുടെ ഒരു കൂട്ടത്തെയാണ് ഉദ്ദേശിക്കുന്നത്. ഈ പോസ്റ്റ് Codex harness-നെ കേന്ദ്രീകരിക്കുന്നു, ഇത് എല്ലാ Codex അനുഭവങ്ങൾക്കും അടിസ്ഥാനം നൽകുന്ന കോർ ഏജന്റ് ലൂപ്പും എക്സിക്യൂഷൻ ലോജിക്കും നൽകുന്നു,മാത്രമല്ല ഇത് Codex CLI മുഖേന ഉയര്‍ന്നു വരുന്നതാണ്. ഇവിടെ സൗകര്യത്തിനായി, “Codex” എന്നതും “Codex CLI” എന്നതും പരസ്പരം മാറ്റി ഉപയോഗിക്കാം.

ഏജന്റ് ലൂപ്പ്

ഓരോ AI ഏജന്റിന്റെയും കേന്ദ്രം“ഏജന്റ് ലൂപ്പ്” എന്നറിയപ്പെടുന്ന ഒന്നാണ്. ഏജന്റ് ലൂപ്പിന്റെ ലളിതമായ ഒരു ചിതം ഇനി പറയുന്നു:

“Agent loop” എന്ന തലക്കെട്ടുള്ള ഡയഗ്രം, AI സിസ്റ്റം ഉപയോക്തൃ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്നത്, ഉപകരണങ്ങളെ വിളിക്കുന്നത്, ഫലങ്ങൾ നിരീക്ഷിക്കുന്നത്, പദ്ധതി അപ്ഡേറ്റ് ചെയ്യുന്നത്, ഔട്ട്പുട്ടുകൾ തിരികെ നൽകുന്നത് എന്നിവയെ ചിത്രീകരിക്കുന്നു. അമ്പുകൾ ഉപയോക്തൃ ഇൻപുട്ട്, മോഡൽ റീസണിംഗ്, ഉപകരണ പ്രവർത്തനങ്ങൾ, അന്തിമ പ്രതികരണം എന്നിവ പോലുള്ള ഘട്ടങ്ങളെ ബന്ധിപ്പിക്കുന്നു.

തുടക്കത്തില്‍ ഒരു ഏജന്റ്, ഉപയോക്താവിൽ നിന്ന് input സ്വീകരിച്ച്, അത് മോഡലിനായി തയ്യാറാക്കുന്ന വാചക നിർദ്ദേശങ്ങളുടെ കൂട്ടത്തില്‍ ഉൾപ്പെടുത്തുന്നു, ഇത് പ്രോംപ്റ്റ് എന്നറിയപ്പെടുന്നു.

അടുത്ത ഘട്ടം മോഡലിനോട് നമ്മുടെ നിർദ്ദേശങ്ങൾ അയച്ച് ഒരു പ്രതികരണം സൃഷ്ടിക്കാൻ ആവശ്യപ്പെടുന്നതാണ്, ഈ പ്രക്രിയയെ inference എന്ന് അറിയപ്പെടുന്നു. ഇൻഫറൻസ് സമയത്ത്, ടെക്സ്റ്റ് പ്രോംപ്റ്റ് ആദ്യം ഇൻപുട്ട്കളുടെ ഒരു ശ്രേണി അഥവാ ടോക്കണുകള്‍⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആക്കി മാറ്റുന്നു—മോഡലിന്റെ വാക്കുകളുടെ ലൈബ്രറിയില്‍ അതിനെയും കൂടി ചേര്‍ക്കുന്നു. ഈ ടോക്കണുകൾ പിന്നീട് മോഡലിനെ സാമ്പിൾ ചെയ്യാൻ ഉപയോഗിക്കുന്നു, അതിലൂടെ ഔട്ട്പുട്ട് ടോക്കണുകളുടെ ഒരു പുതിയ ശ്രേണി സൃഷ്ടിക്കുന്നു.

ഔട്ട്പുട്ട് ടോക്കണുകൾ തിരികെ ടെക്സ്റ്റായി വിവർത്തനം ചെയ്യപ്പെടുന്നു, അത് മോഡലിന്റെ പ്രതികരണമായി മാറുന്നു. ടോക്കണുകൾ ക്രമാനുഗതമായി ഉൽപ്പാദിപ്പിക്കപ്പെടുന്നതിനാൽ, മോഡൽ പ്രവർത്തിക്കുന്നതിനിടെ തന്നെ ഈ വിവർത്തനം നടക്കാൻ കഴിയും, അതിനാലാണ് പല LLM-അടിസ്ഥാനത്തിലുള്ള ആപ്ലിക്കേഷനുകളും സ്ട്രീമിംഗ് ഔട്ട്പുട്ട് പ്രദർശിപ്പിക്കുന്നത്. പ്രായോഗികമായി നോക്കിയാല്‍,ടെക്സ്റ്റിൽ പ്രവർത്തിക്കുന്ന ഒരു API-യുടെ പിന്നിൽ ഇൻഫറൻസ് സാധാരണയായി മറഞ്ഞിരിക്കുന്നു, ടോക്കനൈസേഷന്‍റെ വിശദാംശങ്ങൾ പുറത്തേക്ക് വരുന്നത് ഒഴിവാക്കുന്നു.

ഇൻഫറൻസ് ഘട്ടം പ്രവര്‍ത്തിക്കുന്നത് വഴി, മോഡൽ (1) ഉപയോക്താവ് നല്‍കിയ ഇൻപുട്ടിന് അനുസരിച് ഒരു പൂര്‍ണമായ പ്രതികരണം നൽകുകയോ, അല്ലെങ്കിൽ (2) ഏജന്റ് ചെയ്യുമെന്ന് പ്രതീക്ഷിക്കപെട്ട ഒരു ടൂൾ കോൾ ചെയ്യുകയോ ചെയ്യുന്നു (ഉദാ., “ls പ്രവർത്തിപ്പിച്ച് ഔട്ട്പുട്ട് റിപ്പോർട്ട് ചെയ്യുക”). സാഹചര്യം (2) ല്‍, ഏജന്റ് ഒരു ടൂളിനെ കാള്‍ ചെയ്ത്, പ്രവര്‍ത്തിപ്പിച്ച് ലഭിച്ച ഫലത്തെ ഒറിജിനൽ പ്രോംപ്റ്റിലേക്ക് ചേര്‍ത്ത് ഒരു ഔട്ട്പുട്ട് തയാറാക്കുന്നു. ഈ ഔട്ട്പുട്ട് ഒരു പുതിയ ഇൻപുട്ട് സൃഷ്ടിക്കാൻ ഉപയോഗിക്കുന്നു, അത് മോഡലിനെ വീണ്ടും ക്വറി ചെയ്യാൻ ഉപയോഗിക്കുന്നു; തുടർന്ന് ഏജന്റിന് ഈ പുതിയ വിവരങ്ങൾ പരിഗണിച്ച് വീണ്ടും ശ്രമിക്കാം.

ടൂൾ കോളുകൾ വിളിക്കുന്നത് നിർത്തി ഉപയോക്താവിനായി ഒരു പൂര്‍ണ സന്ദേശം സൃഷ്ടിക്കുന്നതുവരെ ഈ പ്രക്രിയ മോഡൽ ആവർത്തിക്കുന്നു (ഇതിനെ OpenAI മോഡലുകളിൽ assistant message എന്ന് വിളിക്കുന്നു). പല സാഹചര്യങ്ങളിലും, ഈ സന്ദേശം ഉപയോക്താവിന്റെ യഥാർത്ഥ അഭ്യർത്ഥനയ്ക്ക് നേരിട്ട് ഉത്തരം നൽകുന്നു, പക്ഷേ ഇത് ഉപയോക്താവിനുള്ള ഒരു ഫോളോ-അപ്പ് ചോദ്യവുമാകാം.

ഏജന്റിന് പ്രാദേശിക പരിസ്ഥിതിയെ മാറ്റുന്ന ഉപകരണ കോളുകൾ നിർവഹിക്കാൻ കഴിയുന്നതിനാൽ, അതിന്റെ “output” അസിസ്റ്റന്റിന്റെ സന്ദേശത്തിൽ മാത്രം പരിമിതമല്ല. പല സാഹചര്യങ്ങളിലും, ഒരു സോഫ്റ്റ്‌വെയർ ഏജന്റിന്റെ പ്രധാന ഔട്ട്പുട്ട് നിങ്ങളുടെ മെഷീനിൽ എഴുതുകയോ എഡിറ്റ് ചെയ്യുകയോ ചെയ്യുന്ന കോഡാണ്. എന്നിരുന്നാലും, ഓരോ ടേണും എല്ലായ്പ്പോഴും ഒരു അസിസ്റ്റന്റ് സന്ദേശത്തോടെ അവസാനിക്കുന്നു—ഉദാഹരണത്തിന് “ഞാൻ നിങ്ങൾ ആവശ്യപ്പെട്ട architecture.md ചേർത്തു”—ഇത് ഏജന്റ് ലൂപ്പിൽ ഒരു അവസാനിപ്പിക്കൽ നിലയെ സൂചിപ്പിക്കുന്നു. ഏജന്റിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന്, അതിന്റെ ജോലി പൂർത്തിയായിരിക്കുന്നു, നിയന്ത്രണം ഉപയോക്താവിലേക്ക് മടങ്ങുന്നു.

ഡയഗ്രത്തില്‍ കാണിച്ചിരിക്കുന്ന യുസര്‍ ഇന്പുട്ട് മുതൽ ഏജന്റ് പ്രതികരണം വരെയുള്ള യാത്രയെ ഒരു സംഭാഷണത്തിന്റെ ഒരു ടേണ്‍ (Codex-ൽ ഒരു ത്രെഡ് ) എന്ന് വിളിക്കുന്നു. ഈ സംഭാഷണ ടേൺ മോഡൽ ഇൻഫറൻസ് നും ടൂൾ കോളുകൾക്കും ഇടയിൽ നിരവധി ആവർത്തനങ്ങൾ ഉൾപ്പെടാം. നിലവിലുള്ള ഒരു സംഭാഷണത്തിലേക്ക് നിങ്ങൾ ഓരോ തവണയും ഒരു പുതിയ സന്ദേശം അയയ്ക്കുമ്പോൾ, അതുവരെയുള്ള സംഭാഷണ ചരിത്രം പുതിയ ടേണ്‍ നിര്‍മ്മിക്കാനുള്ള പ്രോംപ്റ്റിന്റെ ഭാഗമായി ഉൾപ്പെടുത്തപ്പെടുന്നു, അതിൽ മുൻ ടേൺകളിലെ സന്ദേശങ്ങളും ഉപകരണ കോളുകളും ഉൾപ്പെടുന്നു:

“മൾട്ടി-ടേൺ ഏജന്റ് ലൂപ്പ്” എന്ന തലക്കെട്ടുള്ള ഡയഗ്രാം: ഒരു AI ഏജന്റ് ഉപയോക്തൃ ഇൻപുട്ട് ആവർത്തിച്ച് സ്വീകരിക്കുകയും, പ്രവർത്തനങ്ങൾ സൃഷ്ടിക്കുകയും, ഉപകരണങ്ങളെ ഉപദേശിക്കുകയും, സ്റ്റേറ്റ് പുതുക്കുകയും, ഫലങ്ങൾ തിരികെ നൽകുകയും ചെയ്യുന്ന രീതിയിൽ കാണിക്കുന്നു. ഏജന്റിന്റെ റീസണിംഗ് ചക്രം വിശദീകരിക്കുന്ന ലേബൽ ചെയ്ത ഘട്ടങ്ങൾ, അമ്പുകൾ, ഉദാഹരണ ഉപകരണ ഔട്ട്പുട്ടുകൾ എന്നിവ ഉൾപ്പെടുന്നു.

ഇത് അർത്ഥമാക്കുന്നത്, സംഭാഷണം വളരുമ്പോൾ, മോഡൽ സാമ്പിൾ ചെയ്യാൻ ഉപയോഗിക്കുന്ന പ്രോംപ്റ്റിന്റെ ദൈർഘ്യവും കൂടുന്നു എന്നതാണ്. ഈ ദൈർഘ്യം പ്രധാനമാണ്, കാരണം ഓരോ മോഡലിനും ഒരു context window ഉണ്ട്, അത് ഒരു inference call-ന് ഉപയോഗിക്കാൻ കഴിയുന്ന പരമാവധി ടോക്കണുകളുടെ എണ്ണം ആണ്. ശ്രദ്ധിക്കുക: ഈ വിൻഡോയിൽ ഇൻപുട്ട് മറ്റും ഔട്ട്പുട്ട് ടോക്കണുകൾ രണ്ടും ഉൾപ്പെടുന്നു. നിങ്ങൾക്ക്‌ പ്രതീക്ഷിക്കാനാകുന്നതുപോലെ, ഒരു ഏജന്റ്‌ ഒരു ടേണിൽ നൂറുകണക്കിന്‌ ടൂൾ കോളുകൾ നടത്താൻ തീരുമാനിക്കാം, അതുവഴി കോൺടെക്സ്റ്റ്‌ വിൻഡോ തീർന്നുപോകാൻ സാധ്യതയുണ്ട്‌. ഈ കാരണത്താൽ, context window management ഏജന്റിന്റെ പല ഉത്തരവാദിത്വങ്ങളിൽ ഒന്നാണ്. ഇപ്പോൾ, Codex എങ്ങനെ ഏജന്റ് ലൂപ്പ് പ്രവർത്തിപ്പിക്കുന്നുവെന്ന് കാണാൻ നമുക്ക് ആഴത്തിൽ കടക്കാം.

മോഡൽ ഇൻഫറൻസ്

Codex CLI, HTTP അഭ്യർത്ഥനകൾ Responses API⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) -യിലേക്ക് അയച്ച് മോഡൽ ഇൻഫറൻസ് നടത്തുന്നു. Responses API ഉപയോഗിച്ച് ഏജന്റ് ലൂപ്പ് പ്രവർത്തിപ്പിക്കുന്ന Codex വഴി വിവരങ്ങൾ എങ്ങനെ ഒഴുകുന്നു എന്നത് നാം പരിശോധിക്കും.

Codex CLI ഉപയോഗിക്കുന്ന Responses API എൻഡ്‌പോയിന്റ് ക്രമീകരിക്കാവുന്നതാണ്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), അതിനാൽ Responses API നടപ്പിലാക്കുന്ന⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഏതെങ്കിലും എൻഡ്‌പോയിന്റുമായി ഇത് ഉപയോഗിക്കാം:

ChatGPT ലോഗിൻ ഉപയോഗിക്കുമ്പോൾ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) Codex CLI-യോടൊപ്പം, ഇത് https://chatgpt.com/backend-api/codex/responses ഉപയോഗിക്കുന്നു എൻഡ്‌പോയിന്റ് ആയി
API-കീ ആധികാരികീകരണം ഉപയോഗിക്കുമ്പോൾ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) OpenAI ഹോസ്റ്റുചെയ്ത മോഡലുകൾ ഉപയോഗിക്കുമ്പോൾ, https://api.openai.com/v1/responses ഉപയോഗിക്കുന്നു എൻഡ്‌പോയിന്റ് ആയി
--oss ഉപയോഗിച്ച് gpt-oss⁠ ഉപയോഗിച്ച് ollama 0.13.4+⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) അല്ലെങ്കിൽ LM Studio 0.3.39+⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) എന്നിവയോടൊപ്പം Codex CLI പ്രവർത്തിപ്പിക്കുമ്പോൾ, ഇത് നിങ്ങളുടെ കമ്പ്യൂട്ടറിൽ ലോക്കലായി പ്രവർത്തിക്കുന്ന http://localhost:11434/v1/responses എന്നതിലേക്കാണ് ഡിഫോൾട്ടായി സജ്ജീകരിക്കുന്നത്
Codex CLI, Azure പോലുള്ള ഒരു ക്ലൗഡ് പ്രൊവൈഡർ ഹോസ്റ്റ് ചെയ്യുന്ന Responses API-യുമായി ഉപയോഗിക്കാം

ഒരു സംഭാഷണത്തിലെ ആദ്യ ഇൻഫറൻസ് കോളിനായി Codex എങ്ങനെ പ്രോംപ്റ്റ് സൃഷ്ടിക്കുന്നു എന്ന് നമുക്ക് പരിശോധിക്കാം.

ആദ്യ പ്രോംപ്റ്റ് സൃഷ്ടിക്കൽ

ഒരു എൻഡ് യൂസർ എന്ന നിലയിൽ, നിങ്ങൾ Responses API-യെ ക്വറി ചെയ്യുമ്പോൾ മോഡലിനെ സാമ്പിൾ ചെയ്യാൻ ഉപയോഗിച്ച പ്രോംപ്റ്റ് നിങ്ങളുടെ വാക്കുകളില്‍ നിർദ്ദേശിക്കുന്നില്ല. പകരം, നിങ്ങളുടെ ക്വറിയുടെ ഭാഗമായി നിങ്ങൾ വിവിധ തരം ഇൻപുട്ട് നിർദ്ദേശിക്കുന്നു, തുടർന്ന് Responses API സർവർ ഈ വിവരങ്ങൾ മോഡൽ ഉപഭോഗിക്കാൻ രൂപകൽപ്പന ചെയ്തിരിക്കുന്ന പ്രോംപ്റ്റിലേക്കായി എങ്ങനെ ഘടിപ്പിക്കണമെന്ന് തീരുമാനിക്കുന്നു. നിങ്ങൾക്ക് പ്രോംപ്റ്റിനെ ഒരു “ഇനങ്ങളുടെ പട്ടിക” ആയി കരുതാം; ഈ ഭാഗം നിങ്ങളുടെ ക്വറി എങ്ങനെ ആ പട്ടികയാക്കി മാറ്റപ്പെടുന്നു എന്ന് വിശദീകരിക്കുന്നു.

ആദ്യ പ്രോംപ്റ്റിൽ, ലിസ്റ്റിലെ ഓരോ ഇനവും ഒരു റോളുംആയിബന്ധപ്പെട്ടിരിക്കുന്നു. role ബന്ധപ്പെട്ട ഉള്ളടക്കത്തിന് എത്ര പ്രാധാന്യം നൽകണം എന്ന് സൂചിപ്പിക്കുന്നു, കൂടാതെ മുൻഗണനയുടെ ക്രമത്തിൽ താഴെപ്പറയുന്ന മൂല്യങ്ങളിൽ ഒന്നാണ്: system, developer, user, assistant.

Responses API⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) നിരവധി പാരാമീറ്ററുകളുള്ള JSON പേലോഡ് സ്വീകരിക്കുന്നു. നമുക്ക് ഈ മൂന്ന് കാര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം:

നിർദ്ദേശങ്ങൾ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു): സിസ്റ്റം (അല്ലെങ്കിൽ ഡെവലപ്പർ) സന്ദേശം മോഡലില്‍ സന്ദര്ഭം അനുസരിച്ച് ഉൾപ്പെടുത്തുന്നത്.
tools⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു): മോഡൽ ഒരു പ്രതികരണം സൃഷ്ടിക്കുമ്പോൾ വിളിക്കാവുന്ന ഉപകരണങ്ങളുടെ പട്ടിക
input⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു): മോഡലിലേക്കുള്ള ടെക്സ്റ്റ്, ചിത്രം, അല്ലെങ്കിൽ ഫയൽ ഇൻപുട്ടുകളുടെ പട്ടിക

Codex-ൽ, instructions ഫീൽഡ് model_instructions_file⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) -ൽ നിന്ന് ~/.codex/config.toml-ൽ വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ വായിക്കുന്നു; അല്ലാത്തപക്ഷം, ഈ base_instructions മോഡലുമായി ബന്ധപ്പെട്ടവ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉപയോഗിക്കുന്നു. മോഡൽ-നിർദ്ദിഷ്ട നിർദ്ദേശങ്ങൾ Codex repo-യിൽ ലഭ്യമാണ്, കൂടാതെ CLI-യിൽ ബണ്ടിൽ ചെയ്തിരിക്കുന്നു (ഉദാഹരണത്തിന്, gpt-5.2-codex_prompt.md⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)).

tools ഫീൽഡ് ഒരു ലിസ്റ്റ് ആണ്, ഇത് Responses API നിർവചിച്ച സ്കീമയോട് അനുസരിക്കുന്ന ടൂൾ നിർവചനങ്ങൾ ഉൾക്കൊള്ളുന്നു. Codex-നായി, ഇതിൽ Codex CLI നൽകുന്ന ഉപകരണങ്ങൾ, Codex-ന് ലഭ്യമാക്കേണ്ട Responses API നൽകുന്ന ഉപകരണങ്ങൾ, കൂടാതെ സാധാരണയായി MCP servers വഴി ഉപയോക്താവ് നൽകുന്ന ഉപകരണങ്ങൾ എന്നിവ ഉൾപ്പെടുന്നു:

JavaScript

1[
2  // Codex's default shell tool for spawning new processes locally.
3  {
4    "type": "function",
5    "name": "shell",
6    "description": "Runs a shell command and returns its output...",
7    "strict": false,
8    "parameters": {
9      "type": "object",
10      "properties": {
11        "command": {"type": "array", "description": "The command to execute", ...},
12        "workdir": {"description": "The working directory...", ...},
13        "timeout_ms": {"description": "The timeout for the command...", ...},
14        ...
15      },
16      "required": ["command"],
17    }
18  }
19
20  // Codex's built-in plan tool.
21  {
22    "type": "function",
23    "name": "update_plan",
24    "description": "Updates the task plan...",
25    "strict": false,
26    "parameters": {
27      "type": "object",
28      "properties": {"plan":..., "explanation":...},
29      "required": ["plan"]
30    }
31  },
32
33  // Web search tool provided by the Responses API.
34  {
35    "type": "web_search",
36    "external_web_access": false
37  },
38
39  // MCP server for getting weather as configured in the
40  // user's ~/.codex/config.toml.
41  {
42    "type": "function",
43    "name": "mcp__weather__get-forecast",
44    "description": "Get weather alerts for a US state",
45    "strict": false,
46    "parameters": {
47      "type": "object",
48      "properties": {"latitude": {...}, "longitude": {...}},
49      "required": ["latitude", "longitude"]
50    }
51  }
52]

അവസാനമായി, JSON പേലോഡിലെ input ഫീൽഡ് ഇനങ്ങളുടെ ഒരു പട്ടികയാണ്. Codex താഴെ പറയുന്ന ഇനങ്ങൾ ചേർക്കുന്നു⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉപയോക്തൃ സന്ദേശം ചേർക്കുന്നതിന് മുമ്പ് input -ലേക്ക്:

1. ടൂള്‍സ് വിഭാഗത്തിൽ നിർവചിച്ചിരിക്കുന്ന Codex നൽകുന്ന ഷെല്‍ ടൂളിന് മാത്രം ബാധകമായ സാൻഡ്‌ബോക്‌സിനെ വിശദീകരിക്കുന്ന role=developer ഉള്ള ഒരു സന്ദേശം. അതായത്, MCP സെർവറുകൾ നൽകുന്ന മറ്റ് ഉപകരണങ്ങൾ Codex വഴി സാൻഡ്‌ബോക്‌സ് ചെയ്തിട്ടില്ല, അവയുടെ സ്വന്തം സുരക്ഷാ മാനദണ്ഡങ്ങൾ നടപ്പിലാക്കേണ്ടത് അവയുടെ ഉത്തരവാദിത്തമാണ്.

സന്ദേശം ഒരു ടെംപ്ലേറ്റിൽ നിന്നാണ് നിർമ്മിക്കുന്നത്, അതിലെ പ്രധാന ഉള്ളടക്ക ഭാഗങ്ങൾ Codex CLI-യിൽ ബണ്ടിൽ ചെയ്തിരിക്കുന്ന Markdown സ്നിപ്പറ്റുകളിൽ നിന്നാണ് വരുന്നത്, ഉദാഹരണത്തിന് workspace_write.md⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) എന്നതും on_request.md⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) എന്നതും ഉൾപ്പെടുന്നു:

പ്ലെയിൻ ടെക്സ്റ്റ്

1<permissions instructions>
2  - description of the sandbox explaining file permissions and network access
3  - instructions for when to ask the user for permissions to run a shell command
4  - list of folders writable by Codex, if any
5</permissions instructions>

2. (ഓപ്ഷണൽ) ഉപയോക്താവിന്റെ config.toml ഫയലിൽ നിന്ന് വായിച്ച developer_instructions മൂല്യമായ ഉള്ളടക്കം ഉള്ള role=developer എന്ന ഒരു സന്ദേശം.

3. (ഓപ്ഷണൽ) role=user ഉള്ള ഒരു സന്ദേശം, അതിന്റെ ഉള്ളടക്കം “ഉപയോക്തൃ നിർദ്ദേശങ്ങൾ” ആണ്, അവ ഒരു ഒറ്റ ഫയലിൽ നിന്നല്ല, മറിച്ച് ഒന്നിലധികം ഉറവിടങ്ങളിൽ നിന്ന് സമാഹരിച്ചവയാണ്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു). സാധാരണയായി, കൂടുതൽ പ്രത്യേകമായ നിർദ്ദേശങ്ങൾ പിന്നീട് പ്രത്യക്ഷപ്പെടും:

AGENTS.override.md ൽ ഉള്ള AGENTS.md ഫയലിന്റെയും $CODEX_HOMEഫയലിന്റെയും ഉള്ളടക്കം
ഒരു പരിധിക്ക് വിധേയമായി (ഡിഫോൾട്ട് 32 KiB), cwd യുടെ Git/പദ്ധതി റൂട്ടിൽ നിന്ന് (അത് നിലവിലുണ്ടെങ്കിൽ) cwd വരെ ഓരോ ഫോൾഡറിലും നോക്കുക: AGENTS.override.md യിലെ ഏതെങ്കിലും ഫയലിന്റെ ഉള്ളടക്കം ചേർക്കുക, AGENTS.md, അല്ലെങ്കിൽ project_doc_fallback_filenames in config.tomlൽ വ്യക്തമാക്കിയിരിക്കുന്ന ഏതെങ്കിലും ഫയൽനാമം
ഏതെങ്കിലും സ്കിലുകൾ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിൽ:
- കൗശലങ്ങളെക്കുറിച്ചുള്ള ഒരു ചെറിയ പ്രാരംഭം
- ഓരോ സ്‌കിലിനും സ്‌കിൽ മെറ്റാഡാറ്റ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)
- കൗശലങ്ങൾ എങ്ങനെ ഉപയോഗിക്കാം⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)എന്നതിനെക്കുറിച്ചുള്ള ഒരു വിഭാഗം

4. ഏജന്റ് നിലവിൽ പ്രവർത്തിക്കുന്ന പ്രാദേശിക പരിതസ്ഥിതിയെ വിവരിക്കുന്ന role=user എന്ന ഒരു സന്ദേശം. ഇത് നിലവിലെ പ്രവർത്തന ഡയറക്ടറിയും ഉപയോക്താവിന്റെ ഷെല്ലും വ്യക്തമാക്കുന്നു⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു):

പ്ലെയിൻ ടെക്സ്റ്റ്

1<environment_context>
2  <cwd>/Users/mbolin/code/codex5</cwd>
3  <shell>zsh</shell>
4</environment_context>

input ആരംഭിക്കുന്നതിനായി മുകളിലെല്ലാം കണക്കുകൂട്ടലുകൾ Codex പൂർത്തിയാക്കിയ ശേഷം, സംഭാഷണം ആരംഭിക്കാൻ അത് ഉപയോക്തൃ സന്ദേശം ചേർക്കുന്നു.

മുൻ ഉദാഹരണങ്ങൾ ഓരോ സന്ദേശത്തിന്റെയും ഉള്ളടക്കത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചിരുന്നു, പക്ഷേ input എന്നതിലെ ഓരോ ഘടകവും type, role⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), കൂടാതെ content എന്നിവയുള്ള JSON ഒബ്ജക്റ്റാണെന്ന് ശ്രദ്ധിക്കുക, താഴെപ്പറയുന്ന പോലെ:

JSON

1{
2  "type": "message",
3  "role": "user",
4  "content": [
5    {
6      "type": "input_text",
7      "text": "Add an architecture diagram to the README.md"
8    }
9  ]
10}

Codex പൂർണ്ണ JSON payload Responses API-യിലേക്ക് അയയ്ക്കാൻ തയ്യാറാക്കിയ ശേഷം, Authorization -ൽ Responses API എൻഡ്‌പോയിന്റ് എങ്ങനെ കോൺഫിഗർ ചെയ്തിരിക്കുന്നുവെന്നതിനെ ആശ്രയിച്ച് ~/.codex/config.toml ഹെഡറോടുകൂടി HTTP POST അഭ്യർത്ഥന നടത്തുന്നു (നിർദ്ദിഷ്ടമാക്കിയിട്ടുണ്ടെങ്കിൽ അധിക HTTP ഹെഡറുകളും ക്വറി പാരാമീറ്ററുകളും ചേർക്കും).

ഒരു OpenAI Responses API സെർവർ അഭ്യർത്ഥന സ്വീകരിക്കുമ്പോൾ, അത് JSON ഉപയോഗിച്ച് മോഡലിനുള്ള പ്രോംപ്റ്റ് താഴെപ്പറയുന്ന രീതിയിൽ നിർവചിക്കുന്നു (ഉറപ്പാക്കാൻ, Responses API-യുടെ ഒരു കസ്റ്റം ഇംപ്ലിമെന്റേഷൻ വ്യത്യസ്തമായൊരു തിരഞ്ഞെടുപ്പ് നടത്താൻ കഴിയും):

AI ഏജന്റ് ലൂപ്പിലെ ഒരു ഘട്ടം മാത്രം കാണിക്കുന്ന സ്നാപ്ഷോട്ട് ചിത്രം. ഒരു ഉപയോക്തൃ അഭ്യർത്ഥന മോഡലിലേക്ക് പ്രവേശിക്കുന്നു, അത് ഒരു ചിന്ത, ഒരു ഉപകരണ നാമത്തോടുകൂടിയ പ്രവർത്തനം, കൂടാതെ ഒരു ഉപകരണ ഇൻപുട്ട് സൃഷ്ടിക്കുന്നു. ഡയഗ്രാം ടൂൾ വിളിക്കുന്നതിന് മുമ്പുള്ള ഈ ഇടക്കാല റീസണിംഗ് ഘട്ടം ഹൈലൈറ്റ് ചെയ്യുന്നു.

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, പ്രോംപ്റ്റിലെ ആദ്യ മൂന്ന് ഇനങ്ങളുടെ ക്രമം നിർണ്ണയിക്കുന്നത് ക്ലയന്റ് അല്ല, സെർവറാണ്. എന്നിരുന്നാലും, ആ മൂന്ന് ഇനങ്ങളിൽ,tools യും instructions യും ക്ലയന്റ് നിർണ്ണയിക്കുന്നതിനാൽ, system message -ന്റെ ഉള്ളടക്കത്തെ സർവർ നിയന്ത്രിക്കുന്നതുമാണ്. പ്രോംപ്റ്റ് പൂർത്തിയാക്കുന്നതിനായി JSON പേലോഡിൽ നിന്നുള്ള input ഇവയ്ക്ക് പിന്നാലെ വരുന്നു.

ഇപ്പോൾ ഞങ്ങൾക്ക് പ്രോംപ്റ്റ് ലഭിച്ചതിനാൽ, മോഡലിനെ സാമ്പിൾ ചെയ്യാൻ ഞങ്ങൾ തയ്യാറാണ്.

ആദ്യ ഊഴം

Responses API-യിലേക്കുള്ള ഈ HTTP അഭ്യർത്ഥന Codex-ൽ ഒരു സംഭാഷണത്തിന്റെ ആദ്യ “മറുപടി” ആരംഭിക്കുന്നു. സെർവർ ഒരു Server-Sent Events (SSE⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)) സ്ട്രീം ഉപയോഗിച്ച് മറുപടി നൽകുന്നു. ഓരോ ഇവന്റിന്റെയും data ഒരു JSON പേലോഡാണ്, "type" കൊണ്ട് ആരംഭിക്കുന്ന "response" ഉള്ളത്. ഇത് ഇതുപോലെയൊന്നാകാം (ഇവന്റുകളുടെ പൂർണ്ണ പട്ടിക ഞങ്ങളുടെ API ഡോക്യുമെന്റുകളിൽ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ലഭ്യമാണ്):

പ്ലെയിൻ ടെക്സ്റ്റ്

1data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4data: {"type":"response.output_item.added", "item":{...}}
5data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6data: {"type":"response.output_text.delta", "delta":"two!", ...}
7data: {"type":"response.completed","response":{...}}

Codex ഇവന്റുകളുടെ സ്ട്രീം ഉപയോഗിക്കുന്നു⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) കൂടാതെ അവയെ ഒരു ഉപഭോക്താവിന് ഉപയോഗിക്കാനാകുന്ന ആന്തരിക ഇവന്റ് ഒബ്ജക്റ്റുകളായി വീണ്ടും പ്രസിദ്ധീകരിക്കുന്നു. response.output_text.delta പോലുള്ള ഇവന്റുകൾ UI-യിൽ സ്ട്രീമിംഗ് പിന്തുണയ്ക്കാൻ ഉപയോഗിക്കുന്നു, എന്നാൽ response.output_item.added പോലുള്ള മറ്റ് ഇവന്റുകൾ ഒബ്ജക്റ്റുകളാക്കി മാറ്റി input -ലേക്ക് ചേർക്കുന്നു, തുടർന്ന് വരുന്ന Responses API കോളുകൾക്കായി.

Responses API-യിലേക്കുള്ള ആദ്യ അഭ്യർത്ഥനയിൽ രണ്ട് response.output_item.done ഇവന്റുകൾ ഉൾപ്പെടുന്നുവെന്ന് കരുതുക: ഒന്ന് type=റീസണിംഗ് ഉള്ളതും ഒന്ന് type=function_call ഉള്ളതും. ഉപകരണ കോൾ-ലേക്കുള്ള പ്രതികരണത്തോടെ ഞങ്ങൾ മോഡലിനെ വീണ്ടും ക്വറി ചെയ്യുമ്പോൾ, ഈ ഇവന്റുകൾ JSON-ന്റെ input ഫീൽഡിൽ പ്രതിനിധീകരിക്കപ്പെടണം:

JavaScript

1[
2  /* ... original 5 items from the input array ... */
3  {
4    "type": "reasoning",
5    "summary": [
6      "type": "summary_text",
7      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8    ],
9    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10  },
11  {
12    "type": "function_call",
13    "name": "shell",
14    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15    "call_id": "call_8675309..."
16  },
17  {
18    "type": "function_call_output",
19    "call_id": "call_8675309...",
20    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21  }
22]

തുടർന്നുള്ള ക്വറിയുടെ ഭാഗമായി മോഡലിനെ സാമ്പിൾ ചെയ്യാൻ ഉപയോഗിക്കുന്ന പ്രോംപ്റ്റ് ഇങ്ങനെ കാണപ്പെടും:

ഒരു ടൂൾ കോൾ കഴിഞ്ഞ് AI ഏജന്റ് കാണിക്കുന്ന “Snapshot 2” എന്ന് ലേബൽ ചെയ്ത ഡയഗ്രാം. മോഡൽ ഒരു ഉപകരണ നിരീക്ഷണം സ്വീകരിച്ച് ഒരു പുതിയ ചിന്തയും പ്രവർത്തനവും സൃഷ്ടിക്കുന്നു. ഏജന്റിന്റെ റീസണിംഗ് ലൂപ്പ് എങ്ങനെ ആവർത്തിക്കുന്നു എന്ന് കാണിക്കാൻ ഇൻപുട്ടുകൾ, നിരീക്ഷണങ്ങൾ, ഔട്ട്പുട്ടുകൾ എന്നിവയെ അമ്പുകൾ ബന്ധിപ്പിക്കുന്നു.

പ്രത്യേകിച്ച്, പഴയ പ്രോംപ്റ്റ് പുതിയ പ്രോംപ്റ്റിന്റെ കൃത്യമായ പ്രിഫിക്സാണ് എന്നത് ശ്രദ്ധിക്കുക. ഇത് ഉദ്ദേശപൂർവ്വമാണ്, കാരണം ഇത് തുടർന്നുള്ള അഭ്യർത്ഥനകൾ കൂടുതൽ കാര്യക്ഷമമാക്കുന്നു, കാരണം ഇത് ഞങ്ങൾക്ക് പ്രോംപ്റ്റ് കാഷിംഗ് പ്രയോജനപ്പെടുത്താൻ അനുവദിക്കുന്നു (പ്രകടനത്തെക്കുറിച്ചുള്ള അടുത്ത വിഭാഗത്തിൽ ഇത് ഞങ്ങൾ ചർച്ച ചെയ്യും).

ഏജന്റ് ലൂപ്പിന്റെ ആദ്യ ഡയഗ്രാമിലേക്ക് തിരിഞ്ഞുനോക്കുമ്പോൾ, നാം ഇൻഫറൻസിനും ഉപകരണ വിളിക്കലിനും ഇടയിൽ നിരവധി ആവർത്തനങ്ങൾ ഉണ്ടാകാമെന്ന് കാണുന്നു. അസിസ്റ്റന്റിന്റെ സന്ദേശം ലഭിച്ച് ടേൺ അവസാനിക്കുന്നതായി സൂചിപ്പിക്കുന്നതുവരെ പ്രോംപ്റ്റ് തുടർച്ചയായി വളരാൻ സാധ്യതയുണ്ട്:

പ്ലെയിൻ ടെക്സ്റ്റ്

1data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2data: {"type":"response.completed","response":{...}}

Codex CLI-യിൽ, ഞങ്ങൾ അസിസ്റ്റന്റിന്റെ സന്ദേശം ഉപയോക്താവിന് കാണിക്കുകയും, ഉപയോക്താവിന് അവരുടെ “മറുപടി” നൽകാനുള്ള സമയമാണെന്ന് സൂചിപ്പിക്കാൻ കോംപോസറിന് ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയും ചെയ്യുന്നു. ഉപയോക്താവ് പ്രതികരിക്കുകയാണെങ്കിൽ, പുതിയ ടേൺ ആരംഭിക്കാൻ Responses API അഭ്യർത്ഥനയിലെ input -ലേക്ക് മുൻ ടേണിലെ അസിസ്റ്റന്റ് സന്ദേശവും ഉപയോക്താവിന്റെ പുതിയ സന്ദേശവും രണ്ടും ചേർക്കണം:

JavaScript

1[
2  /* ... all items from the last Responses API request ... */
3  {
4    "type": "message",
5    "role": "assistant",
6    "content": [
7      {
8        "type": "output_text",
9        "text": "I added a diagram to explain the client/server architecture."
10      }
11    ]
12  },
13  {
14    "type": "message",
15    "role": "user",
16    "content": [
17      {
18        "type": "input_text",
19        "text": "That's not bad, but the diagram is missing the bike shed."
20      }
21    ]
22  }
23]

വീണ്ടും, ഞങ്ങൾ ഒരു സംഭാഷണം തുടരുന്നതിനാൽ, Responses API-യിലേക്ക് അയക്കുന്ന input -ന്റെ നീളം തുടർച്ചയായി വർധിക്കുന്നു:

AI ഏജന്റ് ലൂപ്പിന്റെ അന്തിമ ഘട്ടം കാണിക്കുന്ന “Snapshot 3” എന്ന് ലേബൽ ചെയ്ത ചിത്രം. ടൂൾ ഫലങ്ങൾ ലഭിച്ചതിന് ശേഷം, മോഡൽ ഒരു സമാപന ചിന്തയും ഉപയോക്താവിന് തിരികെ നൽകുന്ന അന്തിമ ഉത്തരവും സൃഷ്ടിക്കുന്നു. അമ്പുകൾ ടൂൾ ഔട്ട്പുട്ടിൽ നിന്ന് പൂർത്തിയായ പ്രതികരണത്തിലേക്കുള്ള മാറ്റം ചിത്രീകരിക്കുന്നു.

ഈ എപ്പോഴും വളരുന്ന പ്രോംപ്റ്റ് പ്രകടനത്തിന്‍റെ കാര്യത്തില്‍ എന്താണ് സൂചിപ്പിക്കുന്നത് എന്ന് പരിശോധിക്കാം.

പ്രകടന പരിഗണനകൾ

നിങ്ങൾ സ്വയം ചോദിച്ചേക്കാം, “കാത്തിരിക്കൂ, സംഭാഷണത്തിന്റെ ദൈർഘ്യത്തിൽ Responses API-യിലേക്ക് അയക്കുന്ന JSON-ന്റെ അളവിന്റെ കാര്യത്തിൽ ഏജന്റ് ലൂപ്പ് ക്വാഡ്രാറ്റിക് അല്ലേ?” നിങ്ങൾ പറഞ്ഞത് ശരിയാകാം. Responses API ഒരു ഓപ്ഷണൽ previous_response_id⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) പാരാമീറ്റർ പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിലും, ഈ പ്രശ്നം കുറയ്ക്കുന്നതിനായി, Codex ഇന്ന് അത് ഉപയോഗിക്കുന്നില്ല, പ്രധാനമായും അഭ്യർത്ഥനകൾ പൂർണ്ണമായും സ്റ്റേറ്റ്‌ലെസ് ആയി നിലനിർത്താനും സീറോ ഡാറ്റ റിട്ടെൻഷൻ (ZDR) കോൺഫിഗറേഷനുകൾ പിന്തുണയ്ക്കാനും.

previous_response_id ഒഴിവാക്കുന്നത് Responses API-യുടെ പ്രൊവൈഡറിന് കാര്യങ്ങൾ ലളിതമാക്കുന്നു, കാരണം അത് ഓരോ അഭ്യർത്ഥനയും stateless ആണെന്ന് ഉറപ്പാക്കുന്നു. സീറോ ഡാറ്റ റിട്ടെൻഷൻ (ZDR)⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) തിരഞ്ഞെടുക്കുന്ന ഉപഭോക്താക്കളെ പിന്തുണയ്ക്കുന്നത് ലളിതമാണ്, കാരണം previous_response_id പിന്തുണയ്ക്കാൻ ആവശ്യമായ ഡാറ്റ സംഭരിക്കുന്നത് ZDR-നോട് വിരുദ്ധമാണ്. ZDR ഉപഭോക്താക്കൾക്ക് മുൻ ടേണുകളിൽ നിന്നുള്ള ഉടമസ്ഥാവകാശ റീസണിംഗ് സന്ദേശങ്ങളിൽ നിന്ന് പ്രയോജനം നേടാനുള്ള കഴിവ് നഷ്ടപ്പെടുന്നില്ലെന്ന് ശ്രദ്ധിക്കുക, കാരണം ബന്ധപ്പെട്ട encrypted_content സർവറിൽ ഡീക്രിപ്റ്റ് ചെയ്യാൻ കഴിയും. (OpenAI ഒരു ZDR ഉപഭോക്താവിന്റെ ഡീക്രിപ്ഷൻ കീ നിലനിർത്തുന്നു, അവരുടെ ഡാറ്റ നിലനിര്‍ത്തുന്നില്ല.) ZDR പിന്തുണയ്ക്കുന്നതിനായി Codex-ലേക്കുള്ള ബന്ധപ്പെട്ട മാറ്റങ്ങൾ കാണാൻ PRs #642⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉം #1641⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉം കാണുക.

പൊതുവെ, മോഡലിന്റെ സാമ്പിളിംഗ് ചെലവ് നെറ്റ്‌വർക്ക് ട്രാഫിക്കിന്റെ ചെലവിനെക്കാൾ കൂടുതലാണ്, അതിനാൽ സാമ്പിളിംഗ് ഞങ്ങളുടെ കാര്യക്ഷമതാ ശ്രമങ്ങളുടെ പ്രധാന ലക്ഷ്യമാണ്. ഇതിനാലാണ് പ്രോംപ്റ്റ് കാഷിംഗ് അത്ര പ്രധാനപ്പെട്ടത്, കാരണം ഇത് മുൻ ഇൻഫറൻസ് കോളിൽ നിന്നുള്ള കംപ്യൂട്ടേഷൻ വീണ്ടും ഉപയോഗിക്കാൻ ഞങ്ങളെ പ്രാപ്തരാക്കുന്നു. കാഷെ ഹിറ്റുകൾ ലഭിക്കുമ്പോൾ, മോഡലിന്റെ സാമ്പിളിംഗ് ലീനിയർ ആണ്, ക്വാഡ്രാറ്റിക് അല്ല. ഞങ്ങളുടെ പ്രോംപ്റ്റ് കാഷിംഗ് ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)ഡോക്യുമെന്റേഷൻ ഇത് കൂടുതൽ വിശദമായി വിശദീകരിക്കുന്നു:

ഒരു പ്രോംപ്റ്റിനുള്ളിൽ കൃത്യമായ പൊരുത്തങ്ങൾ ഉണ്ടെങ്കിലെ പ്രിഫിക്സ് കാഷെ ഹിറ്റുകൾ സാധ്യമാകൂ. കാഷിംഗ് പ്രയോജനങ്ങൾ നേടാൻ, നിർദ്ദേശങ്ങളും ഉദാഹരണങ്ങളും പോലുള്ള സ്ഥിരമായ ഉള്ളടക്കം നിങ്ങളുടെ പ്രോംപ്റ്റിന്റെ തുടക്കത്തിൽ വയ്ക്കുക, ഉപയോക്താവിനിഷ്ടമായ വിവരങ്ങൾ പോലുള്ള വ്യത്യാസമുള്ള ഉള്ളടക്കം അവസാനം വയ്ക്കുക. ഇത് ചിത്രങ്ങൾക്കും ഉപകരണങ്ങൾക്കും ബാധകമാണ്; അവ അഭ്യർത്ഥനകൾക്കിടയിൽ ഒരുപോലെ ആയിരിക്കണം.

ഇത് മനസ്സിൽ വെച്ച്, Codex-ൽ “കാഷെ മിസ്” ഉണ്ടാക്കാൻ സാധ്യതയുള്ള പ്രവർത്തനങ്ങളുടെ തരം പരിഗണിക്കാം:

സംഭാഷണത്തിന്റെ മധ്യേ മോഡലിന് ലഭ്യമായ tools മാറ്റുക.
Responses API അഭ്യർത്ഥനയുടെ ലക്ഷ്യമായ model മാറ്റുന്നത് (പ്രായോഗികമായി, ഇത് യഥാർത്ഥ പ്രോംപ്റ്റിലെ മൂന്നാമത്തെ ഇനം മാറ്റുന്നു, കാരണം അതിൽ മോഡൽ-നിർദ്ദിഷ്ട നിർദ്ദേശങ്ങൾ അടങ്ങിയിരിക്കുന്നു).
സാൻഡ്‌ബോക്സ് കോൺഫിഗറേഷൻ, അംഗീകാര മോഡ്, അല്ലെങ്കിൽ നിലവിലെ പ്രവർത്തന ഡയറക്ടറി മാറ്റൽ.

Codex CLI-യിൽ പ്രോംപ്റ്റ് കാഷിംഗ് അപകടത്തിലാക്കാൻ സാധ്യതയുള്ള പുതിയ സവിശേഷതകൾ അവതരിപ്പിക്കുമ്പോൾ Codex ടീം ജാഗ്രത പാലിക്കണം. ഉദാഹരണത്തിന്, MCP ഉപകരണങ്ങൾക്കായുള്ള ഞങ്ങളുടെ പ്രാരംഭ പിന്തുണ ഒരു ബഗ് അവതരിപ്പിച്ചു, അതിൽ ഉപകരണങ്ങളെ സ്ഥിരതയുള്ള ക്രമത്തിൽ പട്ടികപ്പെടുത്തുന്നതിൽ ഞങ്ങൾ പരാജയപ്പെട്ടു⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), അതിനാൽ കാഷ് മിസുകൾ ഉണ്ടായി. MCP ടൂളുകൾ പ്രത്യേകിച്ച് ബുദ്ധിമുട്ടുള്ളവയായിരിക്കാമെന്ന് ശ്രദ്ധിക്കുക, കാരണം MCP സെർവറുകൾക്ക് notifications/tools/list_changed⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) അറിയിപ്പിലൂടെ അവർ നൽകുന്ന ടൂളുകളുടെ പട്ടിക തത്സമയം മാറ്റാൻ കഴിയും. ഒരു ദീർഘമായ സംഭാഷണത്തിന്റെ മധ്യേ ഈ അറിയിപ്പ് മാനിക്കുന്നത് ചെലവേറിയ ഒരു കാഷെ മിസിന് കാരണമാകാം.

സാധ്യമാകുമ്പോഴെല്ലാം, സംഭാഷണത്തിനിടയിൽ സംഭവിക്കുന്ന കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ ഞങ്ങൾ കൈകാര്യം ചെയ്യുന്നത്, മുമ്പത്തെ സന്ദേശം പരിഷ്കരിക്കുന്നതിനുപകരം മാറ്റം പ്രതിഫലിപ്പിക്കുന്നതിനായി input ലേക്ക്ഒരു പുതിയസന്ദേശം ചേർത്തുകൊണ്ടാണ്:

കോൺഫിഗറേഷൻ അല്ലെങ്കിൽ അംഗീകാര മോഡ് മാറുകയാണെങ്കിൽ,ഞങ്ങൾ ഒരു പുതിയ സന്ദേശം ചേർക്കുന്നു⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) അത് role=developer ഫോർമാറ്റിലും യഥാർത്ഥ <permissions instructions> ഇനത്തിന്റേതുപോലെ തന്നെയുള്ളതുമായിരിക്കും.
നിലവിലെ പ്രവർത്തന ഡയറക്ടറി മാറുകയാണെങ്കിൽ, ഞങ്ങള്‍ ചേർക്കുന്ന⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഒരു പുതിയ role=user സന്ദേശം <environment_context>-ന്റെ അതെ ഫോര്‍മാറ്റില്‍ ഉള്ളത് ആയിരിക്കും.

പ്രകടനം ഉറപ്പാക്കാൻ കാഷെ ഹിറ്റുകൾ ലഭ്യമാക്കുന്നതിന് ഞങ്ങൾ വലിയ പരിശ്രമം നടത്തുന്നു. നമുക്ക് നിയന്ത്രിക്കേണ്ട മറ്റൊരു പ്രധാന വിഭവമുണ്ട്: കോൺടെക്സ്റ്റ് വിൻഡോ.

സന്ദർഭ വിൻഡോ തീരാതിരിക്കാൻ ഞങ്ങളുടെ പൊതുവായ തന്ത്രം, ടോക്കൺ-കളുടെ എണ്ണം ഒരു നിശ്ചിത പരിധി കവിയുമ്പോൾ സംഭാഷണം സംക്ഷിപ്തമാക്കുക എന്നതാണ്. പ്രത്യേകിച്ച്, സംഭാഷണത്തെ പ്രതിനിധീകരിക്കുന്ന പുതിയതും ചെറുതുമായ ഇനങ്ങളുടെ പട്ടികയോടെ ഞങ്ങൾ input മാറ്റിസ്ഥാപിക്കുന്നു, ഇതിലൂടെ ഇതുവരെ സംഭവിച്ച കാര്യങ്ങൾ മനസ്സിലാക്കി ഏജന്റിന് തുടരാൻ കഴിയും. കോംപാക്ഷന്റെ ഒരു പ്രാരംഭ ഇംപ്ലിമെന്റേഷൻ സംക്ഷിപ്തമാക്കുന്നതിന്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉപയോക്താവിനോട് /compact കമാൻഡ് കൈമാറി വിളിക്കണമെന്ന് ആവശ്യപ്പെട്ടു, ഇത് നിലവിലുള്ള സംഭാഷണത്തോടൊപ്പം ഇഷ്ടാനുസൃത നിർദ്ദേശങ്ങൾ ചേർത്ത് Responses API-യെ സംഗ്രഹണത്തിനായി⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ക്വറി ചെയ്യും. Codex സംഗ്രഹം അടങ്ങിയ അസിസ്റ്റന്റിന്റെ ഫലമായ സന്ദേശം പുതിയ ഇൻപുട്ട്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആയി തുടർന്നുള്ള സംഭാഷണ ചുരുക്കങ്ങൾക്കായി ഉപയോഗിച്ചു.

അതിനുശേഷം, Responses API കൂടുതൽ കാര്യക്ഷമമായി സംക്ഷിപ്തമാക്കല്‍ നടത്തുന്നതിനായി ഒരു പ്രത്യേക /responses/compact എൻഡ്‌പോയിന്റ്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) പിന്തുണയ്ക്കുന്ന തരത്തിൽ വികസിച്ചു. ഇത് ഇനങ്ങളുടെ പട്ടിക⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) തിരികെ നൽകുന്നു, ഇത് മുൻപത്തെ input -ന് പകരമായി സംഭാഷണം തുടരാൻ ഉപയോഗിക്കാം, അതേസമയം സന്ദർഭ വിൻഡോയിൽ സ്ഥലം ഒഴിവാക്കുന്നു. ഈ പട്ടികയിൽ ഒരു പ്രത്യേക type=compaction ഇനം ഉൾപ്പെടുന്നു, അതിൽ ഒരു അപ്രത്യക്ഷമായ encrypted_content ഇനം ഉൾപ്പെടുന്നു, അത് മൂല സംഭാഷണത്തെക്കുറിച്ചുള്ള മോഡലിന്റെ ഗൂഢമായ മനസ്സിലാക്കൽ സംരക്ഷിക്കുന്നു. ഇപ്പോൾ, Codex auto_compact_limit⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) അതിക്രമിക്കുമ്പോൾ സംഭാഷണം കോംപാക്റ്റ് ചെയ്യാൻ യാന്ത്രികമായി ഈ എൻഡ്‌പോയിന്റ് ഉപയോഗിക്കുന്നു.

അടുത്തതായി

ഞങ്ങൾ Codex ഏജന്റ് ലൂപ്പ് പരിചയപ്പെടുത്തി, മോഡലിനെ ക്വറി ചെയ്യുമ്പോൾ Codex എങ്ങനെ തന്റെ കോൺടെക്സ്റ്റ് രൂപപ്പെടുത്തുകയും നിയന്ത്രിക്കുകയും ചെയ്യുന്നു എന്നതിനെക്കുറിച്ച് വിശദീകരിച്ചു. ഈ യാത്രയ്ക്കിടയിൽ, Responses API-യുടെ മുകളിൽ ഒരു ഏജന്റ് ലൂപ്പ് നിർമ്മിക്കുന്ന ഏവർക്കും ബാധകമായ പ്രായോഗിക പരിഗണനകളും മികച്ച രീതികളും ഞങ്ങൾ പ്രദർശിപ്പിച്ചു.

ഏജന്റ് ലൂപ്പ് കോഡെക്സ്‌ക്ക് അടിത്തറ നൽകുന്നുവെങ്കിലും, ഇത് വെറും തുടക്കമാണ്. വരാനിരിക്കുന്ന പോസ്റ്റുകളിൽ, ഞങ്ങൾ CLI-യുടെ ആർക്കിടെക്ചറിനെക്കുറിച്ച് കൂടുതൽ ആഴത്തിൽ പഠിക്കും, ടൂൾ ഉപയോഗം എങ്ങനെ നടപ്പിലാക്കുന്നുവെന്ന് പരിശോധിക്കും, കൂടാതെ Codex-ന്റെ സാൻഡ്ബോക്സിംഗ് മോഡലിനെ കൂടുതൽ സൂക്ഷ്മമായി പരിശോധിക്കും.

രചയിതാവ്

Michael Bolin

അംഗീകാരങ്ങൾ

Codex CLI നിർമ്മിച്ച മുഴുവൻ ടീമിന് പ്രത്യേക നന്ദി.

വായന തുടരുക

എല്ലാം കാണുക

Codex ഉപയോഗിച്ച് സ്വയം-മെച്ചപ്പെടുന്ന നികുതി ഏജന്റുകൾ നിർമ്മിക്കൽ

എഞ്ചിനീയറിംഗ്2026 മേയ് 27

Windows-ൽ Codex പ്രവർത്തനക്ഷമമാക്കാൻ സുരക്ഷിതവും ഫലപ്രദവുമായ സാൻഡ്ബോക്സ് നിർമ്മിക്കൽ

എഞ്ചിനീയറിംഗ്2026 മേയ് 13

Supercomputer networking to accelerate large scale AI training

എഞ്ചിനീയറിംഗ്2026 മേയ് 5