Aqbeż għall-kontenut prinċipali
OpenAI

23 ta’ Jannar 2026

Inġinerija

Unrolling the Codex agent loop

By Michael Bolin, Member of the Technical Staff

Qed jillowdja…

Codex CLI⁠(jinfetaħ f’tieqa ġdida) 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⁠(jinfetaħ f’tieqa ġdida). 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:

Dijagramma bit-titlu “Agent loop” li turi kif sistema AI tipproċessa talba tal-utent, issejjaħ għodod, tosserva r-riżultati, taġġorna l-pjan tagħha u tirritorna outputs. Il-vleġeġ jgħaqqdu passi bħall-input tal-utent, ir-raġunament tal-mudell, l-azzjonijiet tal-għodod u t-tweġiba finali.

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⁠(jinfetaħ f’tieqa ġdida)—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:

Dijagramma bit-titlu “Multi-turn agent loop” li turi kif aġent AI b’mod iterattiv jieħu input tal-utent, jiġġenera azzjonijiet, jikkonsulta għodod, jaġġorna l-istat, u jirritorna r-riżultati. Tinkludi passi bit-tikketti, vleġeġ, u outputs ta’ għodod ta’ eżempju li juru ċ-ċiklu tar-raġunament tal-aġent.

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⁠(jinfetaħ f’tieqa ġdida) 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⁠(jinfetaħ f’tieqa ġdida), so it can be used with any endpoint that implements the Responses API⁠(jinfetaħ f’tieqa ġdida):

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⁠(jinfetaħ f’tieqa ġdida) 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⁠(jinfetaħ f’tieqa ġdida) in ~/.codex/config.toml, if specified; otherwise, the base_instructions associated with a model⁠(jinfetaħ f’tieqa ġdida) are used. Model-specific instructions live in the Codex repo and are bundled into the CLI (e.g., gpt-5.2-codex_prompt.md⁠(jinfetaħ f’tieqa ġdida)).

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⁠(jinfetaħ f’tieqa ġdida) 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⁠(jinfetaħ f’tieqa ġdida) and on_request.md⁠(jinfetaħ f’tieqa ġdida):

Test sempliċi

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⁠(jinfetaħ f’tieqa ġdida). 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⁠(jinfetaħ f’tieqa ġdida):

Test sempliċi

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

Ladarba Codex ikun għamel il-komputazzjoni kollha ta’ hawn fuq biex jinizzjalizza l-input, iżid il-messaġġ tal-utent biex tibda l-konverżazzjoni.

L-eżempji preċedenti ffukaw fuq il-kontenut ta’ kull messaġġ, iżda innota li kull element tal-input huwa oġġett JSON bi type, role⁠(jinfetaħ f’tieqa ġdida), u content kif ġej:

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
}

Ladarba Codex jibni l-payload JSON sħiħ biex jibgħatu lill-Responses API, imbagħad jagħmel it-talba HTTP POST b’header Authorization skont kif il-punt ta' tmiem tal-Responses API ikun ikkonfigurat f’~/.codex/config.toml (jiżdiedu headers HTTP addizzjonali u query parameters jekk ikunu speċifikati).

Meta server tal-OpenAI Responses API jirċievi t-talba, juża l-JSON biex joħloq il-prompt għall-mudell kif ġej (żgur, implimentazzjoni personalizzata tal-Responses API tista’ tagħmel għażla differenti):

Dijagramma snapshot li turi pass wieħed f’loop ta’ aġent AI. Talba tal-utent tidħol fil-mudell, li jipproduċi ħsieb, azzjoni b’isem ta’ għodda, u input tal-għodda. Id-dijagramma tenfasizza dan il-pass intermedju ta’ raġunament qabel ma tissejjaħ l-għodda.

Kif tista’ tara, l-ordni tal-ewwel tliet oġġetti fil-prompt huwa determinat mis-server, mhux mill-klijent. Madankollu, minn dawk it-tliet oġġetti, il-kontenut biss tal-messaġġ system huwa wkoll ikkontrollat mis-server, peress li l-tools u l-instructions huma determinati mill-klijent. Dawn jiġu segwiti mill-input mill-payload JSON biex jitlesta l-prompt.

Issa li għandna l-prompt tagħna, lesti biex nieħdu kampjun mill-mudell.

