U bood nuxurka ugu muhiimsan
OpenAI

Janaayo 23, 2026

Injineernimada

Unrolling the Codex agent loop

By Michael Bolin, Member of the Technical Staff

Soo kacaya…

Codex CLI⁠(ku furmaa daaqad cusub) is our cross-platform local software agent, designed to produce high-quality, reliable software changes while operating safely and efficiently on your machine. We’ve learned a tremendous amount about how to build a world-class software agent since we first launched the CLI in April⁠. To unpack those insights, this is the first post in an ongoing series where we’ll explore various aspects of how Codex works, as well as hard-earned lessons. (For an even more granular view on how the Codex CLI is built, check out our open source repository at https://github.com/openai/codex⁠(ku furmaa daaqad cusub). Many of the finer details of our design decisions are memorialized in GitHub issues and pull requests if you’d like to learn more.)

To kick off, we’ll focus on the agent loop, which is the core logic in Codex CLI that is responsible for orchestrating the interaction between the user, the model, and the tools the model invokes to perform meaningful software work. We hope this post gives you a good view into the role our agent (or “harness”) plays in making use of an LLM.

Before we dive in, a quick note on terminology: at OpenAI, “Codex” encompasses a suite of software agent offerings, including Codex CLI, Codex Cloud, and the Codex VS Code extension. This post focuses on the Codex harness, which provides the core agent loop and execution logic that underlies all Codex experiences and is surfaced through the Codex CLI. For ease here, we’ll use the terms “Codex” and “Codex CLI” interchangeably.

The agent loop

At the heart of every AI agent is something called “the agent loop.” A simplified illustration of the agent loop looks like this:

Jaantus cinwaankiisu yahay “Wareegga wakiilka” oo muujinaya sida nidaam AI ahi u farsameeyo codsiga isticmaalaha, u yeedho qalab, u arko natiijooyin, u cusboonaysiiyo qorshihiisa, una soo celiyo wax-soo-saar. Fallaaruhu waxay isku xiraan tallaabooyin sida gelinta isticmaalaha, caqliyeynta nooca, ficillada qalabka, iyo jawaabta kama dambaysta ah.

To start, the agent takes input from the user to include in the set of textual instructions it prepares for the model known as a prompt.

The next step is to query the model by sending it our instructions and asking it to generate a response, a process known as inference. During inference, the textual prompt is first translated into a sequence of input tokens⁠(ku furmaa daaqad cusub)—integers that index into the model’s vocabulary. These tokens are then used to sample the model, producing a new sequence of output tokens.

The output tokens are translated back into text, which becomes the model’s response. Because tokens are produced incrementally, this translation can happen as the model runs, which is why many LLM-based applications display streaming output. In practice, inference is usually encapsulated behind an API that operates on text, abstracting away the details of tokenization.

As the result of the inference step, the model either (1) produces a final response to the user’s original input, or (2) requests a tool call that the agent is expected to perform (e.g., “run ls and report the output”). In the case of (2), the agent executes the tool call and appends its output to the original prompt. This output is used to generate a new input that’s used to re-query the model; the agent can then take this new information into account and try again.

This process repeats until the model stops emitting tool calls and instead produces a message for the user (referred to as an assistant message in OpenAI models). In many cases, this message directly answers the user’s original request, but it may also be a follow-up question for the user.

Because the agent can execute tool calls that modify the local environment, its “output” is not limited to the assistant message. In many cases, the primary output of a software agent is the code it writes or edits on your machine. Nevertheless, each turn always ends with an assistant message—such as “I added the architecture.md you asked for”—which signals a termination state in the agent loop. From the agent’s perspective, its work is complete and control returns to the user.

The journey from user input to agent response shown in the diagram is referred to as one turn of a conversation (a thread in Codex). Though this conversation turn can include many iterations between the model inference and tool calls. Every time you send a new message to an existing conversation, the conversation history is included as part of the prompt for the new turn, which includes the messages and tool calls from previous turns:

Jaantus cinwaankiisu yahay “Wareegga wakiilka ee wareegyo badan” oo muujinaya sida wakiil AI ahi si soo noqnoqota u qaato gelinta isticmaalaha, u abuuro ficillo, ula tashado qalab, u cusboonaysiiyo xaalad, una soo celiyo natiijooyin. Waxaa ku jira tallaabooyin summadaysan, fallaaro, iyo tusaalooyin soo-saarka qalab oo muujinaya wareegga caqliyeynta wakiilka.

This means that as the conversation grows, so does the length of the prompt used to sample the model. This length matters because every model has a context window, which is the maximum number of tokens it can use for one inference call. Note this window includes both input and output tokens. As you might imagine, an agent could decide to make hundreds of tool calls in a single turn, potentially exhausting the context window. For this reason, context window management is one of the agent’s many responsibilities. Now, let’s dive in to see how Codex runs the agent loop.

Model inference

The Codex CLI sends HTTP requests to the Responses API⁠(ku furmaa daaqad cusub) to run model inference. We’ll examine how information flows through Codex, which uses the Responses API to drive the agent loop.

The Responses API endpoint that the Codex CLI uses is configurable⁠(ku furmaa daaqad cusub), so it can be used with any endpoint that implements the Responses API⁠(ku furmaa daaqad cusub):

Let’s explore how Codex creates the prompt for the first inference call in a conversation.

Building the initial prompt

As an end user, you don’t specify the prompt used to sample the model verbatim when you query the Responses API. Instead, you specify various input types as part of your query, and the Responses API server decides how to structure this information into a prompt that the model is designed to consume. You can think of the prompt as a “list of items”; this section will explain how your query gets transformed into that list.

In the initial prompt, every item in the list is associated with a role. The role indicates how much weight the associated content should have and is one of the following values (in decreasing order of priority): system, developer, user, assistant.

The Responses API⁠(ku furmaa daaqad cusub) takes a JSON payload with many parameters. We’ll focus on these three:

In Codex, the instructions field is read from the model_instructions_file⁠(ku furmaa daaqad cusub) in ~/.codex/config.toml, if specified; otherwise, the base_instructions associated with a model⁠(ku furmaa daaqad cusub) are used. Model-specific instructions live in the Codex repo and are bundled into the CLI (e.g., gpt-5.2-codex_prompt.md⁠(ku furmaa daaqad cusub)).

The tools field is a list of tool definitions that conform to a schema defined by the Responses API. For Codex, this includes tools that are provided by the Codex CLI, tools that are provided by the Responses API that should be made available to Codex, as well as tools provided by the user, usually via 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
]

