Unrolling the Codex agent loop

Codex CLI⁠(નવી વિન્ડોમાં ખૂલે છે) 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⁠(નવી વિન્ડોમાં ખૂલે છે). 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.

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

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⁠(નવી વિન્ડોમાં ખૂલે છે)—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:

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.

The Codex CLI sends HTTP requests to the Responses API⁠(નવી વિન્ડોમાં ખૂલે છે) 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⁠(નવી વિન્ડોમાં ખૂલે છે), so it can be used with any endpoint that implements the Responses API⁠(નવી વિન્ડોમાં ખૂલે છે):

• When using ChatGPT login⁠(નવી વિન્ડોમાં ખૂલે છે) with the Codex CLI, it uses https://chatgpt.com/backend-api/codex/responses as the endpoint

• When using API-key authentication⁠(નવી વિન્ડોમાં ખૂલે છે) with OpenAI hosted models, it uses https://api.openai.com/v1/responses as the endpoint

• When running Codex CLI with --oss to use gpt-oss⁠ with ollama 0.13.4+⁠(નવી વિન્ડોમાં ખૂલે છે) or LM Studio 0.3.39+⁠(નવી વિન્ડોમાં ખૂલે છે), it defaults to http://localhost:11434/v1/responses running locally on your computer

• Codex CLI can be used with the Responses API hosted by a cloud provider such as Azure

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

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⁠(નવી વિન્ડોમાં ખૂલે છે) takes a JSON payload with many parameters. We’ll focus on these three:

• instructions⁠(નવી વિન્ડોમાં ખૂલે છે): system (or developer) message inserted into the model’s context

• tools⁠(નવી વિન્ડોમાં ખૂલે છે): a list of tools the model may call while generating a response

• input⁠(નવી વિન્ડોમાં ખૂલે છે): a list of text, image, or file inputs to the model

In Codex, the instructions field is read from the model_instructions_file⁠(નવી વિન્ડોમાં ખૂલે છે) in ~/.codex/config.toml, if specified; otherwise, the base_instructions associated with a model⁠(નવી વિન્ડોમાં ખૂલે છે) are used. Model-specific instructions live in the Codex repo and are bundled into the CLI (e.g., gpt-5.2-codex_prompt.md⁠(નવી વિન્ડોમાં ખૂલે છે)).

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:

Finally, the input field of the JSON payload is a list of items. Codex inserts the following items⁠(નવી વિન્ડોમાં ખૂલે છે) 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⁠(નવી વિન્ડોમાં ખૂલે છે) and on_request.md⁠(નવી વિન્ડોમાં ખૂલે છે):

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⁠(નવી વિન્ડોમાં ખૂલે છે). In general, more specific instructions appear later:

• Contents of AGENTS.override.md and AGENTS.md in $CODEX_HOME

• Subject to a limit (32 KiB, by default), look in each folder from the Git/project root of the cwd (if it it exists) up to the cwd itself: add the contents of any of AGENTS.override.md, AGENTS.md, or any filename specified by project_doc_fallback_filenames in config.toml

• If any skills⁠(નવી વિન્ડોમાં ખૂલે છે) have been configured:

  • a short preamble about skills

  • the skill metadata⁠(નવી વિન્ડોમાં ખૂલે છે) for each skill

  • a section on how to use skills⁠(નવી વિન્ડોમાં ખૂલે છે)

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⁠(નવી વિન્ડોમાં ખૂલે છે):

એકવાર Codex input ને initialize કરવા માટે ઉપરોક્ત તમામ ગણતરી કરી લે છે, પછી તે સંવાદ શરૂ કરવા માટે user message ઉમેરે છે.

અગાઉના ઉદાહરણો દરેક message ની સામગ્રી પર કેન્દ્રિત હતા, પરંતુ ધ્યાન રાખો કે input નું દરેક element type, role⁠(નવી વિન્ડોમાં ખૂલે છે), અને content ધરાવતું JSON object છે, જેમ કે નીચે છે:

એકવાર Codex Responses API ને મોકલવા માટે સંપૂર્ણ JSON payload તૈયાર કરે છે, પછી તે ~/.codex/config.toml માં Responses API એન્ડપોઇન્ટ કેવી રીતે કન્ફિગર છે તેના આધારે Authorization header સાથે HTTP POST request કરે છે (જો નિર્ધારિત હોય તો વધારાના HTTP headers અને query parameters પણ ઉમેરાય છે).