L-ewwel turn

Din it-talba HTTP lill-Responses API tibda l-ewwel “turn” ta’ konverżazzjoni f’Codex. Is-server iwieġeb bi stream ta’ Server-Sent Events (SSE⁠(jinfetaħ f’tieqa ġdida)). Id-data ta’ kull event hija payload JSON b’"type" li jibda b’"response", li tista’ tkun xi ħaġa bħal din (lista sħiħa tal-events tinsab fid-dokumentazzjoni tal-API⁠(jinfetaħ f’tieqa ġdida) tagħna):

Test sempliċi

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 jikkonsma l-stream tal-events⁠(jinfetaħ f’tieqa ġdida) u jerġa’ jippubblikahom bħala oġġetti interni ta’ event li klijent jista’ juża. Events bħal response.output_text.delta jintużaw biex jappoġġjaw l-istreaming fil-UI, filwaqt li events oħra bħal response.output_item.added jinbidlu f’oġġetti li jiżdiedu mal-input għal sejħiet sussegwenti tal-Responses API.

Ejja nassumu li l-ewwel talba lill-Responses API tinkludi żewġ events response.output_item.done: waħda b’type=reasoning u waħda b’type=function_call. Dawn l-events iridu jkunu rrappreżentati fil-qasam input tal-JSON meta nerġgħu nsaqsu lill-mudell bit-tweġiba għas-sejħa tal-għodda: 

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
]

Il-prompt li jirriżulta użat biex jittieħed kampjun mill-mudell bħala parti mill-query sussegwenti jkun jidher hekk:

Dijagramma bit-tikketta “Snapshot 2” li turi aġent AI wara sejħa ta’ għodda. Il-mudell jirċievi osservazzjoni minn għodda u jipproduċi ħsieb u azzjoni ġodda. Il-vleġeġ jgħaqqdu l-inputs, l-osservazzjonijiet u l-outputs biex juru kif l-aġent itenni l-loop tar-raġunament tiegħu.

B’mod partikolari, innota kif il-prompt il-qadim huwa prefiss eżatt tal-prompt il-ġdid. Dan huwa intenzjonat, peress li jagħmel it-talbiet sussegwenti ferm aktar effiċjenti għax jippermettilna nieħdu vantaġġ mill-prompt caching (li se niddiskutu fit-taqsima li jmiss dwar il-prestazzjoni).

Meta nħarsu lura lejn l-ewwel dijagramma tagħna tal-loop tal-aġent, naraw li jista’ jkun hemm ħafna iterazzjonijiet bejn l-inferenza u s-sejħa tal-għodod. Il-prompt jista’ jkompli jikber sakemm finalment nirċievu assistant message, li jindika t-tmiem tat-turn:

Test sempliċi

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

F’Codex CLI, aħna nippreżentaw l-assistant message lill-utent u niffokaw il-composer biex nindikaw lill-utent li issa huwa t-“turn” tiegħu biex ikompli l-konverżazzjoni. Jekk l-utent iwieġeb, kemm l-assistant message mit-turn preċedenti, kif ukoll il-messaġġ il-ġdid tal-utent, iridu jiżdiedu mal-input fit-talba tal-Responses API biex jibda t-turn il-ġdid:

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
]

Għal darb’oħra, minħabba li qed inkomplu konverżazzjoni, it-tul tal-input li nibagħtu lill-Responses API jibqa’ jiżdied:

Dijagramma bit-tikketta “Snapshot 3” li turi l-istadju finali ta’ loop ta’ aġent AI. Wara li jirċievi r-riżultati tal-għodod, il-mudell jiġġenera ħsieb konklużiv u tweġiba finali li tintbagħat lura lill-utent. Il-vleġeġ juru t-tranżizzjoni mill-output tal-għodda għat-tweġiba kompluta.

Ejja neżaminaw x’ifisser dan il-prompt li dejjem qed jikber għall-prestazzjoni.

Kunsiderazzjonijiet dwar il-prestazzjoni