Finally, the input field of the JSON payload is a list of items. Codex inserts the following items⁠(ku furmaa daaqad cusub) into the input before adding the user message:

1. A message with role=developer that describes the sandbox that applies only to the Codex-provided shell tool defined in the tools section. That is, other tools, such as those provided from MCP servers, are not sandboxed by Codex and are responsible for enforcing their own guardrails.

The message is built from a template where the key pieces of content come from snippets of Markdown bundled into the Codex CLI, such as workspace_write.md⁠(ku furmaa daaqad cusub) and on_request.md⁠(ku furmaa daaqad cusub):

Qoraal caadi ah

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. (Optional) A message with role=developer whose contents are the developer_instructions value read from the user’s config.toml file.

3. (Optional) A message with role=user whose contents are the “user instructions,” which are not sourced from a single file but are aggregated across multiple sources⁠(ku furmaa daaqad cusub). In general, more specific instructions appear later:

4. A message with role=user that describes the local environment in which the agent is currently operating. This specifies the current working directory and the user’s shell⁠(ku furmaa daaqad cusub):

Qoraal caadi ah

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

Marka Codex sameeyo dhammaan xisaabinta kor ku xusan si uu u bilaabo input, wuxuu ku daraa fariinta isticmaalaha si loo bilaabo wada-sheekeysiga.

Tusaalooyinkii hore waxay diiradda saareen nuxurka fariin kasta, laakiin ogow in walax kasta oo ka mid ah input ay tahay shay JSON ah oo leh type, role⁠(ku furmaa daaqad cusub), iyo content sida soo socota:

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
}

Marka Codex dhiso culeyska JSON oo dhan ee loo diri doono Responses API, wuxuu markaa sameeyaa codsiga HTTP POST isagoo wata madax Authorization iyadoo ku xiran sida bar-dhammaadka Responses API loogu habeeyey ~/.codex/config.toml (madaxyo HTTP dheeraad ah iyo halbeegyo query ah ayaa lagu daraa haddii la qeexay).

Marka server-ka OpenAI Responses API helo codsiga, wuxuu u adeegsadaa JSON-ka inuu ka soo saaro weydiinta nooca sida soo socota (si cad, hirgelin gaar ah oo Responses API ahi waxay samayn kartaa doorasho ka duwan):

Jaantus muuqaal ah oo muujinaya hal tallaabo oo ka mid ah wareegga wakiilka AI. Codsiga isticmaaluhu wuxuu galaa nooca, kaas oo soo saara fikir, ficil wata magac qalab, iyo gelin qalab. Jaantusku wuxuu iftiiminayaa tallaabadan dhexe ee caqliyeynta ka hor inta aan qalabka la yeedhin.

