Codex Max: Training for Tools, Collaboration, and Trust

Coding work that extends beyond one sitting

Early in the Latent Space conversation, a participant describes using Codex Max locally for more than 24 hours across several days, closing and reopening the laptop along the way. This was work extending beyond one sitting, not uninterrupted autonomous execution. The explanation of the Max name emphasizes endurance and speed: a coding agent intended to keep working on substantial problems.

That ambition raises a training question: what makes an agent a dependable pair programmer? During GPT-5 training, personality included predictable working behavior. Developers need to anticipate how a model will collaborate before trusting it with consequential work.

The team translated software engineering practices into observable behaviors that evaluators could grade: - Communicate progress: keep the developer informed while work is underway. - Plan when appropriate: choose a strategy before starting implementation. - Gather context: search and understand the relevant code before acting. - Check completed work: verify the result rather than stopping after an edit. Collaboration thus became a training target alongside the ability to produce code.

Tool interfaces carry learned habits

Work with coding partners exposed how strongly behavior depends on familiar tools. An agent’s harness is the surrounding software through which it uses tools and runs its workflow. Harnesses offer different search and editing interfaces; training can bake in habits that make unfamiliar tools slower or more error-prone to use.

This creates two integration choices: - Codex is optimized for its agent environment. The OpenAI Codex model is trained for the Codex harness and API. The harness is described as open source, while the model is available through the API. Some partners found this opinionated package easier to integrate because it supplied a preferred usage pattern. - Mainline GPT-5 and GPT-5.1 support broader tool use. These models cover more than coding and are described as more steerable across tool interfaces, making them an option for products with their own required tools. The teams were coordinating to keep coding capabilities aligned.

Partners found a useful middle ground: retain custom tools while matching familiar names and input/output interfaces. The initial expectation was that integrations might need to expose only terminal tools. Instead, custom implementations shaped like familiar terminal tools reportedly produced substantially better tool-call performance. Even naming appeared to matter: a search tool called rg reportedly worked better than one called grep, consistent with Codex’s preference for Ripgrep.

These qualitative reports include no workload details or numerical comparison, so renaming is not established as a universal fix. The practical recommendation is to examine the Codex software development kit (SDK) and tool implementations when building a coding integration. The exchange also challenges the positive framing of learned habits: models should generalize. The response distinguishes that broader goal for the mainline series from Codex’s focus on maximizing coding performance.

Communication enables intervention

For engineers handling important work, communication provides a way to supervise an agent. Progress updates let them intervene, stop a run, or avoid waiting for a result they will discard. Preambles before tool calls—short updates about the next action—were trained into the mainline 5 series to support this supervision.

One participant customized an agent to express enthusiasm about shared progress, making project work more enjoyable. They acknowledged that other users dislike this style and that its value depends on the working mode: - Interactive work benefits from timely updates: the developer can follow progress and redirect the agent. - Unattended work may benefit from less conversation: unread output can consume tokens without helping the task.

GPT-5.1’s conversational updates are steerable through prompting, including instructions to suppress them. Codex is described as providing updates through a reasoning summarizer rather than the same native communication behavior.

Integrate the complete agent, then delegate

Tool specialization motivates a larger architectural proposal: make the complete agent the integration boundary. Packaging a model with the harness it works best in lets platforms build above that combination. Zed, GitHub, and VS Code appear in the discussion as examples of this direction. The benefit for coding-tool builders is less work tracking each model release, API change, harness revision, and sandboxing detail.

An agent with access to Codex could also create a missing tool. The proposed application is software that starts a Codex instance to write a custom plugin for a customer’s API. An integration becomes work the software can commission on demand. This is an application pattern proposed in the conversation, rather than a reported deployment result.

Long-running delegation also requires context management. Codex Max is described as managing its context window through compaction inside the Codex harness, keeping context compact enough for work to continue without external management. It can also hand context to subagents—additional agents assigned portions of the work—for parallel execution. The claim that it could run essentially indefinitely is qualitative, and the benefits of parallel delegation were still emerging rather than measured.

Trust requires evaluations of the actual job

One participant reports going months without writing code by hand, offering an open-source Codex upgrade pack for migrating from completions to responses as a concrete example reportedly written entirely by Codex. The explanation for trusting such work centers on guardrails, evaluations, and inspection in production.

These serve distinct purposes: - Guardrails define permitted behavior: establish what the agent is allowed to do. - Traces expose actual behavior: record the sequence of actions in a run, also called a rollout. - Graders assess execution: identify shortcomings and provide feedback for better instructions. Production checks remain part of this process because the ambition is an agent that solves problems beyond the workflows its builder explicitly anticipated.

Applied evaluations test jobs customers actually need done. The team describes a shortage of these tests relative to academic evaluations. A customer might identify one missing capability that blocks adoption, supply an evaluation for it, or develop one jointly. That gives model and product development a concrete outcome to improve.

The analogy is hiring a highly qualified researcher who still needs to learn the job. A prompt supplies the job description; guardrails, evaluations, and feedback establish expected practice. Raw capability does not establish job readiness.

Evaluate the whole interaction

An acceptable final answer can conceal an inefficient path. One proposed evaluation method uses an LLM judge—a large language model acting as an evaluator—to assess the entire trajectory, or sequence of actions, and revisit a weak step:

1. Assess the complete run and identify an unsatisfactory action. 2. Return to the point before that action and rerun the next step with instructions. 3. Grade the new action and use the feedback to improve subsequent behavior. A reported variant asks the agent to write better instructions after feedback that its answer was correct but took too long. Those instructions are added to the harness. The reported improvement is anecdotal, without a quantitative result.

An unfinished job interview evaluation makes collaboration part of the test. Give an agent an underspecified assignment, grade its questions about constraints, introduce changes during implementation, and assess the whole exchange. An LLM could drive the interaction. Clarification and adaptation then become observable requirements.

Thousands of such runs make cost consequential. A participant requests a batch API for multi-turn evaluations so delay-tolerant workloads could run overnight at lower cost. This remains a feature request, with uncertainty about existing support. For these evaluations, immediate completion may matter less than affordability.

Terminal automation reaches beyond code

The discussion broadens to a personal project: an email agent modeled on Devin, operated through Slack. The mechanism is familiar from scripting: combine terminal commands and custom code to accomplish everyday tasks. Coding agents can act as computer-use agents for the terminal, even when the desired result is organized information rather than application code.

The examples span reported use and proposed extensions: - File organization already tried: participants used Codex to organize a messy experiments directory and a crowded desktop. - Further automation proposed: collect images into one folder, sort email through terminal tools, or generate YouTube video snippets for later viewing.

A harder boundary appears when an application exposes only a user interface. Participants report that coding agents still need deliberate prompting to use vision and often fail when doing so. Their hopes for 2026 include more computer use and more extensible subagent support, particularly for applications without an API.

The larger aspiration is trusted technical guidance for small teams: help with difficult customer-driven refactors, messy codebases, and unfamiliar technologies comparable to the guidance available at top technology firms. The closing invitation asks listeners to share what they are building through social channels—and identify missing model or product capabilities that would unlock substantially more useful work.