Forsi qed tistaqsi lilek innifsek, “Stenna, mhux il-loop tal-aġent kwadratiku f’termini tal-ammont ta’ JSON mibgħut lill-Responses API tul il-konverżazzjoni?” U jkollok raġun. Filwaqt li l-Responses API jappoġġja parametru mhux obbligatorju previous_response_id⁠(jinfetaħ f’tieqa ġdida) biex itaffi din il-problema, Codex ma jużahx illum, primarjament biex iżomm it-talbiet kompletament stateless u biex jappoġġja konfigurazzjonijiet ta’ l-ebda żamma tad-dejta (ZDR).

Li tevita previous_response_id tissimplifika l-affarijiet għall-fornitur tal-Responses API għax tiżgura li kull talba tkun stateless. Dan jagħmilha wkoll sempliċi biex jiġu appoġġjati klijenti li għażlu l-ebda żamma tad-dejta (ZDR)⁠(jinfetaħ f’tieqa ġdida), peress li l-ħażna tad-dejta meħtieġa biex tappoġġja previous_response_id tmur kontra ZDR. Innota li l-klijenti ZDR ma jissagrifikawx il-kapaċità li jibbenefikaw minn messaġġi ta’ raġunament proprjetarji minn turns preċedenti, peress li l-encrypted_content assoċjat jista’ jiġi dekriptat fuq is-server. (OpenAI jippersisti ċ-ċavetta tad-dekriptaġġ ta’ klijent ZDR, iżda mhux id-dejta tiegħu.) Ara l-PRs #642⁠(jinfetaħ f’tieqa ġdida) u #1641⁠(jinfetaħ f’tieqa ġdida) għall-bidliet relatati f’Codex biex jappoġġja ZDR.

Ġeneralment, l-ispiża tal-kampjunar tal-mudell tiddomina l-ispiża tat-traffiku tan-network, u b’hekk il-kampjunar isir il-mira ewlenija tal-isforzi tagħna għall-effiċjenza. Huwa għalhekk li l-prompt caching huwa tant importanti, għax jippermettilna nerġgħu nużaw il-komputazzjoni minn sejħa ta’ inferenza preċedenti. Meta niksbu cache hits, il-kampjunar tal-mudell ikun lineari u mhux kwadratiku. Id-dokumentazzjoni tagħna dwar prompt caching ⁠(jinfetaħ f’tieqa ġdida) tispjega dan f’aktar dettall:

Cache hits huma possibbli biss għal matches ta’ prefiss eżatti fi prompt. Biex tirrealizza l-benefiċċji tal-caching, poġġi kontenut statiku bħal istruzzjonijiet u eżempji fil-bidu tal-prompt tiegħek, u poġġi kontenut varjabbli, bħal informazzjoni speċifika għall-utent, fit-tmiem. Dan japplika wkoll għal immaġnijiet u għodod, li jridu jkunu identiċi bejn it-talbiet.

B’dan f’moħħna, ejja nikkunsidraw x’tipi ta’ operazzjonijiet jistgħu jikkawżaw “cache miss” f’Codex:

  • Nibdlu l-tools disponibbli għall-mudell fin-nofs tal-konverżazzjoni.
  • Nibdlu l-model li huwa l-mira tat-talba tal-Responses API (fil-prattika, dan ibiddel it-tielet oġġett fil-prompt oriġinali, peress li fih istruzzjonijiet speċifiċi għall-mudell).
  • Nibdlu l-konfigurazzjoni tas-sandbox, il-modalità ta’ approvazzjoni, jew id-direttorju tax-xogħol kurrenti.

It-tim ta’ Codex irid ikun diliġenti meta jintroduċi karatteristiċi ġodda f’Codex CLI li jistgħu jikkompromettu l-prompt caching. Bħala eżempju, l-appoġġ inizjali tagħna għal għodod MCP introduċa bug fejn ma rnexxilniex nelenkaw l-għodod f’ordni konsistenti⁠(jinfetaħ f’tieqa ġdida), u dan ikkawża cache misses. Innota li l-għodod MCP jistgħu jkunu partikolarment diffiċli għax is-servers MCP jistgħu jibdlu l-lista ta’ għodod li jipprovdu fuq il-fly permezz ta’ notifika notifications/tools/list_changed⁠(jinfetaħ f’tieqa ġdida). Li tonora din in-notifika fin-nofs ta’ konverżazzjoni twila jista’ jikkawża cache miss għaljin.