Sida aad arki karto, kala horreynta saddexda walxood ee ugu horreeya ee weydiinta waxaa go’aamiya server-ka, ma aha macmiilka. Taasi marka la yiraahdo, saddexdaas walxood dhexdooda, kaliya nuxurka fariinta system-ka ayaa sidoo kale uu xakameeyo server-ku, maaddaama tools iyo instructions uu go’aamiyo macmiilku. Kuwaas waxaa ku xiga input-ka ka yimid culeyska JSON si loo dhammaystiro weydiinta.

Hadda oo aan haysanno weydiinteena, waxaan diyaar u nahay inaan muunadayno nooca.

Wareegga koowaad

Codsigan HTTP ee ku wajahan Responses API wuxuu bilaabaa “wareegga” koowaad ee wada-sheekeysi gudaha Codex. Server-ku wuxuu ku jawaabaa qulqul Server-Sent Events (SSE⁠(ku furmaa daaqad cusub)) ah. data-ga dhacdo kasta waa culeys JSON ah oo leh "type" ka bilaabma "response", taas oo noqon karta wax sidan u eg (liis buuxa oo dhacdooyinka ah waxaa laga heli karaa dukumentiyada API⁠(ku furmaa daaqad cusub)):

Qoraal caadi ah

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

Codex wuxuu qaataa qulqulka dhacdooyinka⁠(ku furmaa daaqad cusub) wuxuuna dib ugu daabacaa sida walxo dhacdo gudaha ah oo uu macmiil isticmaali karo. Dhacdooyinka sida response.output_text.delta waxaa loo adeegsadaa taageeridda qulqulka gudaha UI, halka dhacdooyin kale sida response.output_item.added loo beddelo walxo lagu daro input ee wicitaannada xiga ee Responses API.

Aan ka soo qaadno in codsiga ugu horreeya ee Responses API uu ku jiro laba dhacdo oo response.output_item.done: mid leh type=reasoning iyo mid leh type=function_call. Dhacdooyinkan waa in lagu matalaa goobta input ee JSON marka aan mar kale nooca waydiinayno annagoo wata jawaabta yeedhidda qalabka: 

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
]

Weydiinta ka dhalanaysa ee loo adeegsado muunadaynta nooca qayb ka ah waydiinta xigta waxay u ekaan lahayd sidan:

Jaantus lagu calaamadeeyey “Snapshot 2” oo muujinaya wakiil AI ah ka dib yeedhid qalab. Noocku wuxuu helaa u-kuurgal qalab wuxuuna soo saaraa fikir iyo ficil cusub. Fallaaruhu waxay isku xiraan gelinnada, u-kuurgallada, iyo soo-saarrada si loo muujiyo sida wakiilku ugu celceliyo wareeggiisa caqliyeynta.

Gaar ahaan, ogow sida weydiintii hore ay u tahay hordhac sax ah oo weydiinta cusub ah. Tani waa ula kac, maadaama ay codsiyada xiga ka dhigeyso kuwo aad uga waxtar badan sababtoo ah waxay noo suurtagelinaysaa inaan ka faa’iidaysanno kaydinta weydiinta (taas oo aan kaga hadli doonno qaybta xigta ee waxqabadka).

Markaan dib u eegno jaantuskeennii koowaad ee wareegga wakiilka, waxaan aragnaa in ay jiri karaan ku celcelin badan oo u dhexeeya inferens-ka iyo yeedhidda qalabka. Weydiintu way sii kori kartaa ilaa aan ugu dambayn helno assistant message, taas oo muujinaysa dhammaadka wareegga:

Qoraal caadi ah

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

Gudaha Codex CLI, waxaan u soo bandhignaa assistant message-ka isticmaalaha waxaana diiradda saarnaa curiyaha si aan isticmaalaha ugu muujinno inay tahay “wareeggiisa” inuu sii wado wada-sheekeysiga. Haddii isticmaaluhu ka jawaabo, assistant message-kii wareeggii hore, iyo sidoo kale fariinta cusub ee isticmaalaha, waa in lagu daraa input codsiga Responses API si loo bilaabo wareegga cusub:

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
]

Mar kale, sababtoo ah waxaan sii wadnaa wada-sheekeysi, dhererka input ee aan u dirno Responses API wuu sii kordhayaa:

Jaantus lagu calaamadeeyey “Snapshot 3” oo muujinaya marxaladda ugu dambaysa ee wareegga wakiilka AI. Ka dib marka uu helo natiijooyinka qalabka, noocku wuxuu abuuraa fikir gunaanad ah iyo jawaab kama dambays ah oo loo celiyo isticmaalaha. Fallaaruhu waxay muujinayaan kala guurka ka imanaya soo-saarka qalabka una gudbaya jawaab dhammaystiran.

