What You Will Learn

Many people start using AI tools and quickly run into several problems:

• The model is powerful, but the results are unstable.
• The same task produces very different results when phrased differently.
• The longer the conversation, the more likely the AI is to go off track.
• The tool has many features, but you don't know how to organize them into your own workflow.
• You've seen many scattered tutorials, but when it comes to actually doing it, you don't know where to start.

This course will clarify these issues along a complete learning path. It starts with the difference between Agent and ordinary AI chat products, guiding you through understanding Codex's positioning, model selection methods, context management, conversation habits, built-in tools, the Skill mechanism, automation capabilities, and practical scenarios.

After completing this course, you will have a clearer understanding of:

• What tasks are suitable for an AI Agent, and what tasks should be broken down.
• How to express requirements so that the AI can complete tasks more stably.
• How to manage context to reduce the problem of conversations becoming more confusing over time.
• How to use Codex's projects, threads, tools, Skills, and automation capabilities.

---

Preface

Hello everyone, I'm oil 欧呦.

I share content about AI programming and Agent usage on Xiaohongshu. I'm just an ordinary front-end developer. I started using AI programming tools in 2024, completely switched to a Vibe Coding workflow by 2025, and now integrate AI Agents into every aspect of my daily work.

The content of this course comes from my actual usage experience over the past year or more. It's not a tutorial copied from official documentation, nor is it second-hand material organized after paying for someone else's course. Every method, every pitfall, and every insight here is something I've genuinely spent time and money to figure out myself. The article will be a bit long, so feel free to bookmark it for later reading!

What I Hope You Get After Reading

I don't just want this course to teach you how to operate a specific piece of software.

I hope that after reading it, you will have a high-level understanding of the entire AI world. Once you understand AI well enough, you can actively filter out a large amount of junk information and anxiety-inducing content, and form your own judgment. You will be able to distinguish what is truly valuable skill improvement and what is just a blogger's traffic tactic.

More importantly, you will be able to truly apply AI to your own work and life. Whether you are a programmer, product manager, designer, content creator, or any other profession, Agents can do much more than just write code, as long as you understand their capability boundaries and the correct way to use them.

About Me

I don't have a big company background, but I have relatively rich experience in the AI direction.

I started as a front-end developer. I switched to product manager because I found my interest wasn't in the details of implementation, but in "what this thing should look like." Later, when AI emerged, I started using AI programming tools at work and discovered that it could enable one person to do what previously required a team. This realization led me to later join a company building a general-purpose AI Agent as a product manager.

After that, I worked as a product manager and front-end developer at two AI startups. Through these experiences, I gained hands-on experience in Agent design, model selection, context management, MCP development, and SEO implementation — all learned from actual work, not from reading other people's articles.

Regarding content creation, I produce original content on Xiaohongshu, reaching over 10,000 followers in just over a month, posting almost four to five videos a week. And since content creation is just my side hustle, I don't need to worry too much about data, talk about popular topics just to follow the crowd, or spread anxiety for traffic. I only share things I've genuinely used and found good, which is why my content is almost entirely original.

On the product side, I've Vibe Coded Text-Well (an AI text correction tool, from zero to launch in three days), Wolfcha (an AI Werewolf game, a hackathon project), and an AI creation platform (taking SEO daily impressions from 500 to 15,000+ in two months).

On the open-source side, I've created many Skills and tools: draw-ui (UI design draft generation), screen-studio-editor (video editing + subtitles), codex-explore-skill (codebase exploration), my-browser (local browser automation), oiloil-ui-ux-guide (UI/UX design guidelines), and more.

All the content in this course is based on my own genuine experience — things I've actually used, paid for, and learned from. I hope it's useful to you.

---

Chapter 1: The Difference Between Agent and Ordinary AI Chat

Hello everyone, I'm Oil 欧呦, and this is the first chapter of this course.

Personally, I don't really like those very rigid course chapters that first forcefully explain some grand, impractical concepts before analyzing the details bit by bit. That approach is often quite boring.

But why do I start by explaining the difference between Agents? Because many people don't really understand the essential difference between an Agent and an ordinary AI conversation, nor do they know what each can accomplish. Understanding what they can do is the most important prerequisite for fully utilizing AI.

Different people have different needs. From my own learning experience and perspective, many of my interesting ideas stem from imagining which of my scenarios an Agent can cover, based on what I know it can do. I don't usually start with a problem and then figure out if an Agent can solve it, because there are often many ways to solve a problem.

For example, for adding subtitles to videos, I initially used CapCut, and later tried some third-party products. Then, I suddenly realized that using an Agent for this task could achieve a high degree of customization. I had to first understand that an Agent could help me add subtitles to videos and understand exactly how it operates before I could realize it would handle this scenario better than other products.

The same applies to you using an Agent. Once we understand what an Agent can handle, we naturally think about whether our own work scenarios can be handed over to an Agent to run, or if it can help improve our work efficiency. So before we begin, let me explain the difference between an Agent and an ordinary AI conversation.

Let's first list some common examples. You might often hear about products like Tongyi Qianwen, Tencent Yuanbao, Doubao, DeepSeek, ChatGPT, Gemini, OpenClaw, Claude Code, Codex, and Cursor. Someone unfamiliar with AI might think they are AI itself. But they are actually products launched by different companies, and some are AI chat products while others are Agent products. Many people's understanding of them might be limited to domestic vs. foreign differences, subconsciously thinking foreign products are better than domestic ones, for example, believing Claude Code is more powerful than Doubao.

Why emphasize that they are products? Because products and models are two different things.

In fact, the biggest difference is that some are AI chat products, and some are Agent products.

Products like Tongyi Qianwen, Tencent Yuanbao, Doubao, DeepSeek, ChatGPT, and Gemini are all AI chat products.

Some AI chat products on the web also support web search functionality, but there is a huge gap in capability between them and true Agent products.

The web search functionality of an AI chat product is essentially text extraction. When we input a question, it gets some webpage content summaries via a search engine in the background, then organizes the information within the large model's window, and returns the answer in the chat box. During this process, it cannot interact with the webpage, cannot click buttons on the webpage, cannot log into our accounts, and certainly cannot save the obtained information to a local folder on our computer. In contrast, an Agent product's web search is true control and operation. It can take over a real browser, simulate clicks, inputs, and page turning like a human, even log into our own accounts to perform operations, and automatically download various obtained materials locally.

Products like OpenClaw, Claude Code, Codex, and Cursor are all Agent products.

Among them, Gemini, besides having an AI chat product, recently launched an Agent product called Gemini Spark. And Codex and ChatGPT both belong to OpenAI.

1.1 What is an AI Agent

You've probably all used Doubao before, many people might be used to using it on their phones. Doubao is a very classic AI chat product. We input a line of question in the dialog box, and it replies with a paragraph of text in the window. This one-question-one-answer format is very suitable for daily consultations or writing text.

However, if we want it to help us handle specific computer operations, we find it simply can't do it. For example, if we need it to rename all images in a certain folder, it cannot directly control our computer to modify the file names; it can only provide us with a piece of Python code. We have to copy the code ourselves, create a new file, and run it in the terminal ourselves. If there's an error during execution, we have to copy the error message back and ask it. This requires a lot of manual copy-pasting in between.

An Agent is designed to solve these tedious steps. When using an Agent, we don't need to copy and run code ourselves. We just need to provide an overall goal, and it will break down the task, select the appropriate tools, and run step by step until completion.

Traditional AI chat products only reply with text in a browser window, while Agent products can execute commands in the terminal, modify files, and even control the browser, directly completing all these fragmented operations for us.

Previously, the definition of an Agent wasn't very clear, and simple workflows were often mistaken for Agent products. Anthropic officially wrote an article specifically to help clarify this classification. Now, there is a very clear definition of an Agent product: a system that can plan its own actions and call tools.

In the official classification, systems are divided into workflows and Agent products.

Workflows connect large models and various tools with fixed code. For example, we write a program: first, call an API to get data; second, translate text; third, save to a database. In this process, the large model is just a computation node. The model has no decision-making power; it can only follow the program's designed route.

Agent products, on the other hand, give complete control of the process to the large model, allowing it to dynamically decide the next steps and tools. For example, we assign it the goal of fixing a bug. It will decide on its own to first use a search tool to find relevant files, read the code and locate the problem, then modify the file itself, and finally run tests to verify. If a test fails, it will analyze the error and re-modify until the task is complete.

Throughout this process, we didn't set a rigid code path for it. What tool to use for each step and how to proceed next are entirely decided by the model during execution based on the actual results returned. This kind of system with dynamic decision-making power is what we call an Agent product.

1.2 Limitations of Ordinary AI Chat Products

When using ordinary AI chat products, you often find their limitations quite obvious.

Besides not being able to directly operate the computer as mentioned earlier, the context window of web-based AI chat products is also limited. When the conversation goes on for a long time, it forgets the earlier content. It also cannot directly read local files on our computer, and certainly cannot know the actual test results on our local machine.

Because an ordinary AI chat product is essentially a static sandbox environment, it is completely disconnected from our local computer and the real external internet. All its output can only stay in the text box, unable to produce any feedback on the real world.

1.3 Functional Comparison in Real Scenarios

To help you understand the difference between these two types of products more clearly, let's look at how they handle the same problem in specific life scenarios, and what different operations and results they produce.

Scenario 1: Organizing a Travel Itinerary

We ask them to look up the latest ticket prices and opening hours for West Lake, Xixi Wetland, and Lingyin Temple, then create a spreadsheet file and place it on the computer desktop.

• Ordinary AI Chat Product: Usually can only perform a single web search. It will get relevant webpage summaries for these three attractions via a search engine in the background, then, in the chat text box, either draw a table composed of characters or generate a downloadable link for the spreadsheet file. However, it cannot directly interface with your local computer's operating system to write the created spreadsheet file directly to your desktop path.
• Agent Product: Can autonomously use browser automation tools to visit the official websites of each attraction one by one, actively click on ticket booking or announcement pages, and obtain the latest data for the day. Then, it will directly call your local operating system's file writing interface, create a real spreadsheet file on your computer desktop, fill in the data, save it, and prompt you that the run was successful upon completion.

Scenario 2: Organizing Local Photos

We have a folder on our desktop called "Photos to Organize" containing one hundred photos. We need to select and delete blurry and duplicate photos, then create new folders based on the shooting date for the remaining ones.

• Ordinary AI Chat Product: Directly informs us that it cannot access the local computer desktop and has no permission to modify files. Then it provides a long piece of Python code, telling us to install the runtime environment and configure various dependency libraries ourselves. For non-technical users who don't understand code, this is overwhelming.
• Agent Product: Directly reads the local folder. It calls image viewing tools itself, compares the sharpness and content of each photo one by one, picks out the unqualified ones and moves them to the trash. Simultaneously, it calls the system's file management tools to create categorized folders with specific dates and automatically moves the qualified photos into them.

Scenario 3: Creating a Daily Work Briefing

We want it to automatically, at 9 AM every day, go to some tech communities and social platforms to collect popular posts about large models, organize the titles and links, and send them to us via office software.

