Codex, Claude Code, OpenCode, and China's CLI Agents: How AI Actually Operates a Computer System

The first time people see Codex cutting video on a Mac, driving CapCut, editing code, invoking Git, or even dispatching several agents to work at once, they tend to fall for an illusion: the model seems to have crawled inside the computer, seized the mouse, keyboard and terminal, and started working like a real human engineer.

It is not that mysterious.

The large model is still only the "brain." What actually gives it the power to act is the whole agent runtime around it: the file system, the Terminal, Git, the browser, Computer Use, MCP, plugins, permission control, the task loop and context management. Claude, GPT, Kimi and Qwen are the brain; Codex, Claude Code, Kimi Code, Qwen Code and OpenCode are the body and the working discipline; FFmpeg, Git, the shell, the browser and CapCut are the tools it actually holds in its hands.

Once you separate these four layers, today's seemingly tangled AI-coding ecosystem becomes clear at once.

1. First, build the single most important four-layer model

These four layers are often mashed together, which is why so many half-right questions arise: Can Kimi K3 execute a CLI? Is OpenCode a model? Can Codex edit video? Can a Claude subscription log straight into OpenCode?

The answers, in order:

• Kimi K3 is a model; it does not execute a CLI by itself. Kimi Code, or some other agent runtime, is what does the executing.
• OpenCode is not a model — it is an open-source coding-agent shell and runtime.
• Codex can organize a video edit, but what actually performs the trimming, transcoding and compositing are local tools like FFmpeg.
• The official Claude Code client can use Claude-subscription OAuth; OpenCode cannot legitimately reuse those subscription credentials.

The model sets the ceiling, the agent decides how it thinks and loops, the tools decide what it can do, and permissions decide how far it can actually go.

That is the underlying structure of the whole thing.

2. Why Codex can edit video on a local Mac

Codex is not Premiere, not Final Cut, not CapCut, and certainly not a built-in video engine. It can pull off video editing because it can translate natural-language requirements into tool calls and then repeatedly check the result locally.

The most typical workflow is:

1. Use ffprobe to read the video's codec, resolution, frame rate, duration and audio tracks.
2. Generate ffmpeg commands from the user's request.
3. Execute trimming, concatenation, transcoding, compression, frame extraction, mixing, watermarking or subtitle burn-in.
4. Check whether the output file's duration, resolution and encoding match expectations.
5. If needed, re-tune the parameters and run another pass.

So what Codex does best locally is deterministic editing:

Honestly, editing video by CLI and editing video by GUI are two entirely different modes of production. The former is like a CNC machine: parameters are explicit, results are reproducible, and it suits batch work and automation. The latter is like an editing bench: it depends on watching the footage, dragging the timeline, using templates and exercising aesthetic judgment. Codex can take part in both, but the efficiency, cost and stability are not the same.

3. The so-called "mouse plugin" is really Computer Use

The "AI operating CapCut directly" that you often see on TikTok is usually not some mysterious CapCut-specific plugin, but a visual-operation capability of the Computer Use kind.

Its basic loop is not complicated:

capture a screenshot
    ↓
the model recognizes windows, buttons, text and current state
    ↓
decide the next click, input, scroll or drag
    ↓
execute the mouse/keyboard action
    ↓
screenshot again and judge the result

On macOS, this kind of capability typically needs Screen Recording and Accessibility permissions. It can open applications, click buttons, type text, switch windows and use the clipboard — which means it can, in principle, operate CapCut, Photoshop, Excel, or all sorts of old software that has no API.

But "can operate" is not the same as "operates most economically." A GUI runs into pop-ups, animations, interface redesigns, shifted buttons, drag errors and loading delays. And every step needs a screenshot, visual understanding, an action decision and a result confirmation — so a task that should have taken one FFmpeg command can turn into dozens of rounds of interaction.

The most sensible combination is therefore usually:

• Hand deterministic processing to FFmpeg, the shell and scripts.
• When you must use templates, filters, effects or platform-specific features, hand it to Computer Use driving CapCut.
• Let a human still check the final cut for pacing, subtitles, imagery and aesthetics.