જ્યારે OpenAI Responses API સર્વર request મેળવે છે, ત્યારે તે મોડલ માટે પ્રોમ્પ્ટ કાઢવા JSON નો આ મુજબ ઉપયોગ કરે છે (ખાતરી માટે કહીએ તો, Responses API ની custom implementation અલગ પસંદગી પણ કરી શકે):

જેમ તમે જોઈ શકો છો, પ્રોમ્પ્ટની પ્રથમ ત્રણ items નો ક્રમ client નહીં પરંતુ server નક્કી કરે છે. તેમ છતાં, એ ત્રણ items માંથી ફક્ત system message ની સામગ્રી પણ server દ્વારા નિયંત્રિત થાય છે, કારણ કે tools અને instructions client નક્કી કરે છે. JSON payload માંથી આવેલ input પછી આવે છે અને પ્રોમ્પ્ટ પૂર્ણ કરે છે.

હવે જ્યારે અમારો પ્રોમ્પ્ટ તૈયાર છે, ત્યારે અમે મોડલમાંથી નમૂના લેવા તૈયાર છીએ.

Responses API ને કરાયેલ આ HTTP request Codex માં સંવાદનો પ્રથમ “turn” શરૂ કરે છે. સર્વર Server-Sent Events (SSE⁠(નવી વિન્ડોમાં ખૂલે છે)) stream સાથે જવાબ આપે છે. દરેક event નો data "type" ધરાવતું JSON payload છે, જે "response" થી શરૂ થાય છે, અને તે આ જેવું હોઈ શકે છે (events ની સંપૂર્ણ યાદી અમારી API docs⁠(નવી વિન્ડોમાં ખૂલે છે) માં મળી શકે છે):

Codex events ની stream નો ઉપયોગ કરે છે⁠(નવી વિન્ડોમાં ખૂલે છે) અને તેમને એવા આંતરિક event objects તરીકે ફરી પ્રકાશિત કરે છે જેને client ઉપયોગ કરી શકે. response.output_text.delta જેવી events UI માં streaming માટે વપરાય છે, જ્યારે response.output_item.added જેવી અન્ય events એવા objects માં રૂપાંતરિત થાય છે જે અનુગામી Responses API calls માટે input માં ઉમેરાય છે.

માની લો કે Responses API ને કરેલી પ્રથમ request માં બે response.output_item.done events હોય: એક type=reasoning સાથે અને બીજી type=function_call સાથે. જ્યારે અમે tool call ના response સાથે ફરી મોડલને query કરીએ, ત્યારે આ events JSON ના input field માં આ રીતે રજૂ થવી જરૂરી છે:

આ અનુગામી query ના ભાગરૂપે મોડલમાંથી નમૂના લેવા માટે વપરાતો પરિણામરૂપ પ્રોમ્પ્ટ આ રીતે દેખાશે:

ખાસ કરીને ધ્યાન આપો કે જૂનો પ્રોમ્પ્ટ નવા પ્રોમ્પ્ટનો ચોક્કસ prefix છે. આ ઈરાદાપૂર્વક છે, કારણ કે તે અનુગામી requests ને બહુ વધુ કાર્યક્ષમ બનાવે છે કેમ કે અમે prompt caching નો લાભ લઈ શકીએ છીએ (જે અંગે અમે પ્રદર્શનના આગળના વિભાગમાં ચર્ચા કરીશું).

એજન્ટ લૂપના પ્રથમ ચિત્ર તરફ ફરી જોશું તો inference અને tool calling વચ્ચે ઘણી પુનરાવર્તનો હોઈ શકે છે. પ્રોમ્પ્ટ કદાચ વધતો રહે ત્યાં સુધી કે અમને assistant message ન મળે, જે turn ના અંતનું સંકેત આપે છે:

Codex CLI માં, અમે assistant message વપરાશકર્તાને બતાવીએ છીએ અને composer પર focus કરીને વપરાશકર્તાને સૂચવીએ છીએ કે હવે સંવાદ આગળ વધારવાનો તેમનો “turn” છે. જો વપરાશકર્તા જવાબ આપે, તો અગાઉના turn નો assistant message અને વપરાશકર્તાનો નવો message બંને નવા turn ની શરૂઆત માટે Responses API request ના input માં ઉમેરવા પડે છે:

ફરી એકવાર, કારણ કે અમે સંવાદ ચાલુ રાખી રહ્યા છીએ, Responses API ને મોકલાતી input ની લંબાઈ વધતી જ જાય છે:

આ સતત વધતા પ્રોમ્પ્ટનો પ્રદર્શન પર શું અર્થ થાય છે તે જોઈએ.

તમે કદાચ પોતાને પૂછતા હશો, “થોભો, શું સંવાદ દરમ્યાન Responses API ને મોકલાતા JSON ના પરિમાણની દૃષ્ટિએ એજન્ટ લૂપ quadratic નથી?” અને તમે સાચા હશો. જ્યારે Responses API આ સમસ્યાને ઘટાડવા માટે વૈકલ્પિક previous_response_id⁠(નવી વિન્ડોમાં ખૂલે છે) parameter ને સપોર્ટ કરે છે, Codex આજે મુખ્યત્વે requests ને સંપૂર્ણપણે stateless રાખવા અને Zero Data Retention (ZDR) configurations ને સપોર્ટ કરવા માટે તેનો ઉપયોગ કરતું નથી.

સામાન્ય રીતે, મોડલમાંથી નમૂના લેવાનો ખર્ચ network traffic ના ખર્ચ કરતાં મોટો હોય છે, એટલે કાર્યક્ષમતાના પ્રયત્નો માટે sampling મુખ્ય લક્ષ્ય બને છે. આ કારણે prompt caching ખૂબ મહત્વપૂર્ણ છે, કેમ કે તે અગાઉની inference call ની computation ને ફરી વાપરવાની મંજૂરી આપે છે. જ્યારે અમને cache hits મળે છે, ત્યારે મોડલ sampling quadratic ના બદલે linear બને છે. અમારી prompt caching ⁠(નવી વિન્ડોમાં ખૂલે છે) documentation આ બાબત વધુ વિગતે સમજાવે છે:

Cache hits ફક્ત prompt માં ચોક્કસ prefix matches માટે જ શક્ય છે. caching નો લાભ મેળવવા માટે, instructions અને examples જેવી static content તમારા prompt ની શરૂઆતમાં મૂકો, અને user-specific information જેવી variable content અંતમાં મૂકો. આ images અને tools માટે પણ લાગુ પડે છે, જે requests વચ્ચે સમાન હોવા જોઈએ.

આ ધ્યાનમાં રાખીને, ચાલો વિચારીએ કે Codex માં “cache miss” કયા પ્રકારની operations કારણે થઈ શકે:

• સંવાદના મધ્યમાં મોડલ માટે ઉપલબ્ધ tools બદલી દેવી.

• Responses API request નું લક્ષ્ય બનતું model બદલી દેવું (વ્યવહારમાં, આ મૂળ પ્રોમ્પ્ટની ત્રીજી item બદલે છે, કારણ કે તેમાં મોડલ-વિશિષ્ટ instructions હોય છે).

• sandbox configuration, approval mode અથવા current working directory બદલી દેવી.

Codex ટીમે Codex CLI માં એવી નવી સુવિધાઓ ઉમેરતી વખતે ખાસ સાવચેત રહેવું પડે છે જે prompt caching ને નુકસાન પહોંચાડી શકે. ઉદાહરણ તરીકે, MCP tools માટેના અમારા પ્રારંભિક support એ એવો bug લાવ્યો કે અમે tools ને સતત એકસરખા ક્રમમાં enumerate ન કરી શક્યાં⁠(નવી વિન્ડોમાં ખૂલે છે), જેના કારણે cache misses થયા. ધ્યાન રાખો કે MCP tools ખાસ મુશ્કેલ હોઈ શકે છે કારણ કે MCP servers તેમની પાસે ઉપલબ્ધ tools ની યાદી notifications/tools/list_changed⁠(નવી વિન્ડોમાં ખૂલે છે) notification દ્વારા ગતિશીલ રીતે બદલી શકે છે. લાંબા સંવાદના મધ્યમાં આ notification સ્વીકારવાથી ખર્ચાળ cache miss થઈ શકે છે.