• Ordinary AI Chat Product: States that it cannot start spontaneously in the background or control other software. It can only act as a passive tool, replying when we actively send a message with a question.
• Agent Product: Can utilize its own built-in scheduled automation mechanism (e.g., Codex's Automation task panel). We configure the goal and time rules for the scheduled task directly in the product. It will then automatically start in the background at 9 AM every day, control the browser, log into our social accounts to scrape posts, organize them, and then directly call the office software's sending interface to pop up the briefing.

1.4 The Autonomous Loop and Tool Calling Mechanism of AI Agents

An Agent can help us accomplish these things because its operating logic is an autonomous loop. Academically, this mechanism is called the ReAct loop, which is the continuous repetition of three steps: Think, Act, Observe.

We can understand this through the scenario of renaming images.

• Think: The Agent first analyzes the overall task we gave it and decides to first check what files are in the folder.
• Act: It calls the file search tool to read the folder's contents.
• Observe: It sees the file list returned by the search tool, finding there are five images.
• Think: Based on the obtained image list, it decides to call the file renaming tool.
• Act: It runs the renaming tool and modifies the file names.
• Observe: It confirms the renaming tool returned a success message, verifying the task is complete.

In this loop, the most important part is the tool calling mechanism. The Agent itself doesn't have the ability to modify files or control the computer. It indirectly controls the computer by calling the tools we provide it, such as tools for running terminal commands or reading files. If a tool runs into an error, it gets the error message during the Observe step and then finds a solution on its own in the next Think step, without needing our intervention.

Why File System and Command Execution are Core to Agents

Among all the tools an Agent can call, two are the most fundamental: file reading/writing and terminal command execution.

Why are these two so important? Because almost every operation on our computer can ultimately be broken down into "reading/writing files" and "running commands." Writing code is writing files, installing software is running commands, changing configuration is writing files, running tests is running commands, making spreadsheets is writing files, compressing images is running commands.

As long as an Agent has the abilities of file reading/writing and command execution, it can theoretically do anything we can do on a computer. Because any complex operation can be decomposed by it into a series of file operations and command executions.

This also explains a trend: why these tools originally called Coding Agents are gradually becoming general-purpose Agents.

From Coding Agent to General-Purpose Agent

First, let's talk about what a general-purpose Agent is.

There are many types of Agent products on the market. Some are specialized for one thing, like writing emails, making PPTs, or doing data analysis. These types of Agents usually have a fixed work interface and preset workflow, and what we can do is limited to the scope designed by the product manager.

A general-purpose Agent, on the other hand, is not limited to a specific scenario. It has full access to the file system, can execute arbitrary terminal commands, and can install and call various tools. Whatever task we give it, it does. There's no "I don't have this feature" limitation. Its capability boundary depends on how many tools it can call, not on which features the product manager pre-set.

Tools like Codex, Claude Code, and Cursor were originally designed for programmers to write code. But people gradually realized that writing code is nothing more than reading files, modifying files, and running commands. So, helping me organize documents is also reading and modifying files, right? Helping me do research is also running some search commands? Helping me batch process images is also running some scripts?

These Coding Agents already have full access to the file system and command execution capabilities. They are naturally capable of doing much more than just writing code. It's just that the earliest user base was engineers, so everyone thought they could only write code.

OpenClaw takes a different path. It was positioned as a general-purpose Agent from the start, targeting not just programmers. It can integrate with instant messaging tools like WeChat and Feishu, allowing you to control your computer from your phone to execute tasks. It comes with built-in memory and persona systems, and its interaction style is more like a personal assistant.

But if we look at the underlying capabilities, OpenClaw and Codex are essentially the same thing: file reading/writing + command execution + browser control + autonomous loop. The only difference is that OpenClaw entered from the "general assistant" angle, while Codex entered from the "programming tool" angle. They are both evolving in the same direction — becoming a general-purpose, operating-system-level Agent that can do anything.

Codex has now added a desktop client, browser control, Computer Use, image generation, scheduled tasks, and mobile remote control. It's no longer just a programming tool. And because OpenClaw wasn't designed for writing code from the start, it's not inherently good at handling complex programming tasks. So the official team provided a Skill called coding agent. Its function is that when we ask OpenClaw to write code, it doesn't try to do it poorly itself; instead, it finds Codex or Claude Code installed on our computer and delegates the programming task to these professional coding Agents. This itself shows that different Agents can collaborate and divide labor.

They will all eventually become the same thing: a general-purpose Agent with full system permissions, the ability to call any tool, and the capability to autonomously plan and execute tasks. They just have different entry points, interaction styles, and areas of expertise.

Understanding this, when we use Codex later, don't limit it to just writing code. Anything we do on the computer, as long as it can be broken down into file operations and command execution, can be handed over to it.

---

Common Model Selection

In the previous chapter, we clarified the essential difference between Agent products and ordinary AI chat products. In this chapter, let's talk about model selection.

Many people new to AI often get confused by various names. So before we choose a model, let's first clarify three concepts.

Clarifying the Difference Between Models, Agents, and AI Products

A name we often hear can represent completely different things in different contexts. Let's take Google's Gemini as an example.

First, the AI Chat Product. This is the software we use directly on a mobile app store or webpage, with a chat input box and various buttons. When we say "use Gemini to look up some information," we are referring to its AI chat product.

Second, the Large Language Model. This is the thing that actually does the thinking in the background. The Gemini 3.5 Flash we call via software or API is the large language model. The model itself has no interface; it's just a computational program running on a cloud server.

Third, the Agent Product. This is an automated system that uses the model's intelligence, paired with local tools. For example, Google's official Gemini Spark, or the main subject of this course, Codex.

Why do we need to emphasize this difference? Because when we use an Agent product like Codex or Cursor, we are using an Agent shell to select a large language model as its intelligent brain. The upper limit of an Agent product's performance depends on which model you configure for it.

Who is the Current Top Choice

Currently, the three strongest large model companies overseas are OpenAI, Anthropic, and Google. Each has its own strongest model series.

Previously, the capabilities of these three companies were very close, making it hard to say who was better. But as of the end of May 2026, the strongest models are very clear: OpenAI's GPT-5.5 and Anthropic's Claude Opus 4.7. In Agent execution scenarios, these two are currently the best-performing, top-tier models.

For a long time, the GPT and Claude series have been the top choices for AI programming and driving Agents. Based on my practical experience, as long as you can use these two models, there's generally no need to choose other inferior models for daily development and high-difficulty tasks.

Let's look at the characteristics of these three companies' models. They all natively support visual recognition.

Claude Series

The advantage of the Claude series is its strong programming ability and the best requirement understanding among the three. When you describe a slightly abstract or complex business logic to it, it can quite accurately grasp your true intent, and the code it writes has relatively tight logic. However, its disadvantage is its high price. Whether it's pay-as-you-go API calls or various premium subscription plans, its usage cost is the highest among the three.

GPT Series

The GPT series also has strong programming execution ability, but it is slightly inferior to Claude in understanding abstract requirements. If your instructions are not specific enough, it can sometimes have understanding deviations. However, its advantage lies in its high cost-performance ratio for actual use. Although the unit price per single model call isn't cheap, if you subscribe to a monthly plan like ChatGPT Pro or ChatGPT Ultra, the actual cost amortized over heavy development and high-frequency usage is much cheaper than Claude, and the usage quotas are more generous.

Gemini Series

The Gemini series performs averagely in Agent scenarios. Its tool calling success rate is not high, and its logical planning tends to go off track, making it unsuitable as a primary model for Agents. The latest Gemini 3.5 Flash has some improvements, but there's still a gap compared to the top two. However, Gemini's advantage is its good aesthetic sense; the copy and layout it writes are more natural and human-like, and it's cheap. I generally use it for design-related tasks.

Here's an often-overlooked problem: If you haven't used the strongest models, you are likely to be pessimistic about AI's performance.

I often receive paid consultations. Many people, before coming to me, were quite skeptical about whether AI could really help them do things well. When I asked them how they had operated before, they usually said they had used some ordinary product for a certain task, only to find that the AI's answers were terrible, or that when the task reached a certain depth, the model's hallucinations became severe, or it couldn't even understand their actual needs.

This is a misconception. The reason they think AI is no good is largely because they have never experienced a truly strong model. Using a weak model to run complex Agent tasks naturally yields poor results. But if you switch to GPT-5.5 or Claude Opus 4.7, many previously unsolvable problems become clear.

Of course, besides the model's own intelligence, another key factor determines the success or failure of a task: the harness capability of different Agent products.

"Harness" can be translated as a saddle or rig. In the Agent context, it refers to the design capability of the tool suite and underlying framework. Different Agent products have slightly different harness structures. Even when calling the exact same underlying large language model, a well-designed Agent framework can squeeze the model's intelligence to its limit through better tool scheduling, context guidance, and runtime error correction mechanisms. A crude framework, on the other hand, will cause the same model to make frequent errors. Therefore, while choosing a top-tier model, we also need to pair it with a well-designed Agent product.

What is Multimodality and Its Practical Scenarios

When looking at model specification sheets, we often see the terms unimodal and multimodal.

In simple terms, modality is the sensory channel through which the large model communicates with the outside world.

Traditional unimodal models only have one sensory channel: pure text. They can only read and write text and code, and cannot directly perceive image and audio data. Multimodal models, on the other hand, add vision, hearing, and speech generation to the large model. They can not only read plain text but also directly understand images, videos, and even analyze audio recordings you send them.

In a web chat, multimodality might just let you send an emoji. But in the execution loop of an Agent product, different modalities combined with specific automation tools can directly help you solve many tedious tasks.

Application in Web Design and Web Page Restoration

In the past, if we wanted AI to help us write a webpage, we had to use hundreds of words in the dialog box to describe it very tediously: put a gray-white input box in the top left, a dark blue button on the right, a faint grid gradient background... Despite all this effort, the interfaces written by unimodal models were often ugly.

• Generating Design Drafts: We can directly use image generation tools like GPT Image 2 for UI design. Many people might search online for various image generation prompt templates, but that's unnecessary. Within an Agent, we just need to give a general requirement (e.g., "make a minimalist style Dashboard page"), and the AI will write a suitable image generation prompt itself. Those particularly long English prompts you see online are mostly written by AI, not by humans. Also, providing a reference image when generating images yields much better results than pure text descriptions. The AI can extract style, color scheme, layout, and other information from the reference image much more precisely than we can describe with text. Another tip: if you see an image and want to know its generation prompt, just throw the image into any multimodal model that supports image input and ask it to reverse-engineer the prompt.
• Precisely Restoring Web Pages: You can directly send the generated design images, or screenshots of any excellent website you find online, to a top-tier model with vision capabilities (like GPT-5.5, Claude Opus 4.7, or Gemini 3.5 Flash, which natively supports video and ultra-long image stream recognition). It will scan the image, extract the page's color HEX codes, container border radii, text line heights, and margins, and then directly write highly accurate HTML and CSS code. This process of going directly from an image to a webpage is something unimodal models cannot do.

Practical Effect in Subtitle Proofreading

When doing video production or subtitle transcription, we often encounter errors where homophones are incorrectly transcribed. For example, if we say "Claude Code" (the programming tool) in the video, ordinary speech recognition engines, having only the single modality of hearing, often recognize it as "cloud call." Top-tier multimodal models (like Claude Opus 4.7, which natively supports long videos and keyframe awareness) can handle this.

In an Agent's automatic editing workflow, it employs a proofreading method that combines two modalities:

• Step 1: Generate an initial subtitle draft via audio transcription.
• Step 2: The Agent performs keyframe OCR scanning on the video frames in the background. The model checks the code, website logos, or window titles appearing on the computer screen in the video frames.
• Step 3: The model cross-references the "Claude Code" displayed on the screen with the homophone "cloud call" heard in the audio. Once it detects an inconsistency, it combines the context to automatically correct the erroneous subtitle to the accurate proper noun and handles capitalization. This audio-visual joint proofreading, using vision to correct hearing, is a practical application of multimodality in production scenarios.

The Difference Between Native Multimodality and Plugin Multimodality

Here, you also need to pay attention to a detail: the performance gap between native multimodality and plugin multimodality.

Many domestic models and some open-source models do not natively support image and audio data input when calling their APIs. If they want to process images, they must rely on the Agent framework to configure temporary ASR or OCR plugins locally for relay. This temporarily spliced modality calling is slow and often fails due to complex image backgrounds.

In contrast, models like OpenAI's GPT-5.5, Anthropic's Claude Opus 4.7, or Google's Gemini 3.5 Flash natively support multimodal input at the underlying algorithm level. When executing high-frequency, complex automated browser control tasks, native multimodal models are almost the only choice.

What to Look for When Choosing an Agent Model

When chatting with AI on a webpage, we usually just care if it answers intelligently. But when deploying it in an Agent to execute tasks, the evaluation criteria change. Based on my experience, a model suitable for an Agent should be evaluated on these aspects.

Conversational Quality in Reporting

During Agent operation, the model needs to frequently report to you what commands it plans to run, what files it will modify, and ask for execution permission. If the model's replies are very stiff and obscure, using complex language to explain simple problems, it becomes difficult for you to understand its plan and build trust.

For example, the earlier GPT-5.4 had this problem quite noticeably, writing very complex plans. The latest GPT-5.5 has improved significantly in daily conversation, mostly using plain, straightforward language. Conversely, while Claude Opus 4.7 has improved its programming ability, its tone has become slightly stiffer and more mechanical compared to version 4.6, sacrificing some conversational warmth.

Obedience After Multiple Context Compressions

When an Agent product continuously executes long tasks, the context rapidly increases. When the context reaches a certain length, the Agent product automatically triggers a compression mechanism to condense previous conversations and tool execution records.

After multiple context compressions, many ordinary models start to experience memory loss or become lazy, easily messing up previously established code plans. In this regard, GPT-5.5 demonstrates very strong instruction-following ability, strictly adhering to previous instructions even after long tasks and frequent compressions.

Stability in Modifying Large Files

Agent products need to frequently modify our local files. They typically read a file first, then use search-and-replace to modify a segment of code within it.

If the model is not stable enough in this area, it might be fine editing small files of a few dozen lines, but when editing large files of several hundred lines, it is prone to replacement failures or even arbitrarily deleting unrelated code.

In terms of local file editing stability, Claude Sonnet 4.6 and Claude Opus 4.7 perform very well. On the other hand, the domestic MiniMax 2.7, while fast and good at long context understanding, often experiences localization failures or causes large sections of code to be rewritten and lost when modifying large files via an Agent.

Cost Decisions in Practical Development

When considering model costs, never just calculate based on the model API price list. In actual development with Agent products, the billing method and usage scenario are the key factors determining your bill.

Monthly Subscriptions Are Often More Cost-Effective Than API Billing

In the Agent product's ReAct loop, every time the model runs a tool or views a file, it needs to re-read all previous conversation history and project code structure as context. This causes the number of tokens consumed per conversation to skyrocket exponentially.

If we rely entirely on API pay-as-you-go billing, complex development tasks involving a few modifications and debugging sessions can easily generate several or even dozens of dollars in costs. This makes you very hesitant and constrained during development.

My experience is: if you are doing heavy daily development, always choose a "monthly subscription" over "API billing" whenever possible. For example, subscribing to the $200/month ChatGPT Ultra plan and using GPT-5.5 or Codex in Cursor or Windsurf for high-difficulty programming means your monthly expense is fixed regardless of how frequently you ask questions and rewrite files. This way, you don't have to mentally calculate costs every time you write code, allowing you to focus entirely on solving the specific business problem.

Reducing API Costs Through Sub-Agent Distribution

If, due to team collaboration or software limitations, we must use API billing (e.g., using Claude Code to automatically run complex builds), we can significantly reduce costs by designing a primary-secondary model combination:

• Top-tier high-intelligence model only for designing the development plan: We let it design the modification plan in the main window. Since it doesn't need to actually run file modifications, the number of rounds in the main session is very low, the context is clean, and the overall cost is very low.
• Low-cost secondary model as a sub-agent to specifically modify files: The main Agent passes the finalized plan to the sub-agent. The sub-agent performs high-frequency file reading, modification, retries, test error handling, and recompilation in the background. Although this process generates a large number of tokens, the unit price of the secondary model is very low (often one-tenth or even less of the top-tier model), so the total expenditure is much lower.

Choosing Cost-Effective Models Based on Specific Scenarios

Different models have different strengths. You need to dispatch them precisely based on the task type to avoid overkill:

• Writing Code and Design Restoration: If we need to write some nice page layouts, design UI layouts, or write plain-language marketing copy, we can directly call Gemini 3.5 Flash. It generates tokens very quickly, is very cheap, and inherently has excellent aesthetic sense and copywriting style. There's no need to consume expensive Claude quotas for these tasks.

Regarding the speed of model token generation, the industry generally uses the metric TPS (Tokens Per Second), which measures how many tokens a large model can output per second.

Your intuitive feel for TPS varies greatly between different models. If a model's TPS is below 50, you'll feel the output is very slow, with code and text appearing in a stuttering manner. Lightweight models like Gemini 3.5 Flash or GPT-5.4 mini typically achieve TPS of 150 to 200 or more.

This high TPS generation speed is very advantageous in practice. For example, for some webpage displays or small game requirements, users don't want to wait long. High TPS can make a whole page of React code generate and display on the screen in one or two seconds, significantly reducing wait time. If running a large refactoring in the terminal, a high-TPS sub-agent can also finish modifying files quickly, preventing you from waiting idly with your laptop closed.

Additionally, you might see a parameter called TTFT (Time to First Token), which is how many milliseconds the model needs to wait after you send an instruction before it outputs the first word. Lightweight models usually react quickly, with a first-word wait time of only one or two hundred milliseconds; while reasoning models with deep thinking enabled may require a first-word wait time of over ten seconds. When choosing a model, you should also consider these two speed dimensions.

• Running Single-Point Modifications and Error Troubleshooting: Several excellent domestic models (GLM-5.1, MiniMax 2.7, DeepSeek V4 Pro) perform very well in Chinese-English multi-tasking and regular code execution. However, you need to have clear expectations: when task complexity is very high or the context reaches hundreds of thousands of tokens, they are still more prone to localization failures and planning deviations compared to GPT-5.5 and Claude Opus 4.7. Therefore, I recommend using them under a sub-agent mechanism to specifically run already-determined single-point modifications, script executions, or routine error troubleshooting. This can save you a lot of development budget.
• Large Project Refactoring and Legacy System Maintenance: If your task involves complex code dependency refactoring or tracking down very subtle memory leaks, never skimp on costs by using a low-end model. For such high-difficulty tasks, low-end models, due to their imperfect logical planning, often get stuck in a loop of making errors, reporting errors, and failing to fix them again. This repeatedly consumes a large number of tokens. You think you're saving money, but the final bill ends up being more expensive than using GPT-5.5 or Claude Opus 4.7 to fix it correctly in one go.

My Model Combination Evolution

I basically do all my coding via Vibe Coding, never modifying files myself, relying entirely on talking to the Agent to execute tasks. After using it for a while, my model combination underwent a significant change.

In the past, I was used to a multi-model heterogeneous combination:

• Product Manager: Used Claude Opus 4.6. Its requirement understanding ability is strong, conversational quality is good, and code design ability is excellent.
• Daily Executor: Used GPT-5.3 Codex. Its API call price is very cheap. I had Claude delegate various mechanical, fragmented development tasks to Codex via sub-agents for execution.
• Designer: Used Gemini 3.1 Pro. Because Claude and Codex have a relatively monotonous aesthetic in visual design, while Gemini can design interfaces with very good texture based on simple requirements.

Now I no longer use this multi-model setup. I've gone All-in-One: Now I completely use Codex with GPT-5.5 for all my daily development tasks.

On one hand, GPT-5.5 fixed the previous issue of obscure language; its conversational quality and programming ability are both good now. On the other hand, I subscribed to the $200 ChatGPT Ultra plan, which provides ample quota. Even with heavy daily development, I can't use it all up, making its cost-performance ratio much higher than Claude.

As for the shortcoming in design aesthetics, I've already covered it by using my own open-source draw AI plugin, combined with GPT Image 2 for AI image generation to directly design interfaces, and then letting Codex restore the design images to HTML and write them into the project.

Introduction and Positioning of Codex

In the previous chapter, we discussed in detail how to choose a large language model suitable for an Agent. In this chapter, let's talk about the main protagonist of this course: Codex.

Many people, when first encountering command-line Agents, immediately think of Anthropic's Claude Code.

For a long time in the past, Claude Code was almost universally recognized as the most advanced and mature Agent product. This is because Anthropic has accumulated a lot of experience in Agent design and engineering implementation. They published a series of high-quality research articles quite early, including how to design tools, how to use progressive loading to design the Skill mechanism, and how to efficiently manage context space.

In my actual development and learning process, these articles were essential reading for me. Coupled with Claude's strong programming reasoning and requirement understanding abilities, Claude Code had no real competitors for a long time.

Since Claude Code is so strong, why did OpenAI's later-released Codex attract me and gradually become my daily driver? There's a very important industry background here.

For a long time before, OpenAI didn't put all its effort into Codex. They were more inclined to create broad-coverage multimedia AI applications, like the highly anticipated video generation model Sora. This allowed Anthropic, which had been deeply involved in the Agent field early on, to seize the initiative.

Later, the competitive landscape changed. At the end of March 2026, OpenAI shut down the Sora video application and API, shifting its strategic focus towards code generation and Agent directions.

To counter Anthropic's strong competition, OpenAI began to fully invest in Codex. They allocated top-tier computing power to support Codex's iteration, with high-frequency updates in the first half of 2026, launching a multi-platform desktop client and a more powerful underlying execution model. This is why Codex's capabilities have improved rapidly recently and are starting to catch up with Claude Code in development efficiency.

Let's start with Codex's current specific form.

What is Codex

In essence, Codex is a tool that runs within a local project. Its purpose is to help us execute specific coding tasks, run local compilations, or perform automated tests.

At its most fundamental design level, it has been refactored and written using the Rust language. Therefore, it starts up very quickly in our terminal, and when scanning large project directories or looking up code methods and definitions, there's almost no perceptible delay. Its local memory footprint is also very small.

If you're used to ordinary AI chat windows, you might think it's just a dialog box that writes code for you to copy and paste. But when we use Codex, starting it within a project directory allows it to interact directly with our local system at the file level. It can write code, compile, and run it itself, helping us complete those tedious tasks that would otherwise require many manual steps.

They Are Almost No Different

As the two most powerful terminal AI Agent products currently on the market, people often like to compare Codex and Claude Code comprehensively.

But in my actual usage experience, there is almost no difference in the feel of daily development between the two.

First, their core interaction flow and rhythm are completely identical. Both run in the local command-line terminal. After you type the start command, both enter a streaming, dark terminal interaction panel. When you input a development requirement, both will autonomously scan the project directory, read local files, and execute tests and compilations in the background. Before they make any code modifications or run sensitive terminal commands, both will display a confirmation prompt on the screen, waiting for you to press Enter to authorize.

Second, their core functionalities are completely interchangeable. Both seamlessly support commands like /goal for asynchronous long-term task execution. Both automatically trigger context compression mechanisms during long conversations. Both support the MCP protocol for extending tools. Both support creating custom Skills to standardize repetitive workflows.

Once you learn how to use one of these tools, switching to the other requires virtually no additional learning or adaptation cost.

The only minor differences lie in the underlying model brand, the shell's packaging form, and the stability of account security for domestic users:

• Model Ecosystem: Claude Code is natively bound to Anthropic's official Claude series models. Codex is an OpenAI product, defaulting to the GPT series models.
• Product Form: Claude Code is currently still a tool that runs purely in the terminal command line. Besides the command-line tool, OpenAI has also packaged a desktop application for Codex, making it easier to manage multiple parallel development tasks, along with a mobile client for multi-device linkage.
• Account Security: This is a very real pain point for domestic users. Anthropic's risk control mechanism is very strict, even showing obvious geographical restrictions against domestic IPs, leading to large-scale bans on accounts associated with China. Many people get their subscription or virtual card banned without warning within seconds of payment. This makes using Claude Code a high-risk endeavor with frequent disconnections and bans. In contrast, OpenAI's risk control logic for regular network access and payments from Chinese users is much more lenient and stable, with fewer frustrating account bans.

What's the Difference from OpenClaw

Many people might also ask about another recently popular tool: OpenClaw.

OpenClaw and Claude Code / Codex can essentially do the same things. They all have core capabilities like file operations, script execution, browser control, and web search. Anything OpenClaw can do, Claude Code can do, and vice versa.

But their product design orientations are different.

OpenClaw's most convenient feature is that it can be easily configured onto our Feishu, WeChat, or Telegram. We can talk to it from our phones and remotely control the computer to execute tasks, without needing to sit in front of the computer. It also comes with built-in Memory and Soul systems, constantly recording information from our conversations into its memory and refining its persona.

Claude Code, on the other hand, is a tool focused on writing code. It has practical capabilities for engineers like Task decomposition, Worktree separation, and LSP semantic navigation. Most people using Claude Code don't bother with complex memory systems because the code repository itself is its memory. Its job is related to writing code; reading the existing code tells it what the project does, what conventions and design styles it has. Keeping the context clean leads to better task execution.

Here's an observation of my own: OpenClaw, with its memory and soul, provides some emotional value, but its effectiveness in handling serious work tasks is not as good as programming tools like Claude Code. When you want to call an Agent to execute a task, the shorter and higher quality the context, the better. A bunch of memories unrelated to the current task stuffed into the context actually hinders its execution ability.

However, they are not mutually exclusive. I use both myself. OpenClaw even officially provides a Skill called coding agent. This means if we ask OpenClaw to write code, it will find out if we have Codex or Claude Code installed on our computer and delegate the programming task to them. They have a division of labor: OpenClaw is like a smart assistant, handling lightweight to-do management, file organization, information retrieval, and mobile remote control; while Codex or Claude Code handles complex programming, architecture design, and long-duration engineering tasks.

Why I Choose to Use Codex

In reality, the differences between various Agent products aren't as big as imagined. My main reason for choosing Codex is that its combination with GPT-5.5 provides good overall results.

On one hand, for high-intensity daily development, I subscribe to the ChatGPT Pro monthly plan, which provides more than enough quota. Compared to the restrictive and expensive API pay-as-you-go model, this unlimited quota allows me to experiment and make mistakes freely, which is a great experience.

On the other hand, GPT-5.5 performs very well in the image generation modality. It seamlessly supports the official latest GPT Image 2 image generation tool. In daily use, we can even use image generation directly within the conversation to help us design and iterate UI interfaces or creative assets.

Cursor as an Alternative Entry Point

Here's a practical supplement. To use Codex, we need to subscribe to ChatGPT Pro, which requires a US phone number or credit card for payment. The same goes for Claude Code; Anthropic's subscription has a higher barrier for domestic users, plus the risk of account bans. Many people get stuck at this step.

If you can't directly subscribe to GPT for now, don't have a US phone number or credit card, but still want to quickly experience the effect of multiple top-tier models paired with an Agent, you can use Cursor.

The advantages of Cursor are:

It's a desktop application with a very low download and installation barrier. All configurations (Plugins, Rules, Skills, MCP) are visual, with clickable options, so you don't need to type slash commands in the terminal.

It aggregates the strongest current models. GPT-5.4, Claude Sonnet, Opus, Gemini 3.1 Pro — these models are all inside, and you can choose which to use.

It's not tied to a single model vendor. With Codex, I can only use GPT; with Claude Code, I can only use Claude. But Cursor has both top overseas models and some domestic models, allowing us to switch freely and compare which works better.

Of course, Cursor also requires a VPN and a subscription ($20), but it's much simpler than the whole process of getting a US account, binding a virtual card, and configuring an API Key. If you can solve the payment issue and subscribe directly to ChatGPT Pro, it's still recommended to use Codex directly for a more complete experience.

In the next chapter, we will officially start setting up the Codex runtime environment and dissect its configuration files in detail.

---

Installation and Basic Configuration

Before deciding to use Codex, we need to prepare the local runtime environment, log in to the software, and complete the basic parameter configuration.

Runtime Environment We Need to Prepare

Because when we ask the Agent to write code or run daily tasks, it often needs to use various external dependencies, it's recommended to install the following two most basic environment tools on your computer first.

First, the Node.js environment. It's recommended to install the latest LTS stable version directly. This is because when we later load and manage various external tools and publish plugins via the MCP protocol, most underlying scripts depend on the Node.js runtime environment. Second, the Git tool. Because when the Agent automatically modifies code and executes /goal long-term tasks, it needs to automatically perform local code diffs, create new branches, and commit code locally. Therefore, a local Git command-line environment is essential.

How to Download and Install the Desktop Client

This course completely does not require and does not recommend you to type commands directly into the dark terminal command line. All our tasks and management will be completed directly in the official, visual desktop software:

• macOS Users: Directly visit the Codex official desktop page to download and install. If your Mac has an Apple M-series chip, choose the Apple Silicon hardware version; if it's an older Intel chip, choose the Intel version.
• Windows Users: Directly visit the Windows Microsoft Store Codex page for a one-click download and installation.

After installation, just double-click to open the software.

Windows Users Note: Codex supports the native PowerShell sandbox on Windows, so you don't need to install WSL or a virtual machine. However, if your project depends on Unix commands (like sed, grep), you might still need to configure Git Bash or WSL. Most daily use won't encounter problems.

Once opened, the left side is the navigation bar: New chat, Search history, Plugins (Plugins and Skills), Automations. The middle is the conversation area. The bottom is the input box, where all our interactions with the Agent begin.

Logging into Our Account

When you open the Codex desktop application for the first time, simply click "Log in" on the interface. The system will automatically pop up a login page in your default web browser. Just log in with your existing ChatGPT Plus or ChatGPT Pro subscription account to authorize.

It's worth noting that although the official team still supports OpenAI API keys (i.e., entering a key starting with sk-) for separate token billing, for heavy development, high-frequency context reading will cause the API charges to accumulate quickly. You might spend dozens of dollars in just a few days. Therefore, my most recommended approach is to directly log in with an already subscribed ChatGPT Plus or ChatGPT Pro account and use the included quota. This will save us a lot of development costs and completely eliminate bill anxiety.

Entry Point for Modifying the config.toml Configuration File

After completing the account login, we can modify its operating rules and basic parameters. All of Codex's parameters are controlled through a configuration file called config.toml.

We can find the entry point for modifying this file directly in the visual interface. In the left navigation bar, click on the Configuration panel, and you will see an Open config.toml button on the right.

Click it, and the system will automatically open your local text editor to edit the global config.toml configuration file. The interface entry point is as follows:

If you are modifying this .toml file in Cursor or VS Code, I suggest typing the following line at the very top of the configuration file. It will provide you with parameter auto-completion and format diagnostics:

#:schema https://developers.openai.com/config-schema.json

Common Core Parameter Configuration

In this opened config.toml file, the following parameters are the most commonly used when we write code and do automation tasks later. It's recommended to configure them on the first day.

• Feature Toggles ([features]):
  • goals = true: Enables the powerful asynchronous long-term task (/goal command).
  • hooks = true: Enables writing automated Hook mechanisms to listen to and extend Agent runtime events.
• Common Core Parameters (root level):
  • model = "gpt-5.5": Recommended global default main model.
  • model_reasoning_effort = "high": Reasoning depth. Options: low / medium / high. Low is fast but shallow analysis; high is slow but strong reasoning. I use medium daily and switch to high for complex tasks.
  • sandbox_mode = "workspace-write": Sandbox mode. This setting determines which files the Agent can touch. workspace-write only allows modifying files in the current project directory; read-only allows viewing but not modifying; if set to a completely unrestricted mode, it can modify files anywhere on your computer, which is generally not recommended.
• External Tool Interfaces ([mcp_servers]):
  • [mcp_servers.filesystem]: Controls the loaded local file system plugin, defining the command (npx), arguments (@modelcontextprotocol/server-filesystem), and activation status (enabled = true).
• Account and Billing Permissions ([billing]):
  • model_provider = "chatgpt": Binds to ChatGPT's premium subscription service, linking the large model execution quota to your ChatGPT Plus ($20/month) or ChatGPT Pro ($200/month) personal billing quota.

This parameter specification is fully synchronized under the latest 2026 software ecosystem. If we later debug new tools (like Git commit, Browser control, etc.), we will also record and supplement the real-time parameters in the corresponding chapters.

After completing these core parameter configurations, save the file using the shortcut key, and our dedicated Codex console is fully configured.

Here's a very handy little trick: Since you're already using Codex, for most config.toml configuration parameters, you don't actually need to open the file and modify them line by line yourself.

Because Codex, as an Agent capable of directly reading and writing files, has the ability to modify the configuration file itself. We just need to send it a command in the chat box, like: "Help me change the default model in the config file to gpt-5.5 and set the reasoning effort to high," or "Help me turn on the goals feature toggle in the config file."

It will then find the config.toml file in our personal root directory, modify these configuration lines on its own, and display the modification plan on the screen before making changes. This lazy approach of letting AI configure AI is the intuition you should cultivate when using an Agent.

Skill Trigger Entry Point

In the Codex desktop client, click on Plugins on the left, switch to the Skills tab, and you can see all currently installed Skills. During a conversation, we can manually trigger a Skill using $skill-name, or simply speak and let Codex automatically match based on semantics.

Skill is a very core extension mechanism of Codex. We will explain its principles, how to find them, how to install them, and how to write your own in detail in Chapter 8 later. For now, just know where to see them.

Starting from the next chapter, we will officially enter the practical operation of specific functions.

---

Context Engineering

I was chatting with a friend who doesn't use AI much, and he told me something that surprised me. He said he thought AI gets smarter the more you use it, like raising a pet — the more time you spend with it, the better it knows you and the smarter it gets.

Then he told me about a problem he actually encountered. He chatted with Doubao for a whole day. It started well; it remembered his name and what he had said before. But as the conversation went on, he suddenly noticed that Doubao seemed to forget who he was and couldn't remember what they had talked about earlier. He was very confused and asked me, "Isn't this AI supposed to get smarter? Why did it suddenly get dumber?"

I believe many people share this confusion. Before we officially start using Codex, it's necessary to clarify the concept of context. Because everything we'll discuss later — thread management, Goal commands, compression mechanisms — is all related to this.

AI Doesn't Get Smarter by Chatting with You

This might be the biggest misconception for many people.

Once a large language model is trained, its capabilities are fixed. During our conversation with it, it doesn't "learn" new knowledge, nor does it become smarter just because we chat a bit more. It simply reads the information we give it and answers based on that information.

So why does it seem to "understand you" so well at the beginning? Because what we said to it earlier is still within its "field of view." But this field of view has a boundary.

Every Conversation is Stateless

Many people don't know this. We feel like we're having a "conversation" with the AI, and it seems to "remember" what was said earlier. But in reality, the model itself has no memory. Every time it generates a response, it's a completely new inference starting from scratch.

So how does it manage to "remember" previous conversation content? The answer is simple: every time we send a message, the product packages up all the previous conversation history in the background and sends it all together, along with our latest message, to the model. The model reads through all this content from beginning to end and then generates a response.

In other words, when we send the tenth message, the model actually receives the complete record of the previous nine rounds of Q&A plus our tenth message. It answers each time only after "reading the entire chat history," not because it actually "remembers" anything.

This understanding is crucial because it directly explains why AI gets slower, more expensive, and dumber the longer you chat: each new message requires resending all the previous content. The longer the chat, the larger the amount of information per round.

The Essence of Context: A Complete Archive with a Size Limit

Having understood the above, context becomes easy to explain.

Each time the model answers a question, it has a complete archive in front of it. This archive contains:

• System behavior rules given to it (e.g., "You are a helpful assistant")
• All messages we have sent previously
• All content it has replied with previously
• Results of intermediate tool calls (e.g., what files it read, what web pages it searched)

Each time it answers, it reads this entire archive from beginning to end and generates the next sentence based on all the content within it.

This archive is the context.

The problem is that this archive has a size limit. The archive capacity varies for each model, usually measured in the number of Tokens. One Token is roughly equivalent to one Chinese character or half an English word.

How Big is the Context for Different Models

Currently, the context window sizes of mainstream models vary greatly:

Model	Context Window
GPT-5.5 / GPT-5.4	1,050,000 Token
Claude 4.7 Opus / 4.6 Sonnet	1,000,000 Token
Gemini 3.5 Flash / 3.1 Pro	1,000,000 Token
Qwen 3.7 Max	1,000,000 Token
DeepSeek V4 Pro	1,050,000 Token
Doubao Seed 2.0 Pro	256,000 Token
Kimi K2.6	262,000 Token
MiniMax M2.7	205,000 Token
DeepSeek R1	164,000 Token

Currently, top-tier models have basically reached the level of 1 million Tokens, roughly equivalent to being able to hold about 2500 pages of plain text. Some models are still around 200,000.

What does a large context window mean? It means we can stuff more background information into a single conversation. For example, if we ask an Agent to analyze a large code project, a larger context window allows it to read more files at once, leading to a more complete understanding of the overall architecture. If the window is too small, it can only see a part, making it prone to one-sided judgments.

For an Agent, a large context also has another benefit: it can execute longer task chains without triggering compression. The results of each tool call (file contents, terminal output, webpage content) are written into the context. A complex task can easily consume hundreds of thousands of Tokens. Models with larger windows can last longer before needing compression, resulting in better task execution coherence.

What's Inside an Agent's Context

In an Agent like Codex, the composition of the context is much more complex than in ordinary AI chat products. What we see on the chat interface is just a few messages, but in the background, the archive sent to the model for each round of dialogue contains a lot of things:

• System Instructions — Agent behavior rules, JSON Schema descriptions of available tools, current working directory, date and time, and other basic information
• Skill Descriptions — If we have installed Skills, the trigger conditions and descriptions for each Skill are written in
• Our Messages — Just what we type in the input box
• Model's Replies — Including the text replies it generates
• Chain of Thought — The model's reasoning process before answering (can be very long in models that support thinking)
• Tool Calls and Results — Which files it read, the complete content of those files, what terminal commands it ran, the terminal output, what web pages it searched, the content of those web pages

All of this piled together constitutes the true context volume of a single round of dialogue.

We might have only sent a message like "Help me look at the structure of this project," but the Agent might have read a dozen files in the background, each with hundreds of lines of code, run several terminal commands, and all these results are written into the context. A one-sentence task might actually consume tens of thousands or even hundreds of thousands of Tokens.

The biggest source of consumption here is often the return results of tool calls. A file might be thousands of lines, a terminal output might be hundreds of lines, a scraped webpage might be tens of thousands of words. Once these things are written into the context, they stay there, and every subsequent round of dialogue has to resend them.

Context is an Attention Budget

Anthropic, in their official article, proposed a concept I find very helpful: context is a limited attention budget.

What does this mean? Every piece of information we stuff into the context consumes the model's attention. If the context is full of information highly relevant to the current task, the model's attention is focused, and execution is good. But if a large amount of information irrelevant to the current task is mixed in — like the full text of a file read thirty minutes ago, the return result of a tool that's already been used, or descriptions of a bunch of Skills that will never be triggered — then the model's attention is distracted by this noise.

Therefore, the core principle of context engineering is not "stuff more things in," but "only put in the most useful things." The density of information is much more important than the total amount of information.

This also explains a phenomenon: some people install a bunch of Plugins, each with dozens of Skills, and the descriptions of all these Skills are written into the context. Although most of them won't be triggered most of the time, their descriptive text is always there, occupying space and distracting attention. More Skills are not better; more accurate and better suited to the usage scenario is better.

Why Does It Get Dumber the Longer You Chat

Back to my friend's question. He chatted with Doubao for a day, so why did it later forget who he was?

There are two reasons.

The first reason is that the context filled up, and the earlier content was dropped or compressed. When the archive can't hold any more, the product either directly deletes the earliest conversation content or replaces the original detailed content with a short summary. After the replacement, those details are lost.

The second reason is more important. Anthropic calls this phenomenon Context Rot in their official documentation: As the number of Tokens in the context increases, the model's accuracy and recall ability decrease.

This means that even before the context is full, if there's too much stuff crammed in, the model's ability to find key information deteriorates. It's like an archive densely packed with tens of thousands of words; asking it to find a specific detail from the first page is likely to be inaccurate.

So, AI does not get smarter the more you chat. In most cases, the longer the context, the lower the AI's execution quality. The density of useful information is the key.

How to Keep Context Efficient

Having understood the principles above, we can actively manage the quality of the context. Here are some practical ideas:

Fetch on demand, don't preload. Don't stuff all potentially useful information in at the beginning. Let the Agent fetch it itself when needed. For example, let it read a file when it needs to see it, rather than stuffing the entire project's file list into the context at the start.

Use sub-agents to isolate context. If a task requires reading a lot of code to find a key location, let a sub-agent do the exploration first. It reads dozens of files in its own context and finally returns only the key paths to the main Agent. This keeps the main Agent's context lean. I wrote a Skill called Explore specifically for this.

Clear out used tool results. After an Agent reads a file, makes a judgment, and writes code, the content of that file is no longer needed in subsequent conversation turns. Good Agent products automatically clean up these expired tool return results, keeping only the record of the tool call (what was called, what the conclusion was) and discarding the original large chunks of returned content.

Write important information externally. If some information might be needed later, instead of letting it occupy space in the context, have the Agent write it to a local file. Read it when needed later. This is much more efficient than having tens of thousands of words of information sitting in the archive.

Codex's Compression Mechanism

Codex automatically handles the problem of overly long context. When the Token usage of the context approaches 90% of the window size, it automatically triggers a compression.

The compression process goes something like this: the previous conversation history is given to the model to generate a summary. This summary then replaces all the original content, keeping only the most recent conversation and the summary. It's like condensing a thick stack of files into a single page, freeing up space to continue the conversation.

This is why, after chatting in Codex for a long time, you might sometimes feel it has "forgotten" some previous details. It hasn't gotten dumber; those details were simplified during compression.

Compression has a cost. Once triggered, the original information is irreversibly lost, leaving only the summary. If a key detail wasn't captured by the summary, it's gone. So, instead of waiting for the context to fill up and be passively compressed, it's better to actively control the context length — start a new thread for a new task, keeping each thread short and focused.

This is also why the next chapter is about thread management and conversation skills: understanding the nature of context allows us to collaborate better with the Agent.

---

How to Talk to AI

In my many conversations with people about their Agent usage experience, I've noticed a very common phenomenon: people spend too much time writing prompts.

Many people's habit is to brainstorm in their head for a while before opening the Agent, then write a long paragraph and throw it over in one go, trying to cram the goal, steps, format, constraints, and exception handling all into the first sentence. They think if they don't say it all clearly from the start, the AI will definitely do it wrong.

This mindset might have been correct when using the ChatGPT web version in the past, because the models weren't as capable then, and they didn't have tools to look up information themselves. We really did have to feed them everything.

But it's different now.

The Other Extreme: Afraid to Speak

Contrary to over-engineering prompts, there's another group of people who are even hesitant about how to talk to AI.

I've met many people who come to me for consultation. Their questions could easily be answered by just asking an Agent. But they prefer to ask a human who has used it.

I think there are two reasons. The first is a psychological barrier. Many people still treat AI as a search engine, thinking they need to have the question very clear and the wording very precise before they can ask. It's like using Google in the old days; if the keywords weren't right, you wouldn't find anything. They haven't yet developed the mindset of "just ask anything."

The second is not knowing what it can do. They have no concept of the Agent's capability boundaries, are unsure if it can answer the question or if the answer will be correct, so they prefer to ask a human.

But in reality, the current Agent is not a program that requires precise input to run. It's a conversational partner you can talk to about anything. You can use any tone; if you're wrong, it will correct you; if you're unclear, it will ask you clarifying questions. You can even say directly, "I don't know how to describe this problem," and it will guide you to clarify it.

So my advice to beginners is: don't overthink it, just send it out. If you're not satisfied, the direction is wrong, or the description is unclear, you can continue chatting and refining. The cost of talking to an Agent is very low; don't mentally turn it into a high-threshold activity.

The Models Are Already Very Strong

The top-tier models of 2026, whether GPT-5.5 or Claude Opus 4.7, already have a very deep understanding of best practices for various technologies. For example, if you ask it to write a user registration feature, it inherently knows that passwords need to be encrypted, input validation is needed, API status codes should be standardized, and error messages should be user-friendly. You don't need to list these things one by one in your prompt.

The only thing we really need to do is: figure out what we actually want.

Often, the reason our conversations with an Agent are ineffective is not because the prompt isn't detailed enough, but because we ourselves haven't figured out what we want. We shift the responsibility of "clarifying the requirements" to the complexity of the prompt, thinking that writing more is safer. But a short sentence with a clear goal is far more useful than a long, vague paragraph.

The Agent is Not a Script, It's a Collaborator

Unlike chatting with the old ChatGPT, an Agent can engage in continuous communication. It can ask us questions, read files to supplement information, and check code to see existing conventions. We don't need to explain everything in the first sentence.

A practical example:

Some people write prompts like this: "Help me write a user management module, with registration and login functionality, use JWT for authentication, bcrypt for password encryption, PostgreSQL for the database, include email verification, send a verification email after registration using Resend, use React for the frontend, React Hook Form with Zod for form validation, error messages in Chinese, RESTful API style, standardized status codes..."

Writing this long paragraph takes several minutes, but half of the information in it, the Agent could have figured out from the project itself. It can open package.json to see what framework you're using, and glance at the existing code to understand your style conventions.

My approach is usually to say just one sentence first:

"Help me create a user registration and login feature."

After sending it, the Agent might ask back: "Do you need email verification or phone number? Any preferred authentication method?"

I then supplement a few key decisions. The rest, it will figure out by looking at the project, seeing how the existing code is written, and making its own judgments.

Why One-Shot Long Prompts Are Worse

Besides wasting time, cramming too much information into one go has several practical downsides:

First, it consumes the context budget. As discussed in the previous chapter, the more information crammed into the context, the more the model's attention is scattered. If a prompt of several hundred words contains half the information the Agent doesn't need (like best practices it can judge on its own), those words are wasting the attention budget.

Second, if we preset too detailed execution steps, we actually limit the Agent's own planning ability. It might have a better implementation path than we thought, but because we've fixed the steps, it can only follow our instructions.

Third, the time spent writing a very long prompt is often slower than breaking it into two or three rounds of dialogue. Many times, spending ten minutes mentally constructing a prompt is less efficient than spending one minute writing a short goal, sending it, and then gradually supplementing it in the conversation.

The Agent Can Get Information Itself

This is the biggest difference from the ChatGPT web version. The Agent has tools; much information doesn't need to be manually provided by us:

• What's the tech stack → It reads package.json or requirements.txt itself
• Code conventions → It looks at the style of the existing code itself
• Database structure → It reads the schema file or migrations itself
• Project structure → It scans the directory itself
• How did someone else do this feature → It searches itself

We only need to tell it two things: what I want, and any special constraints. We don't need to teach it how to do it.

When to Say More

It's not that one sentence is always enough. There are situations where you do need to provide more context:

• Clear business constraints — e.g., "Don't modify existing API interfaces," "This feature is only for paying users"
• Acceptance criteria — e.g., "Only done when all tests pass," "Page load time must not exceed 2 seconds"
• Personal preferences — e.g., "I don't like using class components," "Use English for variable names, not pinyin"
• Special context the Agent can't see — e.g., requirements verbally communicated by the product manager, conventions not yet documented

But note, these are information at the "constraint and goal" level, not the "execution step" level. We tell it "what not to touch" and "what counts as done," not "what to do first, what to do second."

The Rhythm of Conversation

My own rhythm for talking to an Agent is roughly like this:

State the goal first. Briefly describe what I want to do, without rushing to give a plan.

Let it look before acting. If working in an existing project, I'll ask it to look at the relevant code first before making changes. This way, it makes decisions based on existing code, not guesses.

Let it propose plans when unsure. If a problem has multiple implementation approaches, I won't think about it myself and tell it which one to use. I'll ask it to give me a few options, and I'll choose. Because it has seen more solutions than I have.

Correct direction immediately if it goes off track. If I find it's going in the wrong direction midway, I directly say, "This isn't what I want. I want..." There's no need to restart the thread from scratch; correcting within the current conversation is more efficient.

Use /side for unrelated questions. If I want to ask a question unrelated to the current task midway, don't ask it in the main conversation. Use the sidebar feature mentioned earlier to ask, and don't pollute the main context.

The Essence of Conversation

Talking to an Agent is not about writing a command for it to execute; it's about figuring out together what needs to be done, and then letting it do it. We are responsible for providing the goal and constraints; it is responsible for planning and execution. The model's understanding of most technical solutions is already very deep. We don't need to teach it how to do it; we just need to figure out what we want.

Using Voice Input to Speed Up Conversation

Since talking to an Agent is an iterative process, input speed is important. I personally use a lot of voice input, which is much faster than typing, especially for describing requirements in a conversational tone. Speaking is more natural than typing.

Codex has a built-in voice input feature, a small microphone icon in the bottom right of the input box. Clicking it uses OpenAI's model for speech-to-text. However, if you have other local voice input tools, the experience is better because the response is faster and doesn't require network waiting.

I use Shandianshuo. Holding down the right Option key triggers it, and the text appears as soon as I release it. It supports local and cloud recognition models, and can automatically filter colloquialisms and structure the text, making our spoken language a bit more formal. It's free and supports both Mac and Windows.

If you're willing to pay, Typeless is a cross-platform choice (Mac, Windows, iOS, Android). Press the Fn key to speak, and it uses AI to polish colloquial speech into written language before outputting, providing a smooth experience. There are also open-source solutions like local Whisper deployment, suitable for privacy-conscious people.

For Vibe Coding, the efficiency improvement from voice input is significant. We don't need to organize our requirements into precise text in our minds before typing; we just speak. If it's not clear enough, the Agent will understand or ask clarifying questions.

---

Thread and Project Management

In daily heavy development or routine chores, how you efficiently organize your projects and sessions directly determines the Agent's execution efficiency and your own user experience.

In this section, let's talk about how to manage threads and projects in the Codex desktop application.

The Logic of Dividing Code Projects and Daily Chores

When you see the Projects list on the left side of the desktop, you need to use completely different directory mounting logic based on the task type. These are two core habits I've developed through my usage:

• Code Repository Projects: If I have a specific code directory, like an actual code repository such as museon or wolfcha, I will directly open it as an independent project in the Projects list on the left. For all subsequent bug fixes, feature iterations, or code scans related to this repository, I will open new threads within this project to run them. This ensures the context is very clean, allowing the Agent to focus only on the local code of this one repository.
• Daily Chores Project: For a bunch of daily tedious tasks, like adding subtitles to videos, doing some specific domain research online, or brainstorming topics for my Xiaohongshu posts, I absolutely do not create a bunch of new projects for each one. My approach is to directly mount my user root directory (e.g., /Users/linzhihuang) as a project on the left.

After opening the user root directory on the left, the interface entry point looks like this:

Why mount the entire user root directory? Because many daily chores often require reading files from different paths on our computer. For example, video files are usually in the system's Videos folder, written scripts might be in another temporary folder, and Xiaohongshu persona documents might be in yet another directory.

If the project scope is set too small, the Agent will get an error when trying to read files outside the project. My approach is to directly mount the user root directory as a large project on the left. This way, the Agent can always read any path we need, whether for tool calls or research.

Independent Context of Threads and File Persistence

When using the desktop client, each independent conversation on the left is called a thread. Codex officially calls it a thread.

You must remember this most basic rule: Each thread has its own completely independent context.

This means that the background information and conclusions you discussed with the Agent in the previous thread do not exist in its temporary memory when you create a new thread.

If you encounter very long continuous tasks, like brainstorming Xiaohongshu topics that take several days, or debugging a large script step by step, re-entering the lengthy background settings every time you open a new thread is not only tedious but also wastes a lot of Tokens.

In fact, many Agent products specifically designed for programming have long adopted this logic by default. It's just that general users, when facing AI, haven't yet gotten used to treating the Agent as a complete program with a local file system.

Since we know that a thread's temporary memory is cleared when it's closed, but the files in our local project directory are never lost, we can directly ask the Agent to write the core persona, topic direction, or research conclusions we discussed earlier as .md text files into our currently mounted project directory.

The next time we open a clean new thread and start a new round of conversation, we simply send a command in the input box: "Read the references/persona.md file in the current project directory to get my background, and then let's continue yesterday's topic."

By using local files as persistent memory in this way, each new thread is very clean and responds quickly, while also using the file system to save us Token costs.

Thread Pinning and Common Thread Sedimentation

When we start Codex in a project, as our conversations increase, the left panel will accumulate many temporary threads. If you have some core threads that need long-term maintenance or frequent back-and-forth conversations (like a dedicated thread for writing Xiaohongshu topics, or debugging a local API), letting them be buried in the list is very inconvenient.

Codex provides a small pin icon, the thread pinning function (Pin).

In the list, when you hover your mouse over an important thread, click the small pin icon on the right, and this thread will be fixed and settled into the Pinned dedicated area at the very top of the list. Pinned threads will not scroll down as new conversations are added. The interface entry point is as follows:

I habitually pin some high-frequency, highly reusable conversations that serve as daily backbone tasks to the very top. For example, I always have Update Grid Prompter prompts and $xhs-assistant pinned. This way, when I need to supplement my Xiaohongshu outline or fine-tune some common Prompter rules, I just click into these two pinned threads at the top, without needing to re-enter any background.

Common Core Settings in the Dialog Box

When you click into a specific thread, there are several very critical visual parameter adjustment buttons below the conversation input box. They directly determine the permission boundary, underlying model, reasoning intensity, and running speed of the current session.

1. Unthinkingly Choose Full Access Permission

In the bottom left of the dialog box, you'll see a permission control button (default is usually Default permissions or Auto-review). In daily use, I highly recommend directly switching it to Full access:

If you choose other restricted permissions, the Agent will pop up a window asking for your consent every time it reads a file or runs a command, which is annoying to use. Current models are already quite reliable in their operational logic, and cases of randomly modifying files are rare. Just turn on Full access.

2. Model, Reasoning Depth, and Speed Configuration

On the right side of the dialog box, directly click the model name button (e.g., GPT-5.5) to fine-tune the operating brain of the current thread:

• Reasoning: You can switch between reasoning depth levels like Low, Medium, High, and Extra High. The default recommendation is to directly choose the highest level, Extra High, which gives the model the strongest reasoning ability.
• Speed: Click the Speed button to enter speed mode switching. It is recommended to directly check the Fast mode. After enabling it, the model's token generation speed will increase by about 1.5 times.

Conversation Message Queue and Steer Mechanism

In addition to the core settings above, Codex also has a conversation queue management mechanism within a single thread that fits our daily habits very well.

When Codex is reading a file, debugging an error, or executing a time-consuming command, if you suddenly have a new idea, you can directly send the new conversation content to the chat box.

At this point, the newly sent conversation will not interrupt its ongoing modification action. Codex will default to storing the new message in a queue. Once the last tool call or modification of the previous task is completed, it will spontaneously start analyzing the backlog of new messages in the queue in the background and continue working step by step.

For example, I can first send an instruction for it to write core code; then, without waiting for it to finish, I can directly send a second request: "Also, help me write the test script for reviewing this code." It will queue them up and execute them itself.

However, if during its execution, you suddenly realize it has misunderstood the solution or its modification direction has gone off track, and you don't want to wait for it to finish the wrong work before queuing, you can click the steer button next to the newly sent message.

After clicking steer, Codex will directly intervene in the queue. After the current tool call is completed, it will immediately start reading your latest steered guidance message and spontaneously correct its subsequent course of action. This flexible queuing and on-the-fly steering mechanism is very suitable for fine-tuning and controlling its thinking during long tasks.

In the next section, we will go a step further and discuss how to use Codex's built-in tools to efficiently execute tasks within a project.

---

Built-in Tool Functions

Many people, when first using an Agent, often can't distinguish between the model and the tools.

A basic understanding needs to be established first: The model is responsible for thinking; the tools are responsible for executing.

The large language model itself is just a computational file running on a cloud server, capable only of text prediction and thinking. It has no eyes, no hands, and no ability to read your local computer files, run your terminal, or open a browser to go online.

The Agent's product mechanism provides a toolbox around this large language model. When the model, during its thinking, finds it needs to complete a specific task, it selects the corresponding local tool from this toolbox and indirectly controls our computer by calling the tool.

Understanding this concept of tools is very helpful for daily Agent use.

Because when the model executes a task, it doesn't know what's on our computer or what it can do. Every time it selects a tool, it decides based on the JSON Schema definition of the tool read at the system level.

This process is like writing an instruction manual for each tool in the system background. For example, for a tool named read_file used to read files, the instruction manual format defined for it in the background is typically like this:

{
  "name": "read_file",
  "description": "When you need to view the specific content of a file on the computer, please call this tool. You must provide a clear absolute path to the file.",
  "parameters": {
    "path": "The specific path of the local file you want to view, e.g.: /Users/me/desktop/text.txt"
  }
}

When you type a sentence in the chat box like: "Help me see what's written in outline.md on the desktop."

After receiving this sentence in the background, the large model will spontaneously compare all available tools. It sees that the description of the read_file tool above matches your instruction. So, in its returned response, the model won't directly reply with text; instead, it will generate a structured tool call data:

{
  "tool_to_call": "read_file",
  "arguments": {
    "path": "/Users/linzhihuang/desktop/outline.md"
  }
}

The local Agent program intercepts this JSON data generated by the model, then executes the real file reading code in the background on our computer, grabs the text content of the local file, and then throws it back to the large model as an observation result. Only after the large model reads the file content does it finally organize a plain-language reply for you.

Once we clearly understand how the large model selects tools by reading instruction manuals, we can use precise descriptions in our conversations to actively trigger them, avoiding situations where it hallucinates or refuses because it doesn't know it has this capability.

So, in daily practice, how should we talk to Codex to accurately trigger the various built-in tools behind it? In this section, let's systematically take stock of the various built-in tool capabilities currently supported by Codex.

External Web Search and Image Design Tools

This group of tools mainly helps the Agent break through the limitations of local files, access information from the outside world, and even directly handle multimedia assets:

• Web Search and Real-time Information: Codex can directly search the internet and supports opening any webpage and reading its specific content. It supports real-time fetching of weather, stocks, indices, or specified text. In daily use, we can directly say in the input box: "Help me check the latest policy," or "Open this link and look at the key points, check Apple's stock price today." It will fetch data by calling the browser and web search modules itself, without being limited to outdated data. Large models, without external reference materials, are prone to making things up.

Google's NotebookLM has an approach to solving the hallucination problem: it only allows the model to answer based on the documents you provide it, and every sentence points out which specific document and line it comes from. This way, the model basically doesn't make things up.

Codex's web search and file reading follow the same logic. When we ask it to write code for something unfamiliar or research a new topic in a conversation, I habitually include in my request a requirement for it to first search specific web pages or read specific local files.

When the large model has specific, up-to-date web pages and code as a basis for its answer, the conclusions it draws and the code it writes will have far fewer errors. Asking it to include links to reference web pages or paths to local files in its answer is much more reliable than letting it guess on its own.

• Image Search and Image Generation: This is a very unique feature of Codex. Other Agents often require us to manually configure external image generation models, but Codex comes with built-in image generation capability. It uses the currently most powerful GPT Image 2 image generation model. If we use an official ChatGPT subscription, we can use it directly in the software. Besides daily design work, image generation has another very important scenario: generating various design assets we need during Vibe Coding. For example, when developing a webpage, we can directly ask it to generate UI design drafts, or when making a game, directly ask it to generate various game art assets. If you need reference images, you can also directly say: "Find a few interior reference images of the Tesla Model Y." If you need design assets, you can directly say: "Generate a cover image for Xiaohongshu," and it will output the image directly in the conversation.

Local File Modification and Terminal Control Tools

This group of tools is the core capability for the Agent to help us with daily development and file management:

• File Modification and Local Terminal: This is the most frequently used underlying functionality. The Agent can directly read, write, and precisely modify our local files. As long as we authorize it, it can also directly execute commands in our computer's terminal (e.g., running compilations, executing unit tests, or checking Git status). You just need to briefly assign the task in the input box, like "Fix this bug" or "Run the tests," and it will analyze the logs and complete the modifications itself.
• Local Image Viewing: It natively supports multimodal visual recognition. We can directly provide a local image path, and it can analyze the image content. For example, when debugging a frontend style error, just take a screenshot and send it to it, saying "Look at this screenshot, where is the button position wrong?" It can then find the corresponding code and make adjustments itself.

Browser Automation Tools

• Browser Operations: Codex has a built-in headless browser. Also, if we install its Chrome browser extension, it can directly take over our default browser and automatically operate various websites we are already logged into (like GitHub, Xiaohongshu, Feishu, etc.). We can directly give it commands like: "Open the webpage and see if there are any issues with the page." It will automatically execute actions like taking screenshots, clicking, inputting, and analyzing page elements.

The installation of the Chrome browser extension and how to automate research will be mentioned later, so we won't expand on it here.

Task Planning, Goal Tracking, and Execution Tools

This group of tools ensures that the Agent can advance very logically when executing complex long tasks, without easily going off track:

• Task Planning and Goal Tracking: When facing a complex task, the Agent will maintain a progress checklist in the background. You can directly say: "First break down the steps for me, then continue running." It also supports the /goal command. For example, saying "Keep modifying this project until it can run" will make it spontaneously perform a loop of debugging in the background, record a clear big goal, and only mark it as complete when the condition is met.
• Workspace Dependency Location: Codex can automatically retrieve and locate various pre-installed Node, Python dependencies on your computer, as well as libraries for handling documents, spreadsheets, PDFs, PPTs, etc. For example, if you throw an Excel file at it and say "Help me process this spreadsheet," it will automatically load the corresponding Python processing code locally to execute the modification.
• Tool Discovery and Plugin Installation Suggestions: When we want to use a special capability, it can automatically check if there are available tools in the local environment (e.g., whether GitHub or Supabase is connected). If it finds a tool plugin is not enabled, it will also check in the background if it can be installed and suggest installation to us on the interface.
• User Input Requests: When encountering a key divergence point (e.g., two different modification plans), it won't act on its own. Instead, it will pop up a structured multiple-choice UI form on the desktop client interface, allowing us to make a choice by clicking directly on the interface.
• Parallel Execution and MCP Resource Reading: When analyzing large projects, it will automatically read multiple files in parallel in the background, or search multiple locations simultaneously to speed up analysis. Also, in scenarios with external connectors, it can directly read MCP resources, configurations, and context information provided by some connected services.
• Automation Tasks: Codex allows us to configure various scheduled automation tasks directly in the desktop interface. For example, setting a time rule like "Check project dependencies for me every Monday." It will then automatically wake up and execute in the background at the scheduled time.

Skill Trigger

In addition to the built-in tools above, Codex also supports extending capabilities through Skills. A Skill is an operation guide written by us or the community. During a conversation, Codex will automatically determine whether to use a certain Skill based on what we say.

There are two trigger methods: one is we actively call it with a slash command /skill-name; the other is Codex automatically matches it based on what we say. For example, if I have a UI design Skill installed, when I tell Codex "Help me design a page," it will automatically trigger this Skill and execute according to the workflow written inside.

We will discuss the complete mechanism of Skills and how to write them in detail in Chapter 8 later.

Common Term Explanations

For the convenience of readers without a programming background, I've organized a few common English terms that appear in this chapter into the most straightforward plain language below for easy reference.

• JSON: It's a specific text format for expressing data information. It uses the simplest curly braces and colons to list the attributes and specific content of information like bookkeeping. Because its format is very neat and concise, both humans and AI can read it without barriers.
• Schema: In layman's terms, it's a set of rule definitions. It's used to constrain what something should look like, what attributes it should contain, and what types those attributes must be.
• Metadata: It can be understood as data about data, i.e., auxiliary data used to describe other data. For example, the body of a book is data, while its title, author, publication date, and abstract are its Metadata. In an Agent, the name and brief functional description of a tool are the Metadata of that tool, and the large model uses this to quickly filter tools.
• Headless Browser: Refers to a browser without a visible software interface, running in the system background. Although it doesn't display any window on the screen, it can load web pages, click buttons, or perform webpage layout and screenshots just like a regular Chrome browser in the computer's memory.
• MCP Resources: Full name is Model Context Protocol connection data. It refers to data or configuration information saved in various external software services (like Feishu, GitHub, Supabase, etc.) that is safely shared with the Agent for reading through a universal bridge protocol (MCP).

---

Automation

The previous section mentioned Codex's built-in browser tools and Computer Use. In this section, let's expand on the topic of automation.

In Codex's settings, there is a page called Computer Use. Opening it shows three options:

Image missing: Computer Use settings page (local file not found: assets/image-6e9478a1-5a09-417f-b9bc-314ef8ea9a4b.png)

• Any App — Let Codex directly control any application on our computer
• Google Chrome — Control our Chrome browser via a browser extension
• Locked use — Let Codex continue operating even when the computer is locked

These three capabilities correspond to different levels of automation. Let me explain each one.

Computer Use is the Fallback Solution

Once Any App is installed, Codex can operate our computer desktop like a human. For example, asking it to open Feishu to send a message, or open some editing software to export a video — these are all possible.

But here's a very important understanding: Computer Use has the lowest priority among all automation methods.

Why? Because its working method is to take screenshots, use vision to identify interface elements, and then simulate mouse and keyboard clicks. The precision and speed of this process are not as good as dedicated tools.

For example, if we want Codex to open a webpage in the browser and fill out a form, using Computer Use, it would have to take a screenshot, find the browser icon's position, click to open, take another screenshot, find the address bar, click into it, type the URL... Every step requires a screenshot, recognition, and operation, which is very slow.

But if we use a dedicated browser tool, it directly operates the DOM nodes through code interfaces, getting it done in one step, quickly and accurately.

So my usual approach is: If a dedicated tool can handle it, don't use Computer Use. Only when there is no corresponding dedicated tool (e.g., operating some local desktop software) do I fall back to using it.

Chrome Plugin is the Core of Daily Automation

This is one of the most practical features Codex has added recently, in my opinion.

Before talking about the Chrome plugin, let me explain how cumbersome browser automation used to be.

In the past, if you wanted an Agent to control a browser, there were two mainstream methods:

One was Agent Browser. Its problem is that it opens a completely new browser instance. What does this mean? We usually log into platforms like Xiaohongshu, Bilibili, and GitHub in our own Chrome browser. But Agent Browser opens a clean new browser with no login state. We have to log in again in that new browser. And if we are also using these platforms in our own browser, they might log each other out.

The other was Browser MCP. Its configuration is quite troublesome; we need to manually install the MCP Server and then start the connection, which is a high barrier.

I previously wrote a tool called Local Browser Operator to solve this problem. Its idea was to reference Manus's My Browser, taking over our existing default browser through a browser extension. This way, all login states are ready-made, and no repeated logins are needed.

Later, Codex itself released this Chrome plugin, with the exact same principle as mine. And since it's official, its compatibility with Codex itself is definitely higher, so I switched directly.

How to Install

Search for "chrome" in Codex's Plugins and install this Chrome plugin. After installation, the first time you open it, it will guide you to install a corresponding browser extension in your Chrome browser. After installation, you'll see a Codex icon in the top right corner of Chrome, showing "Connected."

Going back to the Computer Use settings page, the Google Chrome section will show "Connected to browser extension" with the switch turned on.

What Problem Does It Solve

The core is just one sentence: Directly control our existing browser, reusing all our existing login states.

I usually need to publish videos to three or four platforms (Xiaohongshu, Bilibili, etc.), and I'm logged into all of them in my own Chrome. After using the Chrome plugin, Codex operates directly with my existing identity, without needing me to open another browser and log in again.

It's the same for research. I'm usually logged into YouTube, Reddit, GitHub, etc., and Codex can directly use my identity to access content that requires login.

How Does It Work

Its principle is the same as Manus's My Browser. It must use a browser extension to control our existing browser. The reason Agent Browser can't do this is that it doesn't have a browser extension, so it can only start a new browser instance.

During automated execution, it creates a new tab group in Chrome and then creates new tabs and performs operations within this group. This way, it doesn't disrupt the other tabs we are using.

How I Use It Daily

I mainly use it for these things:

• Frontend automated testing, asking it to open the local development page and click around to see if there are any issues
• Helping me with research, like asking it to search for a certain technical solution, open a few web pages to compare
• Multi-platform publishing for content creation; after I finish recording a video, I ask it to automatically distribute it to multiple platforms
• Scraping data that requires login to see

The trigger method is simple. When talking to it in the conversation, you can add a slash before the command to specify using the Chrome tool. For example, if I want it to research a topic, I first write the research requirements, then prepend the slash command, and it will open the browser and perform the operations itself.

Priority Between Them

Finally, let's summarize the selection logic for these three automation methods:

If the task is related to the browser (research, publishing, testing web pages), prioritize the Chrome plugin. It operates the browser DOM directly through code interfaces, which is fast and accurate.

If the task involves local desktop applications (editing software, Feishu client, Finder) and no other dedicated tool can cover it, then use Computer Use.

Locked Use is just an auxiliary switch that allows Computer Use to continue working when the screen is locked.

---

Plan Mode

Earlier, when discussing automation and Goal, we talked about letting Codex execute tasks directly. But sometimes, we don't want it to start acting immediately; we want it to think things through first before acting.

Plan Mode is for this purpose.

How to Enable

In the desktop client, in the plus menu at the bottom left of the input box, there is a Plan mode toggle:

After turning it on, the next message we send will not cause Codex to start writing code or executing operations directly. Instead, it will first collect context, analyze the situation, and then present us with an execution plan. If there are unclear points, it will ask us clarifying questions first.

Once we confirm the plan is okay, it will start executing.

When to Use Plan Mode

I generally use Plan Mode in these situations:

When the task is complex. For example, a refactoring involving multiple files, or adding a new feature that spans several modules. If I let it act directly, it might go in the wrong direction halfway through, having already modified a bunch of files. With Plan Mode, it first lists the overall plan, I check if there are any issues, and then confirm before execution.

When I haven't figured it out myself. Sometimes I only have a vague idea and am unsure about the specific implementation. In this case, I turn on Plan Mode, describe the idea, and let Codex help me sort out the specific implementation steps. It's like using it as a technical consultant first, and then switching it to executor after confirming the plan.

When unsure about the impact on existing code. For example, I want to modify a certain feature but am unsure if it will affect other parts. In Plan Mode, it will first look at the relevant code, analyze the impact, tell me which files and modules might be affected, and then ask me if I want to proceed.

Difference from Direct Conversation

Without Plan Mode, when we say "Help me add a user registration feature," Codex directly starts creating files and writing code.

With Plan Mode enabled, sending the same message will first produce a plan: how it intends to implement it, how many steps, what each step does, and what needs to be confirmed. After we read it and click confirm, it starts acting.

This difference is not noticeable for small tasks, but it's significant for large tasks. If the direction is wrong from the start for a large task, the cost of correcting it halfway is very high. Plan Mode allows us to spot problems before execution begins.

Pairing with PLANS.md for Long Tasks

If the task is particularly large (e.g., one that takes several hours), the official recommendation is to place a PLANS.md file in the project. This file breaks the entire task into multiple milestones, each with clear acceptance criteria.

The general structure is:

• What is the goal of each milestone
• How to verify the milestone is complete (e.g., run what command, look at what output)
• If verification fails, fix it first before moving on
• What decisions were made and why

Codex will follow this file step by step during execution, verifying each milestone before moving to the next. This way, even if the task runs for a long time, it won't go off track because there are clear checkpoints.

The official team mentioned someone used this method to have Codex work continuously for over seven hours from a single message to complete a full feature.

Pairing with Goal Mode

Plan Mode and the Goal Mode to be discussed in the next section can be used together.

My approach is: first turn on Plan Mode to have Codex produce a complete execution plan. After I confirm the plan is fine, I use Goal Mode to have it execute according to the plan continuously until completion.

The benefit is: Plan ensures the direction won't be wrong, and Goal ensures it will keep working until the standard is met. The combination is "think it through first, then finish it all at once."

Limitations of Plan Mode

After using it, I've found a few issues to be aware of with Plan Mode:

Plan modifications are full rewrites. If we ask Codex to produce a plan and then want to change one step, it might regenerate the entire plan, potentially altering or shortening other steps that were already written. It currently doesn't support incremental editing that only modifies a part while keeping the rest unchanged. So if you want to fine-tune a plan, you may need to repeatedly check if it has changed things that were previously decided.

Sometimes it produces a plan without going deep enough. The ideal state of Plan Mode is: first look at the code, understand the existing architecture, discover constraints, and then produce a plan. But in practice, it sometimes looks at a few files and starts producing a plan, potentially missing some existing interfaces or tests. This problem is more noticeable in large codebases. If you find its plan has overlooked something, you can directly tell it "Take another look at the XXX file."

Plan Mode's constraints are at the prompt level, not physical isolation. That is, in Plan Mode, Codex theoretically "shouldn't" modify files, but this restriction is enforced by telling it not to via a prompt, not by a sandbox. In extreme cases, it might still modify files. So if the task is high-risk, it's recommended to create a git branch or stash your current changes before enabling Plan Mode.

Plans are not automatically saved to a local file. This is the biggest issue I see currently. The plan generated by Plan Mode only exists in the current conversation's context. It doesn't automatically write a Markdown file locally. What does this mean? If the conversation has many rounds and triggers context compression, the plan's details might be compressed away. Or if we open a new thread to execute a previous plan, that plan is no longer there.

My own solution is: after Plan Mode produces a plan, I manually ask Codex to write the plan to a local file (e.g., PLAN.md). Then I turn off Plan Mode and ask it to execute, referencing this file during execution. This way, even if the context is compressed, the plan remains intact in the file.

Claude Code handles this a bit better; it automatically saves plans to the ~/.claude/plans/ directory. Many in the Codex community are also requesting this feature, but it hasn't been implemented yet.

Compatibility with Goal Mode is still being improved. Some users have reported that when both Plan and Goal are enabled simultaneously, Codex might skip planning and execute directly. The official team says the interaction between these two features is still being optimized. My own approach is to use Plan first to produce a plan, confirm it, then turn off Plan Mode, and then enable Goal to execute. Don't have both enabled at the same time.

My Own Feelings

I don't use Plan Mode for simple tasks because it adds an extra round of confirmation. Small tasks can be done directly. But if the task involves a large scope, or I haven't figured out the specifics myself, I turn it on.

Another use case: if you're unsure whether your requirement description is clear enough, you can turn on Plan Mode and let Codex produce a plan first. See if its understanding matches what you intended. If not, it means your description is ambiguous, and you can correct it at this stage, rather than discovering the problem after it has already done the work.

---

Goal Setting (/goal command)

Normally, we send Codex a message, it executes it, and then stops to wait for our next instruction. But if we have a large task, like building a complete project from scratch, doing a framework migration, or tracking down a recurring bug, we actually want it to keep working until it's done, without us having to watch it constantly.

The /goal command is for this purpose. It was added after Codex version 0.128.0.

How to Enable

In the desktop client, click the plus button at the bottom left of the input box. A menu pops up with a "Pursue goal" toggle:

After turning this toggle on, the next message we send will be treated as a Goal to execute. Codex will keep pushing towards this goal until it's completed or encounters a blockage.

If the toggle doesn't appear, you might need to enable this feature in the configuration file first. Add goals = true to the features section in config.toml.

Difference from Normal Conversation

Let me explain in the simplest way.

The flow of a normal conversation is: I send a message → Codex does it → gives me the result → stops and waits for my next message.

The flow of a Goal is: Codex completes one step → checks if the goal is achieved → if not, continues to the next step → checks again → until the goal is reached, or I pause it, or the Token budget runs out.

The difference is that in a normal conversation, Codex stops after completing one step, even if the task isn't finished; it thinks "I've done my part for this round." But in Goal mode, at the end of each round, it goes back to check if the goal condition is met. If not, it automatically continues.

This isn't done with prompts; it's a program-level mechanism that continuously checks. Even if the context is compressed midway, the goal information isn't lost; it always knows it hasn't finished yet.

Goal Execution Status

During execution, a Goal can have several states:

• Executing — It's still working towards the goal
• Paused — Manually stopped by us, e.g., we want to correct the direction
• Completed — Goal achieved, it marks itself as done
• Budget reached — Token usage hit the limit, gracefully winding down
• Blocked — Encountered a problem it can't solve itself, waiting for us to handle

One thing I think is well-designed: when the Token budget is about to run out, it doesn't suddenly stop. Instead, it enters a winding-down state. It summarizes what has been done, what remains, and where to continue next. We can then continue this goal in a new session.

How to Write a Good Goal

This is the most critical part. From my experience, the more detailed the Goal, the better the long-term execution. If it's too vague, it might think it's done after just two or three steps.

The official documentation summarizes several elements needed for writing a Goal. Let me translate them into plain language:

1. Target Result — Tell it what needs to be achieved in the end.

2. Verification Method — How it knows it's done. For example, all tests pass, benchmark targets are met, screenshot comparisons are consistent.

3. Things Not to Touch — What is not allowed to be modified while working towards the goal. For example, don't modify the database structure, don't change public API interfaces.

4. Allowed Scope — Which files it can modify and which tools it can use.

5. Decision-Making Between Rounds — Tell it how to decide what to try next after completing one step.

6. When to Stop — If it encounters a blockage it can't solve itself, it should stop and tell us where it's stuck, rather than trying blindly.

Let me give an example for comparison.

Weak Goal:

/goal optimize performance

This is as good as not writing anything. It doesn't know what level of optimization counts as done, what metric to use, or what it can't touch.

Strong Goal:

/goal Reduce the p95 latency of the checkout interface to below 120ms. Use the checkout benchmark for verification, while keeping all correctness tests passing. Only allow modification of code and tests related to the checkout service. After each attempt, record what was changed, what the benchmark result was, and what to try next. If the benchmark can't run or no effective optimization path is found, stop and tell me where you're stuck.

This is very clear. Codex knows the target (p95 < 120ms), how to verify (run benchmark), what not to break (correctness tests), what scope it can touch (checkout service), how to record progress each round, and when to stop.

If you're unsure how to write it yourself, you can also roughly describe the requirements and ask Codex to draft the Goal for you. For example, say: "Help me organize this requirement into a /goal format, with clear evaluation criteria and stopping conditions." It will turn your vague description into a structured Goal.

Scenarios Suitable for Goal

Based on my own use and official recommendations, these scenarios work best with Goal:

• Code Migration — Migrate from an old framework to a new one, with the goal of pixel-perfect UI, verified by Playwright screenshot comparisons
• Building a Project from Scratch — First write a plan.md, then have it implement step by step according to the plan, creating tests for each phase
• Performance Tuning — Set a specific metric target (e.g., response time below 150ms) and let it keep trying until it's met
• Complex Bug Tracking — Let it keep investigating until the root cause is identified or the bug can be reliably reproduced
• Prompt Optimization — If you have a set of eval tests, let it continuously adjust the prompt, run evals, check scores, and optimize until the score is met
• Large Refactoring — Set the goal as all tests passing + code conforming to new standards

When Not to Use Goal

Not all tasks are suitable for Goal. For these situations, just use normal conversation:

• Changing one line of code
• Asking a question
• Small bug fix
• Simple Code Review
• Anything that can be done in a few minutes

Goal is suitable for tasks that "take an hour or two or more to complete." If the task itself can be done in three to five steps, using Goal is overkill.

My Own Usage

When I use /goal, I usually pair it with the caffeinate command. Because Goal tasks often take a long time, and I might not be at the computer or might assign the task before going to sleep.

caffeinate -dimsu

This way, even if the MacBook lid is closed, it won't sleep, and Codex will keep running in the background. As long as the network is stable, I can see the results when I wake up the next day.

Also, if the goal's status becomes vague during execution (e.g., its progress reports become increasingly general), don't add more one-shot instructions. Instead, directly tighten the goal itself. Tell it what the most important next step is, what command to use for verification, and when to pause. Making the goal more specific is much more effective than adding more conversation content.

---

Sidebar Function (/side command)

Earlier, when discussing context, we mentioned that the longer the context and the more irrelevant information it contains, the worse the Agent's execution quality. During our daily conversations, we often encounter a scenario: Codex is helping me with a task, and halfway through, I suddenly want to ask it a question that's not very related to the current task.

For example, it's writing a feature for me, and I suddenly want to ask "What does a certain API parameter of this library mean?" If I ask this directly in the main conversation, this Q&A will be written into the context. When it continues the task later, the context will contain a piece of information unrelated to the task. As conversations accumulate, the context gets polluted by these miscellaneous questions.

/side is designed to solve this problem.

How to Use

Type /side in the input box and send it. It will open a new conversation window on the right side:

This right-side conversation has two characteristics:

First, it can see all the context information from the main conversation on the left before this point. That is, it knows what we were doing, where the code is at, and the current project status.

Second, what we say on the right side will not be written into the left side's context. The right side is an independent branch; after chatting, it doesn't affect the cleanliness of the main conversation.

Similar Feature in Claude Code

If you use Claude Code, there's a similar command called /btw. The functionality is similar: temporarily insert an unrelated question during the main conversation. Claude Code handles this question separately, preventing it from affecting the context direction of the main task.

The difference is that Codex's /side opens a complete independent conversation window on the right, which is visually clearer; Claude Code's /btw is still in the same terminal, just logically isolated.

When to Use

My daily use cases for /side mainly include:

Asking temporary questions — Mid-task, I want to quickly confirm an API usage, the meaning of a concept, or ask if the current plan has obvious risks. After asking, I return to the main conversation to continue the task without polluting the main context.

Comparing plans — For example, Codex wrote a report for me on the left, and I want to quickly ask on the right "Is there a problem with the third conclusion in this report?" I just look at the result myself; the main conversation doesn't need to know.

Parallel execution — This is an advanced usage. If Codex has already explored enough code on the left and has a rich context, we can use /side to execute another part of the task on the right simultaneously. One thing on the left, another on the right, running in parallel.

The Right Side Model is Independently Selectable

An easily overlooked point: the model for the right sidebar can be different from the left. For example, while the main task on the left is running with GPT-5.5, I can switch to a cheaper model for a small question on the right. This doesn't waste quota and doesn't affect the execution quality of the main task.

Specific Usage of Parallel Execution

This is an advanced use of /side. If Codex has already explored a lot of code on the left and has a rich context, we can use /side to execute another task on the right simultaneously.

For example, a real scenario: the left side is helping me refactor the code of a certain module, and I suddenly remember that the corresponding test file for this module also needs updating. I don't want to interrupt the refactoring flow on the left, so I open a /side on the right and say, "By the way, help me update the tests for this module." Because the right side inherits the context from the left, it knows what code I changed and can directly update the tests accordingly.

The changes on both sides don't interfere with each other. What's changed on the left is on the left; what's changed on the right is on the right.

Its Limitations

/side has a few things to be aware of:

• It's temporary. I haven't found an exact number for how long it lasts, but if you don't use it for a few hours, you might not be able to send messages anymore. So don't expect to maintain it as a long-term thread.
• It doesn't create a new thread on the left. Once the sidebar is closed, the content discussed inside doesn't stay anywhere. If important conclusions were reached on the right, remember to ask it to write them to a file.
• You cannot open another /side within a /side; it's only one level deep.
• The right-side conversation is more suitable for lightweight operations. If the task on the right is also heavy (e.g., needs to read many files, run many commands), it might compete for resources with the left side, slowing both down.

So /side is best suited for quick, short, temporary conversations: ask a question, confirm a direction, make a comparison, update a small file on the side, and then return to the main line.

---

Rewind Conversation Rewind

In the previous section about /side, we solved the problem of temporary questions not polluting the main line. This section's rewind solves another scenario: the main line has already been polluted, and we want to go back to a previous clean node.

Earlier, when discussing context, we mentioned that the longer the conversation and the more irrelevant information it contains, the worse the Agent's execution quality. In daily use, this often happens: a thread has been going on for a while, with a bunch of off-track attempts, wrong questions, and dead-end plans mixed in. All this stuff is piled up in the context. When we ask it to do something later, its attention is distracted by this noise.

Rewind takes the conversation back to a previous message, discarding all Q&A after that point, essentially forking a new conversation from that point.

How to Operate

In the desktop client, move your mouse over a previous message in the history. An entry point to "go back to this step" will appear. Clicking it discards all content after this message, returning the conversation to the state at that point in time. (If you're using the command line, pressing Esc twice in a row does the same thing.)

After going back, we can send a new message on that clean basis and continue the subsequent task.

The Most Important Point: It Only Rewinds the Conversation, Not the Code

This must be remembered, otherwise it's easy to step into a pit.

Rewind deletes the context, not the file changes. You rewind the conversation to three rounds ago, but the files modified by the Agent during those three rounds remain in their modified state; they don't revert with the conversation.

This creates a mismatch: the conversation has been rewound and has no memory of the file changes, but the files on disk are already in their new state. When the Agent continues from there, it thinks the files are old, but they are actually new, making its judgments prone to errors.

So, when code changes are involved, my habit is to do a git commit before rewinding. This way, if the conversation and file states become misaligned, I can use git to revert the code as well, aligning both sides. Alternatively, after rewinding, first ask it to re-read the current files to replenish the actual state on disk back into the context before continuing.

To revert the code as well, git is still the most stable method. Codex previously had an /undo command that would revert code along with the conversation, but it was removed by the official team due to many issues. The current rewind only handles the conversation layer.

Difference from New Thread, /side, and Compression

These concepts are easy to confuse. Let me distinguish them in one sentence:

• New Thread — Start completely from scratch; it knows nothing about previous conversations. Suitable when the next task is completely unrelated to the previous one.
• Rewind — Keep the useful earlier part, only cut off the later off-track or irrelevant part. Suitable when you still want to use the earlier context but the later part is messy.
• /side — Don't touch the main line; temporarily open a sidebar to ask a question and come back. Suitable when the main line is fine, just want to insert a small unrelated question.
• Compression — The system automatically condenses the earlier part into a summary when the context is nearly full. It's passively triggered and irreversible.

The key difference is between rewind and new thread. If you spent a lot of time having the Agent explore code and build an understanding of the project, that part of the context is valuable. Starting a new thread directly throws away all that exploration, and the next task will have to explore everything again. With rewind, you can go back to the point just after the exploration was done, before it went off track, cutting off the useless later part while keeping the previous understanding for continued use.

When I Use It

Mainly in these situations:

It misunderstood the direction and is getting more off track. Instead of continuing to correct it sentence by sentence on the wrong basis, it's cleaner to directly rewind to the message before it went off track, re-clarify the requirements, and send it again. This avoids leaving a bunch of erroneous attempts in the context.

In a long conversation, the earlier context is still useful, but I did some things in between that are irrelevant to the next step. I rewind the later irrelevant part and continue the next task on the basis of retaining the useful earlier information.

I asked a series of exploratory questions that made the context messy. After getting the answers, I rewind to before the questions were asked, keeping the main line clean.

Reminder Before Using

The rewound content is irretrievable. After forking, the discarded branch is gone. So if the later part of the conversation contained important conclusions (e.g., an analysis of a problem's cause, a decided plan), ask it to write them to a local file before rewinding.

Also, regarding the code state issue mentioned earlier, when file changes are involved, develop the habit of committing to git before rewinding.

Incidentally, Claude Code's /rewind is more complete, allowing you to choose to rewind only the conversation, only the code, or both, backed by a checkpoint mechanism. Codex currently only has conversation-level rewind; we have to manage code reversion with git ourselves.

---

Memory Function

Earlier, when discussing context, we mentioned that context is independent between threads. That is, things I told Codex in thread A are completely unknown when I open a new thread B.

But what if there is some information we want it to remember across threads? For example, my usual tech stack, some conventions of my project, or a recurring preference setting.

Codex's memory function is for this purpose.

Where to Enable

In the Settings, under Personalization, there is a section called Memory (experimental):

There are several toggles here:

• Enable memories — When enabled, Codex will automatically extract useful information from our conversations, generate memory files, and automatically include them in new conversations later.
• Chronicle research preview — This goes further, enhancing memory by combining content from our screen. For example, if we are looking at a certain document or writing a certain piece of code, it incorporates this context into the memory.
• Skip tool-assisted chats — If enabled, conversations that used MCP tools or web search won't be used to generate memories.
• Reset memories — One-click clear all memories.

How It Works

The mechanism of the memory function is roughly like this:

After a conversation has been idle for a sufficiently long time (currently over 12 hours), Codex will asynchronously analyze the conversation's content in the background, extract information it deems valuable, and generate memory files stored in our local ~/.codex/memories/ directory.

The generated memories are in Markdown file format. Later, when we start a new thread, Codex automatically injects the content of these memory files into the context, so it "remembers" some information from previous conversations.

This process has several characteristics:

• Not real-time; it doesn't generate memories immediately after each conversation ends, but waits until the conversation has been idle long enough
• Automatically filters sensitive information (API Keys, etc., won't be written into memories)
• If the current API usage is nearing its limit, memory generation will also be skipped, not competing for quota
• Memory files are periodically merged and organized, not infinitely expanding

Why I Don't Use This Feature Much

To be honest, I keep the memory function turned off.

The reason is the same as what I said in a previous video: currently, for any Agent's automatic memory function, most of what it writes is useless.

For example, in a certain project, I said "use a light blue color scheme," and it might write this into memory, becoming "user prefers light blue." But this was just a requirement for that one project, not my personal preference. Over time, the memory accumulates a bunch of this kind of out-of-context information, which instead interferes with the quality of subsequent conversations.

If you've used the Knowledge function in Manus, you know that most of the recommended content is also not very useful.

My Own Alternative

Compared to letting AI remember automatically, I find manual management using files to be more reliable.

My approach is: if there is some information I want to share across threads (like my persona information, project conventions, writing style guidelines), I write it as a Markdown file and place it in the project directory. The next time I open a new thread, I directly @ that file for it to read, and it immediately knows.

The benefits of this approach are:

• I clearly know what it "remembers" because I wrote it myself
• There won't be any inexplicable erroneous memories polluting the context
• Can be modified and updated at any time
• Different projects can have different memory files without mixing

The code repository itself is actually a natural memory. When Codex enters a project directory, it reads the code and knows what the project does, what conventions it has, and what tech stack it uses. This information is more accurate than any automatic memory.

Who Should Enable Memory

If your usage scenario is relatively fixed, like you are always using Codex for the same type of thing (e.g., writing code for the same project every day), and you don't want to repeat background information every time, enabling the memory function can save some repetitive explanation time.

But if you are like me and use Codex for a variety of things (writing code, doing research, writing articles, publishing videos), I recommend turning it off and managing it yourself with files for peace of mind.

---

Image Generation and UI Design

Earlier, in the pet features section, we saw Codex's image generation capability. In this section, let's talk about its more practical scenarios in daily development: using Codex for UI design, and how to restore design drafts into code.

Codex's Built-in Image Generation Capability

Codex has a built-in GPT Image 2 image generation model. As long as we subscribe to ChatGPT Pro, we can directly ask it to generate images in the conversation without additional configuration.

Using this capability within Codex is a completely different experience from using it on the ChatGPT web page. Because Codex can read and write files, run code, and preview web pages, it can string together image generation and programming.

Using AI Image Generation for UI Design

I previously tested the effect of GPT Image 2 for UI design, and the conclusion is: The UI design drafts it produces are highly implementable, and the aesthetics are much better than directly asking AI to write HTML code.

Why is this? Because if we directly ask AI to write frontend code, its aesthetic ceiling is limited to the code styles it has seen in its training data. But if we first ask it to generate a design image, it has seen too many excellent designs in the image generation dimension, and the visual output will be much more refined.

So my current workflow for creating a new page has become: first use image generation to create a design draft, and after confirming satisfaction, ask it to restore it into code.

How to Maintain Design Consistency

There is a core problem with creating design drafts: I already have a system with its own sidebar, color scheme, and icon style. How do I ensure that every time AI generates a new page, it is consistent with the existing system?

I tried two methods:

Method 1: Constrain with Prompts

I wrote a unified prompt describing what the sidebar looks like and what color scheme to use. The result was not good. Generating twice with the same prompt produced different interfaces. Constraining through prompts didn't work.

Method 2: Provide a Reference Image

This method works very well. I take a screenshot of an existing page in the system and pass it as a reference image. Then I tell it: "Keep the sidebar exactly the same as the reference image, and help me design a new XXX page."

The result was that the left sidebar remained completely unchanged, with the same colors, icons, and buttons as the reference image. Only the content area on the right was redesigned. I generated it five times in a row, and the left sidebar was stable each time.

However, there is a trade-off: if the reference image contains too many existing design elements, it can limit its creativity. It tends to produce designs that are "similar to the reference image" and is less daring to make big changes.

My later approach was: In the reference image, only keep the parts that need to be fixed (like the sidebar), and clear the content area on the right. This way, it knows the sidebar can't be moved, but the right side can be freely designed. The resulting designs were much better — tight layout, comfortable colors, diverse styles.

How to Write Image Generation Prompts

I tested five different angles for writing prompts, and the results varied greatly:

1. Narrative Perspective — Write the user's journey into the prompt. For example, "After the user opens this page, they first see an overview of data, then scroll down to see a detailed list." This approach tends to produce designs with reasonable information hierarchy.

2. Information List — Directly tell it what data needs to be displayed on the page, but don't specify the layout. For example, "Need to display original video, view count, engagement data, tags," and let it figure out the layout itself.

3. Analogy Reference — Tell it "Make it in Notion style" or "Reference Linear's design," and it will design according to that product's visual language.

4. User Goal — Tell it "What conclusion should the user draw after viewing this page," and let it decide what information to display and how to organize it.

5. Emotional Description — Describe the overall feeling the page should give. This direction had the worst effect, easily producing poster or promotional page styles, not functional pages.

The first four methods all worked well. And you don't need to write these prompts yourself; the AI will analyze the direction of the page you want to create and choose the appropriate angle to generate the prompt itself.

I packaged these strategies into a Skill called draw-ui. Installation method:

npx skills add oil-oil/draw-ui

After installation, whenever we tell Codex "Help me design a XXX page," it will automatically do these things: look at the design resources in the code repository, ask us to provide a reference image, choose the appropriate prompt strategy, and generate a design draft. If code restoration is needed, it will also automatically handle asset separation and skeleton building.

How to Restore Design Drafts into Code

After the design draft is generated, the next step is to turn it into real code. This is also a concern for many people.

The principle of AI restoring design drafts is not mysterious: it uses multimodal visual recognition to look at the layout, colors, and element sizes in the image, and then converts them into HTML/CSS code. Most elements can be replicated 1:1, but there are some things it can't do:

• Logos (these are brand identifiers, can't be drawn with code)
• Complex illustrations (like decorative images in the Hero area)
• Third-party vendor icons (like partner logo walls)
• Subtle texture effects
• Complex SVG curves

These things are essentially visual assets, not things that can be generated with code.

My Restoration Workflow

To address this issue, I optimized my Skill. The entire restoration workflow is as follows:

Step 1: Get the original design draft and record the canvas size.

Step 2: Have the AI analyze the image and identify which elements can be implemented with code and which cannot. For example, brand symbols, illustrations, and texture decorations are classified as "assets"; layout, text, buttons, and tables are classified as "code-implementable."

Step 3: First build the parts that code can handle. Use HTML/CSS to restore the overall skeleton, leaving placeholders where code can't implement.

Step 4: Handle the assets that code can't create. This is the key — I ask the AI to use local cropping to cut out these asset elements (Logo, illustrations, icons) from the original design draft and save them as separate image files.

Step 5: Embed the cropped asset images into the corresponding positions in the HTML. This way, the Logo is a real cropped image, the illustrations are real images, rather than asking the AI to hard-draw them with code.

The final restoration accuracy can reach about 90%. The general layout, colors, and element positions are consistent. The Logo and illustrations, being directly cropped from the design draft, are identical to the original. The remaining 10% can be fine-tuned manually by adjusting the code.

Overall Workflow Summary

My complete workflow for creating a new page now is:

1. Tell Codex what page I want to create, providing a screenshot of an existing system page as a reference
2. Codex uses GPT Image 2 to generate design drafts, possibly offering several options for me to choose from
3. After I select one, it starts restoring it into code
4. During restoration, it automatically separates assets, builds the skeleton, and embeds images
5. Preview the effect in the built-in browser; if something is wrong, mark it directly in the browser for it to fix

The whole process takes about ten minutes to half an hour, depending on the page complexity. For engineers who don't use Figma, this workflow is much more convenient than before.

Limitations

• Text rendering is sometimes inaccurate, especially Chinese characters may appear garbled
• Complex interactive animations cannot be achieved; only static visuals can be restored
• Each image generation consumes quota; extensive iteration can be expensive
• The quality of the restored code depends on the model's capability; sometimes the CSS is not elegant and needs subsequent cleanup
• If our system itself is very plain, the reference image provides too little information, limiting its design creativity

---

Practical Configuration

The previous sections talked about various features of Codex. This section is about some practical configuration items for daily use. Most of these configurations can be changed directly in the desktop client's Settings, without manually editing files.

Preventing Computer Sleep

This was mentioned in the Goal command section, but it's so commonly used that I'll mention it separately here.

In Settings > General, there is a "Prevent sleep while running" toggle:

When turned on, as long as Codex has a task running, the computer won't go to sleep.

This is especially important for long tasks. If you set a Goal for Codex to run for several hours, but the computer goes to sleep after ten minutes, the task will be interrupted. Turning on this switch eliminates that worry.

If you are using a remote connection (e.g., remotely controlling another Mac), there is also a "Keep this Mac awake" option in the Settings > Connections of the controlled computer, serving the same purpose.

Detail Display Level

In Settings > General, there is a "Detail level" option.

The default is Coding mode, which shows the specific commands Codex is executing, what files it's reading, and what scripts it's running. For engineers, this information is useful to see what it's doing.

But if you're not a programmer, or you're just using Codex for daily tasks (research, writing documents, organizing files), seeing a bunch of code output can be confusing. In this case, switching to Default mode makes the interface much cleaner, showing only the final results without the intermediate code details.

Personalization Settings

In Settings > Personalization, you can set two things:

Reply style — There are Friendly and Pragmatic options. I choose Friendly myself, because Codex's default speech is indeed a bit impersonal; choosing friendly makes its replies slightly warmer.

Custom instructions — Here you can write a piece of text telling Codex what rules to follow when replying to you. For example, I write that its replies must be colloquial and concise, natural and clear, and avoid any translationese sentence structures.

This custom instruction takes effect in every conversation, so you don't need to repeat it each time. It's like a global behavior constraint.

MCP Service Configuration

MCP stands for Model Context Protocol, a protocol that allows Codex to connect to external tools and services.

In Settings > MCP servers, you can configure:

For example, I have configured Supabase (database), LangSmith (debugging), MongoDB, etc. After configuration, Codex can directly read and operate data from these external services without us needing to manually copy and paste.

Some MCP services are automatically included with Plugins. For example, installing the GitHub Plugin automatically configures the related GitHub MCP connection.

The MCP configuration is ultimately written in the [mcp_servers] section of config.toml. If we configure it in the desktop UI, it will automatically write it for us, so manual editing is not needed.

Hook Mechanism

Hook is an advanced feature of Codex that allows us to automatically execute some scripts when specific events occur.

For example:

• Every time Codex starts a new session, automatically run a script
• Every time Codex is about to execute a certain command, first perform a check
• After the context is compressed, automatically record some information
• When a sub-agent starts, inject some additional instructions

Hook configuration can be written in config.toml or in a .codex/hooks.json file in the project directory. Codex will ask us to confirm and trust before executing a Hook. After adding or modifying a Hook, it needs to be re-trusted to run.

For most people, Hook is not a necessary configuration. But if you have some fixed workflows you want to automate (like automatically loading a certain file every time you open a new thread, or automatically running tests after each task execution), Hook is very useful.

Work Mode

In Settings > General, there is a "Work mode" option:

You can choose "For coding" or "For everyday work."

If you choose everyday work mode, Codex will hide most code-related output during task execution, presenting information in a cleaner and more understandable way. Suitable for those who don't write code but want to use Codex for daily tasks.

Configuration File Hierarchy

Codex's configuration has a priority concept. From high to low:

1. Command-line arguments (temporary override)
2. Profile configuration (scenario presets)
3. Project directory's .codex/config.toml (project level)
4. User directory's ~/.codex/config.toml (global default)
5. System configuration (if any)
6. Built-in defaults

For most people, only the 4th one needs attention: the user-level global configuration. Things changed in the desktop Settings are mostly written here.

If a specific project has special requirements (e.g., a different model or different permissions), you can place a .codex/config.toml in the project directory to override the global configuration. However, note that project-level configurations only take effect after we mark the project as "trusted."

Automation (Automated Tasks)

In the Automations section on the left side of the desktop, we can configure scheduled tasks:

For example, setting "Every morning at 10 AM, research trending topics on Xiaohongshu" or "Every Monday, check if project dependencies have updates."

Pay attention to a few points when creating:

• On the right, you can select the execution model. It is not the model we use for normal conversations by default. If you don't pay attention, you might use a less powerful model to run the task, resulting in poor performance.
• You can choose where to run: if it's a code repository, you can use Worktree; if it's just a regular directory, choose Local.
• There is a "Use template" button in the top right corner. The official team provides some templates like Bug investigation, Git information summary, writing daily reports, etc.

I don't use Automation much myself because I use Codex every day and execute most tasks manually. But for tasks with a fixed frequency, like daily reports, this feature is quite convenient.

---

Sub-Agent Function

Earlier, when discussing context engineering, we mentioned an optimization idea: use sub-agents to isolate context, letting sub-agents do the dirty work of reading large numbers of files, and only returning key results to the main Agent. In this section, let's talk about Codex's sub-agent function in detail.

What is a Sub-Agent

A sub-agent is an independent, smaller Agent that Codex can spawn during task execution. It has its own independent context, and after completing its task, it returns the results to the main Agent.

For example: I ask Codex to do a code review. If it does it alone, it needs to read all the files into its own context, which fills up quickly. But if it uses sub-agents, it can spawn three sub-agents simultaneously: one specifically for security risks, one for test coverage, and one for code maintainability. Each sub-agent reads the files it needs, and finally returns its conclusions. The main Agent just summarizes them.

Codex Does Not Automatically Dispatch Sub-Agents

This is important to note: Codex will not actively dispatch sub-agents on its own. It only does so if we explicitly state it in the conversation.

For example, we can say:

• "Use three sub-agents to review this code in parallel"
• "Dispatch two Agents, one to look at the frontend code, one to look at the backend code"
• "Explore the modules of this project in parallel"

Cost of Sub-Agents

Sub-agents consume more Tokens. Because each sub-agent is an independent model call, with its own system instructions, tool calls, and context. Three sub-agents running in parallel consume roughly three times the Tokens of a single run.

So not all tasks are suitable for sub-agents. Simple tasks can be done directly. Only when the task itself can be split into several independent parts that can be done in parallel does using sub-agents make sense.

Custom Sub-Agents

Codex supports pre-defining sub-agents with different roles. For example, one specifically for code exploration, one for Code Review, one for looking up documentation.

The definition is done by placing a TOML file in the project or user directory:

• Project level: .codex/agents/xxx.toml
• User level: ~/.codex/agents/xxx.toml

A sub-agent for Review could be defined like this:

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
Lead with concrete findings and include file references.
"""

Key fields here:

• name — The name, used by Codex when dispatching
• description — When this Agent should be used
• model — You can specify a different model for the sub-agent (e.g., using the cheaper gpt-5.4-mini for exploration)
• model_reasoning_effort — Reasoning depth; for exploration tasks, low or medium is sufficient
• sandbox_mode — Permission control, e.g., read-only mode to prevent the sub-agent from randomly modifying files
• developer_instructions — Its behavior guidelines

However, you don't actually need to write this TOML file manually. Just tell Codex "Help me create a read-only code review sub-agent, using gpt-5.4-mini, focusing on security and tests," and it will write this file itself and place it in the appropriate directory. Most configuration operations can be done by Codex itself, without us needing to manually edit configuration files.

Model Selection for Sub-Agents

Not every sub-agent needs the same high reasoning effort as the main Agent. My approach is: the sub-agent also uses gpt-5.5, but with lower reasoning effort (model_reasoning_effort set to low).

The benefit of this is that the model's capability itself is not compromised; it's just that the thinking depth is shallower, making it much faster. For tasks like exploring code or scanning files that don't require deep reasoning, low reasoning effort is sufficient. On the other hand, if you use a model with inherently weaker capabilities (like the mini series), it might sometimes have trouble understanding the task, leading to unstable returned results.

Interface Display During Sub-Agent Execution

In the Codex desktop client, we can see the status of sub-agents when they are running. The main conversation interface shows the execution progress of sub-agents, and you can click into it to see detailed output.

If a sub-agent fails (e.g., file read error, command execution failure), the main Agent receives a failure notification. It usually decides whether to retry or skip. If the problem is serious (insufficient permissions, file not found), it will stop and tell us where it's stuck.

We don't need to manually manage the lifecycle of sub-agents; the main Agent coordinates them. But if you find a sub-agent has been stuck for a long time, just say "Stop that sub-agent" or "Restart it" in the main conversation.

Parallelism Limits

In config.toml, you can set the parallelism limits for sub-agents:

[agents]
max_threads = 6
max_depth = 1

• max_threads — Maximum number of sub-agents running simultaneously, default is 6
• max_depth — Whether sub-agents can spawn further sub-agents, default is 1 (only one level deep, no nesting)

Generally, the defaults are sufficient and don't need changing.

My Own Usage

I don't use sub-agents very often. Most daily tasks can be handled by a single Agent. But there are two situations where I use them:

The first is when the project is large and I'm just starting to get familiar with the codebase. I ask Codex to dispatch several sub-agents to look at different modules, each giving me a brief summary. This allows me to quickly understand the overall project structure without the main Agent reading all the files into its own context.

The second is during Code Review. I ask it to dispatch three sub-agents with different perspectives (security, test coverage, code style), each producing a report, and finally summarizing them. This is more comprehensive than having one Agent read through all the code.

Also, I wrote an Explore Skill myself, whose principle is based on sub-agents. Installation method:

git clone https://github.com/oil-oil/codex-explore-skill.git ~/.codex/skills/explore

After installation, at the beginning of a conversation, I tell Codex "Use explore to first look at this codebase," and it will dispatch sub-agents for code exploration. The sub-agents read a large number of files in their own contexts, and finally return only a key file table and a brief summary to the main Agent. This keeps the main Agent's context lean from the start, not filled with the contents of dozens of files.

The logic of this Skill references the Explore sub-agent mechanism in Claude Code. In Claude Code, whenever it needs to look at a lot of code, it automatically dispatches an exploration sub-agent to first locate things, then passes the key paths to the main Agent. Codex itself rarely does this proactively, so I wrote this behavior into a Skill to trigger when needed.

---

The Origin and Principle of Skills

What Exactly is a Skill

Many people, when first hearing the term Skill, think it's something very profound. In reality, it's just an operation guide written for the AI, saved locally as a file.

More bluntly: a Skill is a folder. Inside, there's a Markdown file (SKILL.md), and possibly some scripts and reference materials. When needed, the AI Agent reads this file and executes according to the steps written inside.

Skills themselves are not a new invention. Before the concept of Skills existed, we were already using various methods to write workflows into files for AI to read. For example, writing a Markdown document describing code conventions and asking the AI to read it before writing code. Or writing a script for the AI to run at a certain time.

Now, Skills are often hyped up as if they enable AI Agents to do things they previously couldn't. But in reality, it's just a tool for structuring context. If you've used Coding Agents before, you might have already been managing context in a similar way — writing a Markdown file in the project for the AI to read is essentially the same thing.

What Anthropic (Claude's company) did was standardize this ad-hoc practice: fixed the folder structure, fixed the format, gave it a name called Skill, and made it recognizable and usable by all Agent products. Now, whether it's Codex, Claude Code, or Cursor, they all support Skills.

Why Skills are Needed

Let's reframe the question: the AI model itself is already very powerful, so why does it need additional "operation guides"?

Two reasons.

First, knowledge the AI itself doesn't possess. For example, our company's internal code conventions, how to call a certain third-party API, or how to use a tool I wrote myself. These things are not in the AI's training data; it doesn't know them. We write this knowledge into a Skill, and it knows after reading it.

Second, repetitive workflows. For example, I write a daily report every day, submit code following a PR process every time, or follow the same steps for every design draft. Explaining these from scratch to the AI every time is too time-consuming. Write the workflow as a Skill, and trigger it with one sentence later.

Anthropic, in their official article, positions Skills as: packaging our professional experience into reusable resources, turning a general-purpose Agent into an expert in a specific domain.

There's also a key point: Skills written by AI for AI usually don't work well. Without human know-how involved, if you ask the AI to generate a Skill itself, it will just rewrite what it already knows. When it reads it next time, it's essentially looking at its own existing knowledge, with no increment.

Truly valuable Skills are those where we, as humans, write in the things the AI does poorly, the mistakes it tends to make, and our unique experience and judgment. This is the key to it doing better next time.

Progressive Loading Mechanism

This is the smartest part of Skill design.

If we install 30 Skills, does the entire content of all 30 Skills get stuffed into the context every conversation? No. Anthropic designed a mechanism called Progressive Disclosure:

Layer 1: Name and Description. The name and description of all Skills are sent to the AI in every conversation. Each Skill takes up about 100 Tokens. This is the basis for the AI to judge "Do I need to use a certain Skill right now?"

Layer 2: Body Content. Only when the AI determines, based on the description, that "this Skill is relevant to the current task" does it read the body of SKILL.md. The body is usually kept within 5000 Tokens.

Layer 3: Attached Resources. The body might say "If you need to do XXX, read references/xxx.md." Only when truly needed does the AI read those reference files and scripts. When not needed, they sit quietly on the hard drive, not consuming context.

The benefit of this design is: we can install many Skills without making every conversation bloated. Only the triggered Skills actually consume context budget.

Using an analogy: a Skill is like a library catalog. The AI browses the catalog (name + description) in every conversation to see if there are any books related to the current task. If it finds one, it goes to the shelf, takes the book down, and opens it (loads the body). If the book says "see Appendix C for detailed data," it then goes to look at the appendix (reads references).

File Structure of a Skill

A standard Skill looks like this:

my-skill/
├── SKILL.md          # Required, entry point
├── references/       # Optional, reference materials
├── scripts/          # Optional, executable scripts
└── agents/           # Optional, openai.yaml configuration

Format of SKILL.md:

---
name: my-skill-name
description: Describe what this Skill does, when to trigger it, and when not to trigger it.
---

Specific operation steps and guidelines are written here...

The part between the three dashes at the top is called frontmatter, in YAML format metadata. This part is Layer 1, always in the context.

The Markdown body below the three dashes is Layer 2, only loaded after being triggered.

The scripts directory holds scripts. For example, if a Skill needs to call a certain API, I can write the calling logic as a Python or Shell script. The AI can directly run this script during execution, without needing to rewrite the code each time.

The references directory holds reference materials. For example, design specification documents, API interface definitions, historical data, etc. The AI reads them only when needed.

Trigger Methods

There are two ways to trigger a Skill:

Active Trigger — We manually specify which Skill to use in the conversation using $skill-name or typing /skills. This method is the most reliable.

Automatic Trigger — We speak normally, and the AI matches the content of our message against the descriptions of all Skills. If the semantics match, it automatically loads the Skill. For example, if I say "Help me add subtitles to a video," and a Skill's description says "Handle video subtitles," it triggers automatically.

The wording of the description is crucial here. If it's too vague, it might trigger incorrectly; if it's too narrow, it might not trigger at all. A good practice is to clearly state the trigger keywords in the description, and also explicitly state "when not to trigger."

Difference Between Skills and Regular Documents

Some people ask: I can just write a Markdown file and put it in the project directory for the AI to read. What's the difference from a Skill?

Functionally, they are quite similar. Any Agent capable of reading files can read Markdown.

But Skills offer a few extra benefits:

• Automatic Triggering — Regular files require us to manually ask the AI to read them each time, or specify them in AGENTS.md. Skills can be triggered automatically based on conversation content.
• Progressive Loading — If a regular file is specified in AGENTS.md, it must be loaded entirely each time. Skills only load the body when triggered.
• Standardized Format — Different Agent products can recognize the Skill format; write once, use everywhere.
• Distributable — Skills have a standard installation method; put them on GitHub, and others can install them with a single command.

If you're just using it yourself, writing a regular file is perfectly fine. But if you want your workflow to be reusable, shareable, and automatically triggerable, writing it in the Skill format is much more convenient.

---

How to Find and Install Skills

Where to Find Skills

The main channels for finding Skills are:

GitHub Search. The most direct way. Search on GitHub for "codex skill" or "claude skill" plus the function keyword you want. You can usually find many. Many individual developers open-source the Skills they write.

Skills Marketplace. A marketplace website specifically collecting Codex Skills, searchable by category. It's better organized than searching GitHub directly.

ClawHub. This is a community-driven Skill and Plugin store, currently hosting over 50,000 tools. If the Skill you're looking for is more general-purpose (not just Codex-specific), you can check here.

Codex Desktop's Plugins Page. In Codex, click Plugins on the left, switch to the Skills tab. You can search and browse some recommended Skills here.

Let the Agent Find It for You. I think this is the most convenient method. Just tell Codex "I want a Skill that can help me do XXX, help me find one." It will search, evaluate, and even install it directly for you.

How to Install

There are three ways to install a Skill, from simple to complex:

Method 1: Let the Agent Install It

This is my most recommended method. After finding a Skill's GitHub link, just throw it to Codex and say "Help me install this Skill." It will download it and place it in the appropriate directory itself. It's that simple.

Because the Agent itself has the ability to download files and operate folders, installing a Skill is a very basic operation for it.

Method 2: Install via Command Line

Run in the terminal:

npx skills add owner/repo-name

For example, to install my draw-ui:

npx skills add oil-oil/draw-ui

After running, it will ask you which Agent to install it for (Codex, Claude Code, or others). Select one and press Enter, and it's installed.

Method 3: Manual Download

Download the repository from GitHub (or git clone), then place the folder in the appropriate directory:

• Codex global Skill directory: ~/.codex/skills/
• Claude Code global Skill directory: ~/.claude/skills/
• Project level: .codex/skills/ or .agents/skills/

Although manual operation has a few more steps, the advantage is that you know exactly where the files are placed.

Verification After Installation

After installation, you can verify. In the Codex desktop client, open Plugins > Skills and see if the newly installed Skill appears in the list. If it does, the installation was successful.

You can also test it directly: type a sentence related to this Skill and see if it triggers automatically. If it doesn't, you can manually call it with $skill-name.

Advice on How Many to Install

Earlier, when discussing context, I mentioned that the name and description of each Skill are permanently in the context. Although each takes up only about 100 Tokens, they add up. More importantly, with too many Skills, the AI is more likely to select the wrong one during matching.

My advice is: Don't install without a real need.

If you've installed a Skill and only used it once or twice, or its functionality can be explained in a few sentences, its existence is just wasting context space and increasing matching interference.

I regularly clean up my Skill list, disabling or deleting infrequently used ones. In config.toml, you can disable without deleting:

[[skills.config]]
name = "some-unused-skill"
enabled = false

Keep it lean. The cleaner the context, the better the AI's execution.

---

How to Write a Good Skill

Nowadays, Almost All Skills are Written by AI

Let's start with a major premise: when we write a Skill now, we don't type the Markdown character by character ourselves. The entire process is described to the AI.

My approach is usually: describe to the Agent clearly "what kind of Skill I want, when it should be triggered, the core workflow, and any important notes," and then ask it to generate the SKILL.md and supporting files. Codex has a built-in Skill called Skill Creator specifically for this. Claude Code and Cursor also have similar creation flows.

But here's a key point: The model used to write the Skill must be strong enough.

Because a Skill essentially solidifies a strong model's understanding and judgment into a file, which can then be read and executed by any model (including weaker ones). If you use a weak model to write the Skill, what it writes might itself have understanding biases, and the subsequent execution will be even worse.

Using the strongest model to write a Skill is like distilling part of the strong model's knowledge into a file. Later, even if a cheaper model is used for execution, it can follow this high-quality guide.

So my advice is: Use the strongest model (GPT-5.5 or Claude Opus) for creating and iterating Skills, and use the default model for daily triggering and execution.

When is it Worth Writing a Skill

Not everything needs to be made into a Skill. My criterion is simple: If I do a task more than twice a day, or if I have to repeat background information every time, it's worth writing a Skill.

For example, I write a daily report every day, submit code following a PR process every time, or make a PPT for every presentation. The steps for these tasks are fixed; only the specific content changes each time. Writing them as a Skill allows triggering with one sentence.

Conversely, if the AI can do it well on its own, there's no need to write a Skill. The model already knows how to write React components; you don't need to write a "How to Write React Components" Skill. Skills should provide knowledge and judgment that the model itself doesn't possess.

The Description is the Most Important Part

When writing a Skill, the most commonly overlooked part is the description. Many people spend a lot of time on the body but write only one sentence for the description. This leads to the Skill either not triggering or triggering incorrectly.

A good description should contain three pieces of information:

1. What this Skill does (write in third person, as it will be injected into the system prompt)
2. When it should be triggered (list keywords and scenarios)
3. When it should NOT be triggered

For example:

description: >
  Add AI subtitles to videos. Trigger when the user mentions "add subtitles," "subtitles," "subtitle,"
  "process this video," "video subtitles."
  Do not trigger when the user is just discussing video content, or talking about other format conversions.

Including trigger keywords is important because the AI relies on semantic matching of the description to decide whether to use the Skill. The "when to trigger" part of the description is the key to whether the Skill is correctly invoked — writing it in the body is useless because the body is only read after triggering.

How to Write the Body

The body is the operation guide. After triggering the Skill, the AI reads this part and executes according to what's written.

A few principles:

Keep it within 500 lines. Once the body of SKILL.md is loaded, the entire content enters the context. Writing too long wastes attention budget. If you really need a lot of content, break the detailed parts into the references directory.

Write imperative steps, not lengthy explanations. The AI needs "what to do," not "why to do it this way." For example, write "Step 1: Check if there's a package.json in the project," not "First, we need to confirm the project's tech stack, because different tech stacks have different handling methods..."

Use concise examples instead of lengthy explanations. If an operation is hard to describe clearly with text, give a concrete example; the AI will understand at a glance.

Ask yourself for every piece of information: Does the AI really need this? If the AI can do a good job without reading a certain piece of content, don't write it in.

When to Use scripts

If some steps require precise execution and cannot be left to the AI's free will, write them as scripts. For example:

• Calling a specific API with fixed headers and authentication information
• File format conversion requiring specific commands and parameters
• Data processing requiring precise logic without deviation

The benefit of scripts is that the execution process is deterministic and won't have errors due to the AI's understanding biases. Also, once the script is written during Skill creation, the AI can directly run it during subsequent use, without needing to rewrite the code each time.

When to Use references

When the body needs to reference some longer reference materials that aren't used every time, put them in references. In the body, just write a sentence like "If you need to do XXX, first read references/xxx.md."

For example, in my UI design Skill, references contains some principles of design psychology. Not every design task requires looking at these, but if I want the design to be more professional, I can ask the AI to read them before designing.

Workflow Skills: Run Through First, Then Write

If we want to encapsulate a workflow into a Skill, my experience is: Don't try to write the Skill from the start. First, use normal conversation to have the Agent run through the entire process completely once.

For example, I want to create a "Video Subtitling" Skill. I wouldn't start writing SKILL.md right away. Instead, I'd first, in a conversation, step by step, have the Agent go through the entire process: extract audio, transcribe, proofread, generate subtitle file, burn in. If it does something poorly at any step, I correct it.

After the entire process is run through and the result is satisfactory, I go back and review the conversation: which steps were fixed, where I provided additional guidance, where it tended to make mistakes. I distill these things and then write the Skill.

Skills written this way are of much higher quality than those written from imagination, because every instruction has been practically verified.

Testing Skills with Sub-Agents

After writing a Skill, how do you verify if it's good?

My approach is to ask the Agent to start a sub-agent and have the sub-agent use the Skill in a clean context. Because our own main conversation might already have a lot of context information, the Skill might seem to work fine, but it's actually being assisted by the background information already in the context.

Having a completely new sub-agent start from scratch, relying solely on the content written in the Skill, truly tests whether it's clear and complete enough. If the sub-agent can do it well, it means the Skill is self-consistent. If not, it means some information is missing and needs to be supplemented.

Feedback and Iteration

Skills are not written once and used forever. After using them for a while, you'll find that the AI always does poorly in certain areas. At that point, you need to go back and modify the Skill.

For example, I wrote a design Skill with some guidelines for it to follow. After a few uses, I found it was too rigid, producing similar designs each time without creativity. So I went back and changed those guidelines from "hard requirements" to "reference directions," giving it more freedom.

Modifying the Skill itself can also be done by the AI. Tell it "I think this Skill is not doing well in XXX area, help me adjust it," and it will modify SKILL.md itself.

But the core judgment — where it's doing poorly and how it should be changed — must be done by a human. Because if the AI optimizes its own Skill, it will only rephrase its existing knowledge without generating new insights. It's us humans who tell the AI where it's doing poorly, so it can do better next time. This is the core of Skill iteration.

Additional Writing Suggestions

Explaining "why" is more effective than giving orders. When writing rules in a Skill, telling the AI the reason is better than writing "you must do this." For example, writing "Don't output more than 2000 lines in one file, because the output Token has a limit and speed will decrease exponentially" is more effective than writing "Prohibit outputting more than 2000 lines." When the Agent understands the reason, it can make correct judgments in new situations, rather than rigidly following one rule and making the same mistake elsewhere.

The division of labor between AGENTS.md and SKILL.md should be clear. Many people are confused about what goes in AGENTS.md and what goes in SKILL.md. Simply put: if a piece of information is needed in every conversation (like the project's build commands, code conventions, directory structure), put it in AGENTS.md; if it's only needed when doing a specific task, put it in SKILL.md. Don't stuff everything into a Skill.

Review Skills installed from the internet. Skills can change the Agent's behavior, making it run commands, install tools, and operate files. If a Skill contains instructions for the Agent to execute dangerous commands or handle credentials, review the content before using it. Just like installing software, be cautious with untrusted sources.

When diagnosing a poorly performing Skill, refer to this table:

Phenomenon	Possible Cause
Doesn't trigger when it should	Description is too abstract, missing keywords users actually say
Triggers the wrong Skill	Descriptions of two Skills overlap
Triggers but result is wrong	Body steps are not clear enough or missing key information
Fails halfway through execution	Missing error handling or prerequisite checks

When encountering a problem, adjust accordingly based on the phenomenon. Skills improve through continuous use and modification; they are not perfect on the first try.

Don't Stress About These Rules

Seeing this, some might think there's a lot to remember. Don't worry, because most of the writing principles mentioned above are already written into Codex's built-in Skill Creator Skill. When we ask the Agent to create a Skill for us, it will follow these rules itself.

What we need to do is not memorize these rules, but understand the logic behind them: context is limited, description is the routing signal, the body should be concise, scripts handle deterministic operations. Understanding this, we know which direction to adjust when reviewing and iterating Skills.

Actual Process of Creating a Skill

In practice, I generally follow three steps:

Step 1: Discuss the requirements with the Agent. Tell it what I want to do, in what scenario to trigger, what the core workflow steps are, and what areas are prone to errors. This step is about articulating the know-how in my mind.

Step 2: Let it generate the first version. Codex has a built-in Skill Creator; just say "Help me create a Skill." It will generate SKILL.md and supporting files according to the standard structure. Cursor also has a similar creation flow. The generated first version usually has the correct structure, but the content might be too generic.

Step 3: Manually supplement key judgments. This is the most important step. Review the generated Skill and add things that the AI doesn't know but I do. For example, "This API might time out in certain situations, need to add retry logic," or "If the generated file exceeds 2000 lines, it needs to be split." These are practical experiences.

The entire process is: humans are responsible for judgment and decision-making; AI is responsible for generation and formatting. We don't need to type the Markdown format ourselves, but the core know-how must be provided by humans.

---

Practical Skill Scenarios

Earlier, we discussed the principles of Skills, how to find them, and how to write them. In this section, I'll share a few Skill directions I actually use myself.

But I want to emphasize one point first: Rather than installing other people's Skills, a better approach is to define Skills that suit your own workflow. Because everyone's projects, conventions, and habits are different. Generic Skills are hard to perfectly fit your scenario. The best use of others' Skills is as a reference and source of inspiration, then modify them or write your own based on your actual needs.

Cross-Agent Collaboration

Different Agents excel at different things. We can write a Skill that lets the current Agent delegate certain tasks to another Agent.

For example, I use Claude Code as my main development tool, but for some repetitive execution tasks, I want to hand them over to Codex (because it uses the ChatGPT Pro quota, not API billing). I wrote a Skill that includes a script. When Claude Code passes a task description to it, Codex starts executing in the background, writes the result to a file, and Claude Code reads the result. The contexts of the two Agents are completely independent and don't interfere.

The same idea applies to: the main Agent uses a strong model for decision-making, and sub-agents use cheap models for execution; or different Agents handle frontend and backend work respectively.

Daily Workflow Automation

Anything we do more than twice a day is worth encapsulating into a Skill.

For example, a few directions I've done myself:

• Writing Daily Reports — The Skill configures the report format and the Feishu document writing method. Every day, I just say "Write daily report" to the Agent. It looks at today's Git commit history, analyzes what was done, and writes it to a Feishu document in the specified format. I don't need to recall what I did today.
• Submitting Code — A Git Ship Skill that automatically completes: check code → create branch → commit → push → create PR → wait for CI to pass → merge → switch back to main branch and pull latest code. The entire process is self-contained.
• Multi-Platform Publishing — After recording a video, one sentence asks it to distribute it to Xiaohongshu, Bilibili, Douyin, and other platforms.

The characteristic of this type of Skill is: the steps are fixed; only the specific content changes each time. Write the workflow into the Skill, and the Agent only needs to fill in the specific content for that instance.

Codebase Information Extraction

The information in a codebase is more comprehensive than a PRD and is always up-to-date. PRDs become outdated, but code doesn't, because code is what the system is actually running.

We can use Skills to extract various forms of output from the code:

• For Technical People — Convert code implementation into an interactive course, explaining what each module does and how data flows. Suitable for newcomers to quickly understand an unfamiliar project.
• For Product Managers — Extract business logic, product concepts, user journeys, and resource relationships from code and PRDs, generating a visual business understanding report. Much faster than flipping through a dozen PRDs.
• For Yourself — When taking over a new project, ask the AI to scan the entire repository and generate an architectural overview, quickly building a holistic understanding of the project.

Skills in this direction usually have high overhead (because they need to read a lot of code), but the output is very practical.

Skill Performance Optimization: Templating Mindset

Many Skills, when generating the final product (like HTML reports, PPTs), ask the AI to write the entire file from scratch. If the file is large (thousands of lines), the AI's output speed is very slow, and Token consumption is very high.

An optimization idea is: Make the repetitive parts into pre-made template fragments. The AI is only responsible for generating the content data, and the assembly is done by a script.

For example, a Skill that generates an HTML report could be designed like this:

• references contains the HTML style templates and code snippets for interactive components
• After analyzing the code, the AI only outputs a structured JSON (title, paragraph content, chart data)
• A script reads this JSON, inserts the content into the template, and assembles the final HTML

This way, the AI's output is reduced from thousands of lines to hundreds of lines, the speed is much faster, and the style and interaction of the final product are more stable (because they are pre-made, not different each time).

The core idea is: For things that can be deterministically completed by a program, don't let the AI rewrite them each time. The AI is responsible for thinking and decision-making; the script is responsible for assembly and execution.

Design and Creative Assistance

Leveraging Codex's built-in image generation capability, we can encapsulate the design workflow into a Skill:

• Use reference images + prompt strategies to generate UI design drafts
• After generation, automatically restore them into HTML code
• When making PPTs/Slides, automatically select themes, colors, and layouts

The key to this type of Skill is solidifying the experience of "how to write effective prompts." This way, the AI doesn't have to rely on luck each time but generates according to proven strategies.

External Platform Connection

Through Skills combined with CLI tools or MCP, the Agent can operate various external platforms:

• Feishu: Read and write documents, send messages, manage knowledge bases
• GitHub: Create PRs, review code, manage Issues
• Databases: Query and modify data in Supabase, MongoDB
• Social Media Platforms: Publish content via browser automation

This type of Skill usually places some authentication-related configurations (Tokens, API Keys) in the scripts directory, so the Agent doesn't need to ask us for authentication information every time during execution.

Skills Are Definitely Not the More the Better

I've mentioned this point before, but it's so important that I'll say it again here. This is not just a Codex issue; it applies to all Agent products.

Whether it's Codex, Claude Code, Cursor, or other Agents, the metadata (name and description) of Skills is written into the context in every conversation. The more Skills, the larger this part occupies, and the more the model's attention is scattered.

Taking Codex as an example, it has a clear budget mechanism: Skill metadata is limited to about 2% of the context window. If it exceeds this, it truncates descriptions; if it exceeds even more, it omits Skills entirely. But even without exceeding the budget, dozens of Skill descriptions crammed together make it easy for the model to select the wrong one during matching.

The same goes for Claude Code. Although it doesn't have a hard percentage limit, the context is finite, and the descriptions of dozens of Skills add up to thousands of Tokens, occupying space in every round of conversation.

My own approach is:

• Only keep truly high-frequency Skills
• Disable infrequently used Skills, turn them back on when needed
• Also check the Skills that come with Plugins and disable the unused ones
• Prefer having fewer Skills to maintain matching accuracy

When to Write a Skill, When to Just Say It

Not all scenarios require a Skill.

If you only do something occasionally, just tell the Agent directly. The Agent's own capabilities are already very strong; for most things, just stating the goal clearly is enough.

Only when you find yourself doing the same thing repeatedly, or the AI always does poorly at a certain point and needs additional know-how, is it worth spending time to write a Skill.

Writing a Skill takes time, but subsequent uses save the cost of repeated communication. However, if you only do the task once, the time spent writing the Skill is not worth it.

---

Harness Concept and Design

What is Harness

The word "harness" literally translates to a horse's rigging or to control. In the context of Agents, Harness Engineering refers to: how to design an engineering environment that allows an Agent to work autonomously, reliably, and continuously.

OpenAI published an article in 2026 called Harness Engineering that discusses this concept. Its core point is: we used to focus on how to write good prompts (Prompt Engineering), then evolved to how to manage context well (Context Engineering), and now we've reached the next stage — how to design the entire engineering environment for the Agent to work stably (Harness Engineering).

These three stages are progressive:

• Prompt Engineering — How to write a good sentence for AI to give a good answer
• Context Engineering — How to manage all the information the AI can see
• Harness Engineering — How to design the entire environment for the AI to work on its own for a long time without errors

But to be honest, there's no fundamental discontinuity between these three concepts. Harness Engineering sounds impressive, but if you already understand Context Engineering, Harness is just the systematic implementation of Context Engineering.

Context Engineering is about "how to make the AI see the most useful information in each round of conversation." Harness is about "how to design a set of mechanisms so that the AI, over long periods, multiple rounds, and multiple topics, can always see useful information, follow correct conventions, and make stable judgments."

One is optimization at the single-conversation level; the other is systematic design at the project level. Essentially, both are about managing "what the AI can see."

So you don't need to treat Harness as a completely new discipline. If you are already doing these things — writing AGENTS.md, using Skills to manage workflows, using Hooks for automatic checks, saving knowledge in file form — you are already doing Harness Engineering, just without a unified name for it before.

Why Harness is Needed

If you've been using Agents to write code for a while, you've probably encountered these problems:

• It repeatedly makes the same wrong approach, going through several rounds of fixes without improvement
• Every time you open a new thread, it forgets the previously established conventions and creates a new set
• As the codebase grows, its understanding of the overall structure gets worse
• More and more of our time is spent reviewing code and testing functionality, rather than advancing new features

The root cause of these problems is that we are only giving the AI individual instructions each time, without designing a set of rules that allow it to work stably and continuously. It starts understanding your project from scratch every time, without a fixed working framework to constrain it.

Harness is this framework.

Core Components of Harness

According to articles from OpenAI and Anthropic, and my own practice, a good Harness roughly includes these layers:

Project Specification File

This is the most basic layer. Place a specification file in the project root (AGENTS.md in Codex, CLAUDE.md in Claude Code) telling the Agent:

• What tech stack and framework does this project use
• Where is the code located, what does each directory do
• How to start the project, how to run tests
• What are the code style conventions

This way, every time a new thread is opened, the Agent's first action is to read this file. It immediately knows the project's overall picture, without needing to spend a lot of context exploring.

Put Knowledge in the Repository

Much project-related knowledge is scattered in Feishu documents, Notion, or team members' minds. The Agent can't see these things.

My approach is to create a docs/ directory in the project and store architecture designs, product requirements, database structures, etc., as files. This way, the Agent can read them when needed, without us having to manually copy and paste each time.

For database structures, I recommend directly connecting an MCP (like Supabase or MongoDB) so the Agent can query the real-time table structure itself. This is more reliable than maintaining a potentially outdated document.

Enforce Rules with Programs

In the past, we wrote in prompts "Run type checking after every code change." But when the context gets long, this prompt gets buried, and the Agent forgets.

A better approach is: through the Hook mechanism, after every code modification by the Agent, the program automatically runs type checking and linting. Regardless of whether the Agent remembers, the check will be executed. If there are errors, the error information is automatically injected into the Agent's context, and it will fix them itself.

The idea is: For things that can be deterministically guaranteed by a program, don't rely on prompts. Prompts can be ignored when the context is long, but Hooks are program-level and won't be forgotten.

Enable the Agent to Self-Verify

This is the key to letting the Agent work on its own for a long time.

If the process for fixing a bug is: Agent modifies code → we manually test on the page → tell the Agent the result → Agent modifies again → we test again... this loop involves too much human participation, and the Agent can't work on its own at all.

For the Agent to run this loop itself, it needs:

• The ability to start the project and test environment itself
• The ability to view the page effect in a browser itself (via Agent Browser or Chrome plugin)
• The ability to read console logs itself (via Chrome DevTools MCP)
• The ability to judge whether the fix result meets expectations itself

When the Agent has the complete loop of "modify code → test itself → view logs → fix again," it can keep working until the bug is fixed. We just need to set a Goal and go to sleep.

Mechanized Execution of Architecture Conventions

OpenAI's Harness team did something very interesting while developing products with Agents: they wrote architecture conventions as custom Linter rules. Each Linter error message directly included the fix method.

This way, every time the Agent wrote code that didn't conform to the conventions, the Linter would report an error, and the error message itself told it how to fix it. No need to write hundreds of lines of architecture explanation in prompts; one Lint error was enough.

They even did periodic "garbage collection": asking the Agent to periodically scan the codebase for deviations from the architecture conventions, and automatically open PRs to fix them when found.

How to Implement for Ordinary Users

Some of the practices mentioned above might be too engineering-oriented. For most people, it doesn't need to be that complex. The most core things:

1. Write a good project specification file (AGENTS.md) — This is the lowest cost, highest return step. Let the Agent quickly understand the project every time it opens a new thread.
2. Write recurring mistakes into the specification — If the Agent always does something wrong in a certain area, write the correct approach into AGENTS.md.
3. Connect it to verification tools — Let it run tests, see error messages, and read logs itself, without relying on us to manually confirm everything.
4. Design clear exit conditions for tasks — When using Goal, clearly state what counts as done and give it a clear verification method.

An Example of AGENTS.md

Here's roughly what an AGENTS.md for a medium-complexity Next.js full-stack project looks like:

# Project Overview
This is a SaaS product frontend project, using Next.js 14 + TypeScript + Tailwind CSS + Supabase.

# Startup and Testing
- Install dependencies: pnpm install
- Development environment: pnpm dev (port 3000)
- Type checking: pnpm typecheck
- Lint: pnpm lint
- Unit tests: pnpm test

# Directory Structure
- src/app/ — Next.js App Router pages
- src/components/ — Shared components
- src/lib/ — Utility functions and API wrappers
- src/hooks/ — Custom React Hooks
- supabase/migrations/ — Database migration files

# Code Conventions
- Use functional components, not class components
- All styles use Tailwind, no CSS files
- API requests go through the wrapper functions in src/lib/api.ts
- Database operations go through Supabase Client, no direct SQL

# Important Notes
- Do not modify existing files in supabase/migrations/; create new migrations for new changes
- Environment variables are in .env.local, do not commit to Git
- Run pnpm typecheck after modifying code to confirm no type errors

This file doesn't need to be very long. The key is to let the Agent know in thirty seconds: what the project uses, where the code is, how to run it, and what rules cannot be broken. After writing this, we don't need to repeat this background information every time we open a new thread.

And this file can also be generated by the Agent itself. In the project directory, tell it "Help me generate an AGENTS.md." It will look at package.json, directory structure, and existing code, and write a first draft. We just review and modify it.

Harness is not designed all at once. It's supplemented bit by bit during daily use. Every time you find the Agent doing poorly in a certain area, think about whether this problem can be avoided through environment design, rather than correcting it in the conversation each time.

Anthropic's View

Anthropic, in their article, mentions a very important principle: Every component in the Harness encodes an assumption about "what the model cannot do on its own." These assumptions need to be frequently questioned because models are getting stronger.

This means that some rules we add to the Harness today might not be needed tomorrow with a new model. For example, we might have previously needed to force the Agent to always make a plan before executing in the Harness, but current models are already very good at planning on their own, so this restriction might be removable.

Therefore, the design principle of Harness is: Keep it as simple as possible, only add complexity where truly needed. First, try the simplest approach to see if it's sufficient; if not, add rules. Don't design a hugely complex system from the start.

---

How Vibe Coding Improves Efficiency

Vibe Coding is using an AI Agent to write code, without manually modifying files yourself, relying entirely on describing requirements for the Agent to execute. My daily development is basically in this mode.

After using it for a while, I've summarized a few practices that can significantly improve efficiency.

Parallelizing Multiple Requirements: Isolate with Worktrees

If you have several requirements to handle simultaneously, like one modifying the homepage style, another fixing a backend interface, and another adding a new feature, and they are unrelated to each other, the most efficient approach is to let them run in parallel without interfering.

Worktree is for this purpose. It's like creating a copy of your code repository. You make changes in the copy without affecting the main project. After finishing, you create a PR to merge back.

In the Codex desktop client, when creating a new thread, you can choose Local (local project) or Worktree (new worktree). After choosing Worktree, all the Agent's changes are in an independent worktree, completely isolated from other threads you are running.

In Claude Code, there's no UI for selecting a worktree, but you can directly say "Help me create a worktree and switch to a new branch." It will execute the Git commands itself. When exiting the thread, it will ask if you want to delete the worktree.

This way, I can open three or four threads simultaneously, each working on its own requirement in its own worktree, without conflicts. When each is done, I create separate PRs to merge. If there are conflicts, I handle them during the PR merge.

Parallelism Within a Single Thread: Sub-Agents

Sometimes it's not multiple requirements, but one large requirement has several things that can be done simultaneously. For example, I want the Agent to review the code of three modules, and these three modules are independent of each other.

Codex and Claude Code both have sub-agent capabilities. Claude Code automatically dispatches Explore sub-agents to find files when exploring code. Codex also supports us actively asking it to dispatch sub-agents for parallel work. The key is not "can I use sub-agents," but in what situations do sub-agents work best:

• The task can be split into several independent parts that don't depend on each other
• Each part requires reading a large number of files (sub-agents have independent contexts, won't fill up the main Agent)
• Only the final conclusions from each part are needed for summarization, not the intermediate processes

For example, reviewing three modules, researching three technical solutions simultaneously, or checking security/tests/style in parallel. These are all very suitable for sub-agents.

But if the task has sequential dependencies (step 2 depends on the result of step 1), or the task itself is simple and doesn't require reading many files, using sub-agents is overkill and consumes more Tokens.

Previously, my approach was to use the Codex Skill within Claude Code to start multiple Codex instances in parallel for execution. But now I've switched to the Codex + GPT-5.5 All-in-One mode. In the Codex desktop client, I just open multiple threads directly, each being a parallel Agent without interference. If I want parallelism within the same thread, I just tell Codex "Dispatch a few sub-agents to do XXX respectively."

Let the Agent Submit Code Itself

In the past, after writing code, I had to manually commit, push, create a PR, wait for CI to pass, and merge. Now, I hand all of this over to the Agent.

After installing the GitHub command-line tool gh, the Agent can directly operate GitHub in the terminal: create branches, commit code, push to remote, create PRs, check CI status, and merge PRs. The entire process can be triggered with one sentence.

I wrote a Git Ship Skill to solidify this workflow: check code → create branch → commit → push → create PR → wait for CI to pass → merge → switch back to main branch and pull latest code. I use it several times a day.

Using /side for Temporary Issues

During development, this often happens: the Agent is helping me with a feature, and halfway through, I suddenly want to confirm an API usage or ask "Will this approach have performance issues?"

If I ask directly in the main conversation, this Q&A pollutes the context. When the Agent continues the feature later, the context contains a bunch of irrelevant stuff.

Using /side is very convenient: temporarily open a sidebar, ask the question, and come back, without affecting the quality of the main context. This was discussed in detail in Chapter 7.

External Data Sources as Part of Harness

Another source of efficiency is letting the Agent directly access project-related external data, rather than us having to manually look it up and copy-paste each time.

For example, I connected Supabase's MCP. The Agent can query the database's table structure, view field types, and even write SQL to verify data. When writing backend interfaces, it can directly query the table to know which fields are available, without me having to flip through documentation.

After connecting GitHub, the Agent can view PR comments, CI error logs, and requirement descriptions in Issues itself. I don't need to manually copy this information in.

Once these external data sources are connected, the Agent can obtain the information it needs during work, significantly reducing the time we spend as "information porters." This is essentially part of Harness — providing enough information sources in the Agent's working environment so it can work more autonomously.

Granularity of Requirement Descriptions

Efficiency largely depends on the granularity of the requirements we describe to the Agent.

Too large is not good. A requirement like "Help me build a user system" is hard for the Agent to get right in one go, and the result will likely need repeated modifications.

Too small is also unnecessary. "Help me add a line break at line 15" — we could probably do this manually faster than describing it to the Agent.

From my experience, a good requirement description granularity is roughly: Something that can be done in one go, and can be immediately verified after completion. For example, "Add an email format validation to the login interface" or "Change the homepage's card list to a two-column layout." After it's done, run it and see if it's correct.

If a requirement is too large, I first use Plan Mode to have the Agent break it down into steps, then execute step by step, verifying each step before continuing.

Describe Behavior, Not Modifications

This is a summary from various practices: Describing the phenomenon you observe or the expected behavior works better than describing the code modification you want.

For example, encountering a bug:

• Bad description: "Add a WHERE condition to filter out deleted users at line 43 of api/users.ts"
• Good description: "When querying the user list with pagination, deleted users still appear in the results"

The latter lets the Agent locate the problem and decide how to fix it itself. It might find a better solution than we thought. If we directly tell it how to modify, we limit its creativity.

Verify After Each Step

Don't let the Agent complete the entire feature in one go before checking the result. Verify after each step, confirm it's correct, then let it proceed to the next step.

The reason is simple: if the first step is wrong but goes unnoticed, all subsequent steps are built on the error. By the time you look at the final result and find everything is wrong, the cost of correction is higher than starting over.

Run it and check after each step. If you find the direction is off, correct it immediately. This habit saves a lot of rework time.

Commit Code Frequently

AI writes code very fast, but that also means code changes happen very fast. If many changes are made without committing, it's hard to revert to a normal state if something goes wrong.

My habit is to commit after each small feature point is completed. This way, if I mess up later, I can easily reset to the previous normal state without starting over.

With Git Ship, it's even more convenient — after finishing one thing, I ask the Agent to commit and push for me; it takes just a few seconds.

---

How Vibe Coding Saves Costs

Saving costs isn't just about reducing Token usage. Different models have vastly different prices. Sometimes spending a lot of money yields poor results, which is actually a waste. This section is about how to spend less overall while maintaining the same execution quality.

My Own View on Costs

Let me start with my own situation. The AI tool quota I use now is reimbursed by my company, so I don't worry much about costs in daily development. But many of my cost-saving experiences were accumulated when my previous company didn't reimburse me.

Back then, spending several hundred or even over a thousand RMB a month on AI tools was quite painful. But I later discovered something: Compared to the dozens of times efficiency improvement brought by AI, it's almost impossible for me to go back to using inferior tools. Once you've used the good stuff, going back to free, weak models and grinding slowly is far more costly in terms of time than a few hundred bucks.

So for individual developers, the key is not "how to spend no money," but "how to spend money where it counts."

I also want to say: if your current company won't even reimburse 500 RMB a month for AI tools, your development efficiency is likely already far behind your peers. In this case, either pay for better tools yourself as an investment in yourself, or seriously consider switching to a team that doesn't limit Token usage. In 2026, the cost of AI tools is negligible for a company, but the impact on individual efficiency is a difference of several times to over ten times.

The methods below are to help you minimize waste without reducing execution quality.

Monthly Subscription vs. API Pay-as-You-Go

We discussed this in Chapter 2. If you do heavy development daily, a monthly subscription is far more cost-effective than API pay-as-you-go. With API billing, every time you ask the Agent to read a file or run a command, you're spending money. A few rounds of conversation can cost several dollars. With a monthly subscription, the price is fixed regardless of usage, so you don't have the psychological burden.

I currently use ChatGPT Pro ($200), paired with Codex + GPT-5.5, which is more than enough for my daily heavy development. Previously, using Claude's API pay-as-you-go, my monthly bill was much higher than this, and I had to constantly monitor usage.

Not All Tasks Need the Strongest Model

This is the most direct way to save costs.

My previous approach was a three-tier system: the main model (Claude Sonnet) for requirement decomposition and decision-making, a cheap model (GLM, Codex) for specific code execution, and Gemini for design drafts. Because most execution work doesn't require the strongest model; using a cheap model yields the same effect but at a fraction of the cost.

Now that I've switched to Codex All-in-One, I use the same GPT-5.5 but adjust the reasoning effort. Simple tasks use low reasoning (fast, low consumption), and complex decisions use high reasoning.

The core idea is to choose the appropriate model based on the task scenario. For example, domestic models like GLM-5.1 have good conversational feel and decent code ability, at a fraction of Claude's price. They are perfectly adequate for daily Skill optimization, bug fixes, and frontend style adjustments. Gemini is good and cheap for design drafts, producing good results in one go. These models each have their strengths; you don't need to pile everything onto the most expensive one.

The key principle is: Switch models flexibly based on task difficulty and type. Use cheap models for simple execution tasks, and only use top-tier models for complex decisions requiring deep reasoning. It's not an either-or choice; switching models for different tasks within the same project is normal. Most daily work can be handled by mid-range models; switch to a stronger one only when it can't handle something.

Let Programs Do What Programs Can Do

This is the core principle for saving Tokens.

A few examples:

Code Checking — If you let the AI check code conventions itself, it might read every file, consuming a large number of input Tokens. But if you configure tools like ESLint, the AI only needs to run one command to get the check results for all files. What takes a program ten seconds might consume tens of thousands of Tokens if done by the AI.

Batch Replacement — For example, we want to change all className from btn-primary to btn-main in the project. If not reminded, the AI will operate like a human: search for the first file, open it, replace, save; search for the second file, open it, replace, save... Twenty files mean twenty rounds of tool calls, each round writing the previous results into the context. But if we tell it "Write a script to do batch replacement," it only needs to write a sed or Node script, and one execution changes everything. The same result, the former might consume over a hundred thousand Tokens, the latter only a few thousand.

Log Information — If the console outputs a lot of logs, don't copy everything and throw it at the AI. Select only the parts relevant to the problem. Redundant information not only wastes Tokens but also interferes with its judgment.

Reduce Noise from Tool Output

Every time the Agent calls a tool (reads a file, runs a command), the tool's return content is written entirely into the context. Many tool outputs are designed for humans, with a lot of detail that is noise for the AI.

For example, the default output format of git log, the installation logs of npm install, the full report from a Lint tool — these contain a lot of information the AI doesn't need.

There's a tool called RTK (Rust Token Killer) specifically designed to solve this problem. It's a CLI proxy. After installation, it transparently intercepts all Shell commands executed by the Agent via a Hook, compressing the output before it reaches the AI.

Its compression methods include four types:

• Filtering — Remove comments, blank lines, useless formatting decorations
• Grouping — For example, instead of listing 47 .tsx files one by one, it becomes "components/ (47 .tsx files)"
• Truncation — Keep the key information at the beginning and end, cut the repetitive middle part
• Deduplication — If the same log line appears 5 times, merge it into one line with (×5)

Installation is a single command: rtk init -g. After installation, it runs automatically in the background. The Agent is completely unaware of its existence and executes commands normally. According to community data, for the same 30-minute development session, Token consumption can be reduced by 60% to 80%. I've saved 8.8 million Tokens myself, and the AI's execution quality actually improved because there was less noise and the context was cleaner.

RTK supports mainstream Agent tools like Claude Code, Codex, Cursor, Gemini CLI, and GitHub Copilot.

Reduce Exploration Costs with Skills

Every time you open a new thread, the Agent has to re-explore the codebase to understand the project structure. This exploration process is the biggest source of Token consumption in Vibe Coding, accounting for roughly 60% to 70% of total input Tokens.

How to reduce this consumption:

• Write a good AGENTS.md — The Agent knows the tech stack, code location, and how to run immediately upon entry, without having to flip through files one by one.
• Use Skills to maintain project conventions — Frontend conventions, backend conventions, component library usage — write them down. When the Agent needs them, it reads the Skill directly, without having to look at dozens of files to summarize.
• Use Explore sub-agents — As mentioned before, let a sub-agent do the exploration first, only returning key paths to the main Agent, preventing the main Agent from reading a large number of files itself.

Conversation Management Tips

Open new threads promptly. If you chat too long in one thread, the context gets longer, and the input Tokens for each round increase. If a task is done and the next task is unrelated, open a new thread directly. A clean context not only executes better but also consumes fewer Tokens.

Use rewind to reuse context. Sometimes in a long conversation, the earlier information is useful for the next task, but some things done in between are unrelated to the new task. I rewind the later unrelated part (clearing the context but not rolling back the code), and then continue the next task based on the retained useful earlier information. This avoids completely starting a new thread and re-exploring.

Use /side or /btw for small questions. Don't pollute the main context for a small question. Use the sidebar, ask, and leave, without increasing the Token accumulation in the main line.

Clear Requirements Save Money

This is easily overlooked. If our requirement description to the AI is vague, it has to spend a lot of Tokens exploring, guessing, and trying. It might guess wrong after a lot of exploration and have to start over.

Conversely, if we clearly tell it which file to modify (or @ the corresponding file path), it goes directly to read that file without needing to search globally.

The more precise the information we give the AI, the less exploration it needs, and the lower the Token consumption. "Help me modify the navigation bar height in src/components/Header.tsx" saves tens of thousands of Tokens compared to "Help me modify the homepage's navigation bar; it seems a bit too high."

---