Computer Use solves the problem of "this software has no open interface, but I still have to operate it." It is a general-purpose mouse and pair of eyes, not a professional editing engine.

4. Why Computer Use usually burns more quota than the CLI

The issue is not that the plugin gets taxed separately; it is that it has more information to process and more interaction rounds to run.

A CLI task usually looks like this:

read a little text → generate a command → execute → read the text result

Computer Use is closer to:

screenshot → visual recognition → locate the control → decide → click → screenshot again → judge → retry

The difference in consumption comes from four places:

So even for the same task on a Mac, the priority should usually be: an API or structured tool first, then the CLI, and only last GUI automation. Not because the GUI is unsophisticated — precisely because the GUI is designed for humans: rich in information but not deterministic; the CLI is designed for machines: plain, but precise.

5. Codex App and Codex CLI are not two fully isolated systems

A common understanding is that the Codex App and the Codex CLI are installed in two separate paths, using two sets of configuration, two sets of hooks, two Gits and two permission systems. That judgment is only half right.

They are indeed different interaction surfaces, but they share a fair amount of underlying state.

The CLI is more of an efficient executor. It sits closest to the shell, Git, tests and logs, and when the path, the command and the goal are all explicit, it is usually faster, keeps a shorter context and has better token economics.

The App is more of an engineering workbench. Its value is not just wrapping a GUI around things; it is organizing tasks, threads, worktrees, the browser, plugins, screenshots, Computer Use, long-running tasks and result previews together. It gives up some minimalism in exchange for stronger coordination.

So you cannot simply say the App must be less efficient than the CLI. If, inside the App, you still mainly call the Terminal and structured tools, the gap can be small; what really drives up cost is screenshots, GUI operations, long browser chains, multi-agent concurrency and heavy reasoning.

The install locations do differ too: the CLI is usually a command-line executable, while the Desktop App lives in macOS's applications folder. But the user configuration, project rules and much of the runtime state converge around the ~/.codex directory and the in-project .codex directory. They are different cockpits of the same Codex ecosystem, not two machines that have never met.

6. How the Codex App and the ChatGPT App divide the market

The boundary between ChatGPT and Codex is also not as simple as "one chats, one writes code."

ChatGPT targets general knowledge work: documents, search, analysis, writing, images, tables, research and everyday office work. Codex targets engineering execution: code repositories, the Terminal, Git, tests, worktrees, hooks, MCP, code review, automation and long-running tasks.

The two face different high-frequency users. ChatGPT wants to be the general entry point for knowledge workers; Codex wants to be the execution hub for engineers and automated workflows. The underlying model, the plugin architecture and some desktop capabilities can be shared, but the products' centers of gravity are completely different.

7. Codex and Claude Code: not plain copying, but rapid convergence

Claude Code's first-mover advantage is very clear. On February 24, 2025, Anthropic released the Claude Code research preview alongside Claude 3.7 Sonnet. From the start it was a terminal-first coding agent: searching code, reading files, editing, running tests, calling command-line tools — even committing and pushing code.

When OpenAI released the Codex research preview on May 16, 2025, the emphasis was still on a cloud software-engineering agent. At that point the two products were not the same shape: Claude Code had already formed a natural work loop inside the Terminal programmers use every day, while Codex was more like an asynchronous cloud engineer.

The gap then closed fast.

Seen through product history, Claude Code is the first-mover benchmark for the terminal coding agent, while Codex, from the second half of 2025 to the first half of 2026, completed a very fierce platform-scale catch-up.

Does that let us say Codex "copied" Claude Code? The official record cannot prove it. The more accurate framing is this: once the industry confirmed that "model plus Terminal plus tool loop" is an effective form, all the major vendors converged toward the same set of engineering answers. Project-rules files, hooks, skills, subagents, MCP, permission approvals, non-interactive modes — these capabilities will look more and more alike, just as browsers all eventually got tabs, an address bar and developer tools.

But convergence does not mean identity.

Where Claude Code is still strong

• Its terminal-first interaction matured earlier, its workflow is coherent, and the agent loop feels natural.
• CLAUDE.md, hooks, commands, skills and community practice have accumulated depth.
• The Claude Sonnet line has long had a solid reputation for agentic coding, code comprehension and complex refactoring.
• For engineers who live in the Terminal, the cognitive load is very low.