Meta jkun possibbli, nimmaniġġjaw bidliet fil-konfigurazzjoni li jseħħu fin-nofs tal-konverżazzjoni billi nżidu messaġġ ġdid mal-input biex jirrifletti l-bidla minflok ma nimmodifikaw messaġġ preċedenti:

  • Jekk il-konfigurazzjoni tas-sandbox jew il-modalità ta’ approvazzjoni tinbidel, ndaħħlu⁠(jinfetaħ f’tieqa ġdida) messaġġ ġdid b’role=developer bl-istess format tal-oġġett oriġinali <permissions instructions>.
  • Jekk jinbidel id-direttorju tax-xogħol kurrenti, ndaħħlu⁠(jinfetaħ f’tieqa ġdida) messaġġ ġdid b’role=user bl-istess format tal-<environment_context> oriġinali.

Nagħmlu ħafna sforz biex niżguraw cache hits għall-prestazzjoni. Hemm riżorsa ewlenija oħra li rridu nimmaniġġjaw: it-tieqa tal-kuntest.

L-istrateġija ġenerali tagħna biex nevitaw li jispiċċa l-kuntest hija li nikkompattaw il-konverżazzjoni ladarba n-numru ta’ tokens jaqbeż ċertu limitu. B’mod speċifiku, nissostitwixxu l-input b’lista ġdida u iżgħar ta’ oġġetti li tirrappreżenta l-konverżazzjoni, u tippermetti lill-aġent ikompli b’fehim ta’ x’ġara s’issa. Implimentazzjoni bikrija ta’ compaction⁠(jinfetaħ f’tieqa ġdida) kienet teħtieġ li l-utent isejjaħ manwalment il-kmand /compact, li kien jagħmel query lill-Responses API bl-użu tal-konverżazzjoni eżistenti flimkien ma’ istruzzjonijiet personalizzati għal sommarizzazzjoni⁠(jinfetaħ f’tieqa ġdida). Codex kien juża l-assistant message li kien jirriżulta u li kien fih is-sommarju bħala l-input⁠(jinfetaħ f’tieqa ġdida) il-ġdid għal turns ta’ konverżazzjoni sussegwenti.

Minn dak iż-żmien ’l hawn, il-Responses API evolva biex jappoġġja punt ta' tmiem speċjali /responses/compact endpoint⁠(jinfetaħ f’tieqa ġdida) li jwettaq il-compaction b’mod aktar effiċjenti. Dan jirritorna lista ta’ oġġetti⁠(jinfetaħ f’tieqa ġdida) li tista’ tintuża minflok l-input preċedenti biex tkompli l-konverżazzjoni filwaqt li tillibera t-tieqa tal-kuntest. Din il-lista tinkludi oġġett speċjali type=compaction b’oġġett opak encrypted_content li jżomm il-fehim latenti tal-mudell tal-konverżazzjoni oriġinali. Issa, Codex juża dan il-punt ta' tmiem awtomatikament biex jikkompatta l-konverżazzjoni meta jinqabeż il-auto_compact_limit⁠(jinfetaħ f’tieqa ġdida).

Dalwaqt

Introduċejna l-loop tal-aġent Codex u mxejna miegħek kif Codex jibni u jimmaniġġja l-kuntest tiegħu meta jagħmel query lil mudell. Tul it-triq, enfasizzajna kunsiderazzjonijiet prattiċi u l-aħjar prattiki li japplikaw għal kull min qed jibni loop ta’ aġent fuq il-Responses API.

Għalkemm il-loop tal-aġent jipprovdi l-pedament għal Codex, dan huwa biss il-bidu. Fil-posts li ġejjin, se nidħlu fl-arkitettura tal-CLI, nesploraw kif jiġi implimentat l-użu tal-għodod, u nagħtu ħarsa aktar mill-qrib lejn il-mudell ta’ sandboxing ta’ Codex.

Awtur

Michael Bolin

Ringrazzjamenti

Grazzi speċjali lit-tim kollu li bena Codex CLI.

Kompli aqra

Ara kollox
Tax Agent > Art Card
Nibnu aġenti tat-taxxa li jtejbu lilhom infushom b’Codex

Inġinerija

codex windows > art card
Nibnu sandbox sigura u effettiva biex nippermettu l-Codex fuq Windows

Inġinerija

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Inġinerija