જ્યાં શક્ય હોય ત્યાં, સંવાદના મધ્યમાં થતા configuration changes ને અમે અગાઉના message ને બદલીને નહીં પરંતુ input માં નવો message ઉમેરીને સંભાળીએ છીએ:

• જો sandbox configuration અથવા approval mode બદલાય, તો અમે મૂળ <permissions instructions> item જેવા જ ફોર્મેટ સાથે નવો role=developer message ઉમેરીએ છીએ⁠(નવી વિન્ડોમાં ખૂલે છે).

• જો current working directory બદલાય, તો અમે મૂળ <environment_context> જેવા જ ફોર્મેટ સાથે નવો role=user message ઉમેરીએ છીએ⁠(નવી વિન્ડોમાં ખૂલે છે).

પ્રદર્શન માટે cache hits સુનિશ્ચિત કરવા અમે ઘણો પ્રયત્ન કરીએ છીએ. એક અન્ય મહત્વપૂર્ણ resource પણ છે જેને અમારે સંભાળવું પડે છે: context window.

context window ખૂટી ન જાય તે માટેની અમારી સામાન્ય રણનીતિ એ છે કે જ્યારે tokens ની સંખ્યા ચોક્કસ threshold થી વધી જાય ત્યારે સંવાદને compact કરી દેવો. ખાસ કરીને, અમે input ને items ની નવી, નાની સૂચિથી બદલી દઈએ છીએ જે સંવાદનું પ્રતિનિધિત્વ કરે છે, જેથી એજન્ટ અત્યાર સુધી શું થયું છે તેની સમજ સાથે આગળ વધી શકે. compaction ની પ્રારંભિક implementation⁠(નવી વિન્ડોમાં ખૂલે છે) માટે વપરાશકર્તાએ /compact command જાતે ચલાવવી પડતી, જે હાજર સંવાદ અને summarization⁠(નવી વિન્ડોમાં ખૂલે છે) માટેની custom instructions સાથે Responses API ને query કરતી. Codex મળેલા summary ધરાવતા assistant message નો નવા input તરીકે ઉપયોગ કરતો⁠(નવી વિન્ડોમાં ખૂલે છે) પછીના conversation turns માટે.

ત્યારથી Responses API ખાસ /responses/compact એન્ડપોઇન્ટ⁠(નવી વિન્ડોમાં ખૂલે છે) ને સપોર્ટ કરવા માટે વિકસિત થઈ છે, જે compaction વધુ કાર્યક્ષમ રીતે કરે છે. તે items ની સૂચિ⁠(નવી વિન્ડોમાં ખૂલે છે) પરત આપે છે, જેને અગાઉના input ની જગ્યાએ વાપરીને context window ખાલી કરતી વખતે સંવાદ ચાલુ રાખી શકાય. આ સૂચિમાં વિશેષ type=compaction item હોય છે જેમાં અસ્પષ્ટ encrypted_content item સામેલ હોય છે, જે મૂળ સંવાદ અંગે મોડલની latent understanding જાળવે છે. હવે, auto_compact_limit⁠(નવી વિન્ડોમાં ખૂલે છે) વટાય ત્યારે Codex આ એન્ડપોઇન્ટ નો આપમેળે ઉપયોગ કરે છે.

અમે Codex એજન્ટ લૂપનો પરિચય આપ્યો અને Codex મોડલને query કરતી વખતે પોતાનો context કેવી રીતે બનાવે છે અને સંચાલિત કરે છે તે સમજાવ્યું. આ પ્રક્રિયા દરમિયાન, અમે એવી વ્યવહારિક બાબતો અને શ્રેષ્ઠ પદ્ધતિઓ પર પ્રકાશ પાડ્યો જે Responses API પર એજન્ટ લૂપ બનાવતા કોઈપણ માટે ઉપયોગી છે.

જોકે એજન્ટ લૂપ Codex નો આધાર પૂરો પાડે છે, તે માત્ર શરૂઆત છે. આવનારી પોસ્ટ્સમાં, અમે CLI ની architecture માં ઊંડું ઊતરશું, tool use કેવી રીતે અમલમાં મુકાય છે તે તપાસીશું અને Codex ના sandboxing model ને વધુ નજીકથી જોઈશું.