Where Codex is strong

• The CLI, Desktop App, IDE, Cloud, SDK, Slack and other surfaces develop in concert.
• The sandbox, exec policy, approvals and enterprise-governance systems place more emphasis on boundary control.
• Worktrees, task parallelism, visual review and desktop-tool integration in the App are more prominent.
• It has expanded very fast from a single coding agent toward a multi-task engineering platform.

So by 2026, asking "who leads across the board" no longer has as simple an answer as it did in early 2025. Claude Code still has an edge in CLI feel and maturity; Codex has caught up extremely fast in platform breadth, desktop orchestration and multi-surface collaboration. The gap still exists, but it has shifted from a generational gap into a gap between different design orientations.

8. Codex also has workflows, loops and multi-agent

Claude Code's workflow and loop often feel natural: read the task, search the code, form a plan, modify, test, find problems, modify again, until it converges. Codex has the same kind of design; only the official naming and triggers differ.

The main terms Codex uses are:

• Agent loop: the model cycles between observing, acting and verifying.
• Subagents: delegating subtasks to independent agents.
• Subagent workflows: the main agent plans and coordinates several subtasks.
• Multi-agent operations: creating, waiting on, resuming, messaging and closing agents.
• Goal mode: continuously pushing toward a long-term goal rather than completing a single round of Q&A.
• Worktrees: letting different agents modify in parallel inside isolated Git working trees.

Its internal logic runs roughly like this:

Codex's built-in or common agent roles include default, worker and explorer, and it also allows you to define your own agents in user or project config. The main agent can perform operations such as spawn_agent, send_input, wait_agent, resume_agent and close_agent.

One real difference: Claude Code's agent loop tends to feel more like default behavior, while Codex's multi-agent orchestration emphasizes explicit delegation more. If a user explicitly asks to "send two agents to research separately," "one worker per module," or "let the explorer look things up first," you are usually more likely to see Codex's fan-out process.

9. Mainland China now has genuine CLI coding agents

Chinese model vendors did not stop at "offer an API so others can plug it into Claude Code." By 2026, several fully formed CLI coding agents had appeared.

The first tier: already a complete CLI-agent form

The second group: strong models, but the official CLI is not the core product

China's first tier already has roughly sixty to eighty percent of the product form of Claude Code / Codex CLI: it can understand repositories, modify files, run the shell, call MCP, use project rules and execute non-interactive tasks, and it has begun to support subagents, skills and hooks.

The real gap is mainly not in "can it change code," but at a deeper engineering layer: whether long-running tasks are stable, whether the permission model is clear, whether complex tasks keep converging, whether multi-agent is truly controllable, whether worktrees and Git are mature, whether failure recovery is reliable, and whether enterprise auditing and the ecosystem are complete.

A feature list can be matched within a few months; engineering stability and community methodology take time. That, precisely, is the truest distance between Chinese and foreign coding agents today.

10. Kimi K3 is already a top-tier open-weight agent model — but it is not a CLI

Kimi K3 is an open-weight, multimodal model released by Moonshot AI and built for agent tasks. According to the official materials, it uses a sparse MoE architecture with 2.8T total parameters and 104B active parameters (activating 16 of 896 experts per token), supports up to 1M context, and was trained with a heavy focus on code, tool calling, browsing and long-horizon tasks.

It can be used through the Kimi Code CLI. Once inside Kimi Code, a user selects k3 or k3-256k via /model, and can also connect other agent runtimes through an OpenAI-compatible or Anthropic-compatible API.

But it has to be stressed again:

Kimi K3 handles understanding and decision-making; Kimi Code handles reading files, executing commands and modifying code.

This is the same layer relationship as GPT plus Codex, or Claude plus Claude Code.

Roughly what level is K3 at

According to the benchmarks Kimi has officially published, K3 has, across several agentic-coding, Terminal, browsing and computer-operation benchmarks, entered the competitive band of Claude Opus 4.6/4.8 and GPT-5.5, matching or exceeding stronger closed-source models on some items.

For example, in the official table:

The K3 figures in this table are compiled from Moonshot's officially published Kimi K3 benchmarks (technical blog and model page; links in the "Kimi and China's CLI Agents" section at the end), verified on 2026-08-02 — of these, GPQA Diamond 93.5, Terminal-Bench 2.1 88.3 and BrowseComp 91.2 match the official figures. The comparison columns (GPT-5.5, Claude Opus 4.8) are taken from each vendor's own reporting; harnesses and reasoning budgets are not necessarily aligned, so cross-comparisons are for reference only.

These numbers should not be read mechanically as "K3 surpasses Opus across the board." Different models may use different agent harnesses, reasoning budgets, temperatures and tool environments, and self-reported figures should be treated with caution. But they at least establish one thing: K3 is no longer a cheap substitute, but an open-weight model that can go head-to-head with top closed-source models on real coding-agent and long-context tasks.

Measured against early-2025 GPT-4.5, K3 is already clearly stronger, especially in code, Terminal, tool calling, long context and agent workflows. GPT-4.5 was a powerful general chat model of its time, but not the kind of agent model that today's long-chain tool execution is built for.

A more prudent conclusion is:

• K3 clearly exceeds the previous-generation general-model level represented by GPT-4.5.
• On CLI programming and tool tasks, it can be regarded as a strong competitor at the Opus 4.6 level.
• On complex abstract judgment, ultra-long-task stability, expressive quality and safety boundaries, one cannot claim it surpasses Claude Opus across the board.
• For everyday tasks you can prefer k3-256k to control consumption; save the 1M-context k3 for large repositories and very long materials.

11. What OpenCode is: an open-source agent shell, not a model

OpenCode's official definition is "an open-source AI coding agent." Installing it is like installing an agent system that can run in the Terminal, Desktop App or IDE — not downloading a standalone large model.

The things it handles include:

• Scanning and understanding the project directory.
• Reading, searching, writing and modifying files.
• Executing Bash commands and tests.
• Calling LSP, MCP, Web Search and custom tools.
• Managing roles such as build, plan and subagent.
• Controlling whether tool permissions are allow, deny or ask.
• Handing task state, tool results and historical context back to the model to form an agent loop.

Behind OpenCode there still has to be a model provider. Through the AI SDK and Models.dev it supports a large number of cloud and local models, and after installing it a user usually needs to run:

brew install anomalyco/tap/opencode
cd /path/to/project
opencode

Then, inside OpenCode:

/connect   connect a model provider
/models    choose a specific model
/init      initialize project rules, generate AGENTS.md

The model can be Anthropic Claude, OpenAI GPT, Kimi, Qwen, DeepSeek, or a local model such as Ollama. In essence, the configuration is a provider_id/model_id, for example:

{
  "model": "anthropic/claude-sonnet-4-5"
}

So OpenCode's commercial and technical value is not "it owns the strongest model," but that the model is swappable. Connect Claude today, switch to GPT tomorrow, use Kimi for certain tasks, use a local model in an offline environment — and the agent's tools, permissions and project workflow can all be kept.

That is the most fascinating thing about the open-shell route, and also its most real cost: you gain the freedom to choose, and at the same time you have to handle the APIs, model differences, context costs, permissions and compatibility yourself.

12. OpenCode cannot legitimately reuse Claude Pro/Max subscription OAuth

This is the easiest trap in using OpenCode, and the point that most needs to be spelled out.

The official Claude Code CLI supports Claude Pro, Max, Team and Enterprise subscribers logging in via OAuth through /login. But the purpose of that authorization is for the user to use Claude Code inside Anthropic's own applications.

Anthropic's official legal and compliance notes state clearly: Claude's subscription OAuth credentials are meant for native Anthropic applications; third-party developers and products should not offer a Claude.ai login, nor relay a user's Free, Pro or Max credentials. Third-party integrations should use a Claude Console API Key, or connect through a supported cloud provider.

OpenCode's official and community record has also made this explicit: an OAuth plugin that let OpenCode reuse a Claude Pro/Max subscription used to exist, but Anthropic explicitly prohibits this method; in March 2026, at the request of Anthropic's legal team, OpenCode removed the built-in Claude-subscription OAuth plugin and the related system prompt.