Aan eegno waxa weydiintan sii koraysaa uga dhigan tahay waxqabadka.

Tixgelinno waxqabad

Waxaad laga yaabaa inaad is weydiiso, “Sug, miyaan wareegga wakiilku ahayn laba-jibbaar marka loo eego qaddarka JSON-ka loo diro Responses API muddada wada-sheekeysiga?” Waadna saxnaan lahayd. In kasta oo Responses API uu taageero halbeeg ikhtiyaari ah oo ah previous_response_id⁠(ku furmaa daaqad cusub) si loo yareeyo dhibaatadan, Codex maanta ma isticmaalo, badanaa si codsiyada loo sii hayo kuwo gebi ahaanba aan xusuus ku dhisnayn iyo si loo taageero qaabeynta xog haynta eberka ah (ZDR).

Ka fogaanshaha previous_response_id waxay wax u fududaynaysaa bixiyaha Responses API sababtoo ah waxay xaqiijinaysaa in codsi kastaa yahay aan xusuus ku dhisnayn. Tani sidoo kale waxay ka dhigaysaa mid toos ah in la taageero macaamiisha doortay xog haynta eberka ah (ZDR)⁠(ku furmaa daaqad cusub), maadaama kaydinta xogta loo baahan yahay si loo taageero previous_response_id ay ka hor imanayso ZDR. Ogow in macaamiisha ZDR aysan lumin awoodda ay uga faa’iidaysanayaan fariimaha caqliyeynta lahaanshaha ah ee wareegyadii hore, maadaama encrypted_content-ka la xiriira lagu furfuri karo server-ka. (OpenAI waxay sii haysaa furaha furfuridda macaamilka ZDR, balse ma sii hayso xogtooda.) Eeg PR-yada #642⁠(ku furmaa daaqad cusub) iyo #1641⁠(ku furmaa daaqad cusub) si aad u aragto isbeddelladii la xiriiray ee lagu sameeyey Codex si loo taageero ZDR.

Guud ahaan, kharashka muunadaynta nooca ayaa ka badan kharashka taraafikada shabakadda, taas oo ka dhigaysa muunadaynta bartilmaameedka ugu weyn ee dadaalladayada hufnaanta. Tani waa sababta ay kaydinta weydiintu muhiim u tahay, maadaama ay noo suurtagelinayso inaan dib u isticmaalno xisaabinta inferens hore. Marka aan helno cache hits, muunadaynta noocku waa toosan tahay halkii ay laba-jibbaar ka ahaan lahayd. Dukumentiyadeenna kaydinta weydiinta ⁠(ku furmaa daaqad cusub) ayaa tan si faahfaahsan u sharxaya:

Cache hits waxay suurtagal u yihiin oo keliya marka hordhac sax ahi ku jiro weydiin gudaheeda. Si aad u hesho faa’iidooyinka kaydinta, dhig nuxurka joogtada ah sida tilmaamaha iyo tusaalooyinka bilowga weydiintaada, nuxurka isbeddelaya sida macluumaadka u gaarka ah isticmaalahana ku rid dhammaadka. Tani sidoo kale waxay khusaysaa sawirrada iyo qalabka, kuwaas oo ay tahay inay isku mid noqdaan inta u dhexeysa codsiyada.

Iyadoo taas maskaxda lagu hayo, aan tixgelinno noocyada hawlgallada keeni kara “cache miss” gudaha Codex:

  • Beddelidda tools ee uu noocku heli karo bartamaha wada-sheekeysiga.
  • Beddelidda model ee bartilmaameedka u ah codsiga Responses API (dhab ahaan, tani waxay beddeshaa walaxda saddexaad ee weydiintii asalka ahayd, maadaama ay ka kooban tahay tilmaamo u gaar ah nooca).
  • Beddelidda qaabeynta sandbox-ka, habka oggolaanshaha, ama galka shaqada ee hadda jira.

Kooxda Codex waa inay feejignaadaan marka ay ku daraan astaamo cusub gudaha Codex CLI kuwaas oo wax u dhimi kara kaydinta weydiinta. Tusaale ahaan, taageeradayadii bilowga ahayd ee qalabka MCP waxay keentay cilad ah inaanan qalabka u tirin si kala horreyn joogto ah leh⁠(ku furmaa daaqad cusub), taas oo sababtay cache misses. Ogow in qalabka MCP uu si gaar ah u adkaan karo sababtoo ah server-rada MCP waxay beddeli karaan liiska qalabka ay bixiyaan si duul ah iyagoo maraya ogeysiiska notifications/tools/list_changed⁠(ku furmaa daaqad cusub). Ixtiraamidda ogeysiiskan bartamaha wada-sheekeysi dheer waxay sababi kartaa cache miss qaali ah.