So the currently stable, compliant ways to connect are:

• Use an API Key created in the Anthropic Console.
• Go through officially supported channels such as Amazon Bedrock or Google Vertex AI.
• Use a third-party API provider such as OpenRouter or Vercel AI Gateway — but accept their pricing, privacy and availability terms.
• If you only want to consume a Claude Pro/Max subscription, use Anthropic's official Claude Code CLI.

A typical configuration flow inside OpenCode is:

launch opencode
  ↓
/connect
  ↓
choose Anthropic
  ↓
enter the Anthropic Console API Key
  ↓
/models to choose a Claude model

You may still be able to find third-party OAuth plugins, old tutorials or workarounds online. "It works for now" does not mean it is compliant, nor that it is stable in the long run. Anthropic has the right to restrict such credentials, and the user also bears the risk of account risk-control and sudden failure.

In one sentence: a Claude Code subscription is a consumption right for the official client; an Anthropic API Key is the proper pass for third-party agents.

13. How to choose: don't ask who is strongest first — ask which layer your task belongs to

Facing Codex, Claude Code, OpenCode, Kimi Code and Qwen Code, the most practical way to choose is not to hunt for a leaderboard that is forever number one, but to look at your own task and constraints.

You can also use a plainer decision chain:

1. If there's an API, use the API first.
2. If there's a CLI, prefer the CLI.
3. If there's a structured file format, read and write the files directly.
4. Only when there's just a GUI, use Computer Use.
5. Only when a task can be split with clear boundaries, dispatch multiple agents.
6. The pricier the model and the longer the context, the more you must curb useless screenshots, repeated logs and boundless exploration.

The tech world loves to show off that "AI can already operate a computer by itself," but what really determines productivity has never been how many times it clicks the mouse — it is whether it can choose the right tool, keep clear boundaries, verify real results, and keep converging after a failure.

Closing: large models are shifting from talking well to getting things done

We used to judge a model by how much it knew, how well it wrote, how high it scored on exams. Now we judge an agent by whether it can enter a real environment, understand a project, call tools, manage permissions, split tasks, catch errors, keep correcting, and finally deliver a result that can be verified.

This is a migration from "language intelligence" to "action intelligence."

Claude Code was first to prove that the Terminal can become a large model's workplace; Codex, at breakneck speed, extended that capability to the App, the cloud, the SDK, worktrees and multi-agent; OpenCode open-sourced the shell so that the model becomes a swappable brain; and Kimi, Qwen, Tencent and ByteDance proved that Chinese vendors are no longer content to offer only a model API — they are contesting the agent runtime, the CLI entry point and the developer workflow.

In the end, what will truly hold value is not that some model leads by three points more on some given day, but who can build a working discipline that is stable, controllable, portable and verifiable. Models will be swapped, prices will fall, leaderboards will change, and subscription policies may even tighten overnight; but project rules, tool systems, knowledge assets, permission boundaries and workflows can remain.

Brains will only grow more plentiful. What is truly scarce is the body, the order — the capacity to make intelligence get things done, again and again.

Perhaps that is where the CLI-agent revolution truly begins.

Official resources and further reading

OpenAI Codex

• Introducing Codex
• Codex is now generally available
• Introducing the Codex app
• Codex Hooks
• Git worktrees
• Subagents
• Computer Use
• GPT-5.5 model documentation
• GPT-5-Codex model documentation

Claude and Anthropic

• Claude Code authentication
• Claude Code legal and compliance
• Claude API authentication

OpenCode

• OpenCode GitHub repository
• OpenCode documentation
• OpenCode providers
• OpenCode models
• OpenCode agents
• OpenCode tools

Kimi and China's CLI Agents

• Kimi K3 GitHub repository
• Kimi K3 official technical blog (with benchmark data)
• moonshotai/Kimi-K3 · Hugging Face (open weights and model card)
• Kimi Code models
• Kimi Code GitHub repository
• Qwen Code GitHub repository
• Qwen3-Coder introduction
• Trae Agent GitHub repository
• Tencent CodeBuddy CLI documentation
• DeepSeek agent integrations