Marka ay suurtagal tahay, waxaan maareynnaa isbeddellada qaabeynta ee ka dhaca bartamaha wada-sheekeysiga annagoo ku darayna fariin cusub gudaha input si loo muujiyo isbeddelka halkii aan wax ka beddeli lahayn fariin hore:

  • Haddii qaabeynta sandbox-ka ama habka oggolaanshaha ay isbeddesho, waxaan gelinnaa⁠(ku furmaa daaqad cusub) fariin cusub oo role=developer ah oo leh isla qaabkii walaxdii asalka ahayd ee <permissions instructions>.
  • Haddii galka shaqada ee hadda jira is beddelo, waxaan gelinnaa⁠(ku furmaa daaqad cusub) fariin cusub oo role=user ah oo leh isla qaabkii <environment_context> ee asalka ahaa.

Waxaan dadaal badan gelinnaa xaqiijinta cache hits si loo helo waxqabad wanaagsan. Waxaa jira khayraad kale oo muhiim ah oo ay tahay inaan maamulno: daaqadda macnaha.

Istaraatiijiyaddayada guud ee looga fogaado dhammaadka daaqadda macnaha waa inaan isku koobno wada-sheekeysiga marka tirada token-nadu ka badato xad gaar ah. Gaar ahaan, waxaan ku beddelnaa input liis cusub oo ka yar oo walxo ah oo matala wada-sheekeysiga, taas oo u suurtagelinaysa wakiilka inuu sii wado isagoo fahamsan waxa ilaa hadda dhacay. Hirgelin hore oo isku-koobid ah⁠(ku furmaa daaqad cusub) waxay uga baahnayd isticmaalaha inuu gacantiisa ku socodsiiyo amarka /compact, kaas oo waydiin jiray Responses API isagoo adeegsanaya wada-sheekeysiga jira oo lagu daray tilmaamo gaar ah oo soo-koobid⁠(ku furmaa daaqad cusub). Codex wuxuu u adeegsaday assistant message-ka ka dhashay oo wata soo-koobka sida input-ka cusub⁠(ku furmaa daaqad cusub) ee wareegyada wada-sheekeysiga xiga.

Tan iyo markaas, Responses API wuxuu u kobcay inuu taageero bar-dhammaad gaar ah oo /responses/compact ah⁠(ku furmaa daaqad cusub) kaas oo si ka hufan u sameeya isku-koobid. Wuxuu soo celiyaa liis walxo ah⁠(ku furmaa daaqad cusub) oo loo isticmaali karo halkii input-kii hore si loo sii wado wada-sheekeysiga iyadoo la sii daynayo daaqadda macnaha. Liiskani wuxuu ka kooban yahay walax gaar ah oo type=compaction ah oo leh walax encrypted_content oo qarsoon oo ilaalisa fahamka qarsoon ee nooca ee wada-sheekeysiga asalka ahaa. Hadda, Codex si toos ah ayuu u adeegsadaa bar-dhammaadkan si uu wada-sheekeysiga u isku koobo marka auto_compact_limit⁠(ku furmaa daaqad cusub) laga gudbo.

Waxa xiga

Waxaan soo bandhignay wareegga wakiilka Codex waxaana sharaxnay sida Codex u sameeyo una maareeyo macnihiisa marka uu nooc waydiinayo. Intii ay taasi socotay, waxaan iftiiminay tixgelinno wax ku ool ah iyo hababka ugu wanaagsan ee khuseeya qof kasta oo dhisaya wareeg wakiil oo ku dhisan Responses API.

Inkasta oo wareegga wakiilku bixiyo aasaaska Codex, waa bilow keliya. Qoraallada soo socda, waxaan qodi doonnaa qaab-dhismeedka CLI-ga, sahamin doonnaa sida adeegsiga qalabku loo hirgeliyo, waxaana si dhow u eegi doonnaa qaabka sandboxing-ka Codex.

Qoraa

Michael Bolin

Mahadnaqyo

Mahad gaar ah dhammaan kooxda dhistay Codex CLI.

Sii wad akhrinta

Eeg dhamaan
Tax Agent > Art Card
Dhisidda wakiillo canshuureed oo is-taraya lana garabsanayo Codex

Injineernimada

codex windows > art card
Dhisidda deegaan xaddidan oo ammaan ah oo wax ku ool ah si Codex loogu ogolaado Windows

Injineernimada

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Injineernimada