10 Billion Tokens in Practice: An In-Depth Review of Codex's Long-Horizon Engineering Capabilities

A Real-World Desktop Application Migration Experiment

Over the past 30 days, content creator Ajiang burned through approximately 10 billion Tokens in Codex. But what actually motivated him to make this video wasn't showing off Token consumption — it was a genuine engineering exercise. He used Codex to complete an architectural migration of an open-source desktop application.

The project is called cc-haha, an open-source desktop application he built by modifying Claude Code's source code with a deep focus on UI. It features built-in Session management, Worktree, permission management, Computer Use, and AI-related functionalities. The migration goal was crystal clear: move the project from a Tauri 2 + Rust desktop architecture to Electron + TypeScript.

To appreciate the scale of this migration, you first need to understand the fundamental differences between the two architectures. Tauri is a next-generation desktop framework built on Rust, with a core design philosophy of "zero redundancy" — it doesn't bundle its own browser engine. Instead, it directly calls the operating system's native WebView components (WKWebView on macOS, WebView2 on Windows) to render the frontend interface, while the Rust layer handles native system calls. The two communicate through strictly typed command interfaces (Commands) for IPC. The direct result is an extremely small application footprint — typically just a few MB after packaging — with significantly lower memory usage than competitors. Notably, Tauri's reliance on OS-built-in WebView components means subtle rendering differences may appear across platforms — WKWebView on macOS and WebView2 on Windows don't support CSS features identically. This is the fundamental reason why Tauri applications require extra testing effort for cross-platform UI consistency.

Rust was released by Mozilla Research in 2010, with version 1.0 arriving in 2015. Its distinguishing feature is the Ownership system — the compiler performs all memory safety checks at compile time rather than runtime, fundamentally eliminating classic C/C++ vulnerabilities like null pointer dereferences, data races, and memory leaks, all without garbage collection (GC), achieving performance close to C. Tauri leverages this characteristic to encapsulate system-level operations as a safe Rust backend. However, for developers with a frontend background, Rust's core concepts — Ownership, Borrow Checker, and Lifetimes — often present a steep learning curve. The logic behind this memory safety model is: traditional languages either rely on developers to manually manage memory (C/C++, flexible but dangerous) or introduce a garbage collector (Java/Go/JavaScript, safe but with runtime overhead). Rust achieves "zero-cost abstractions" by statically verifying resource acquisition and release rules at compile time — safety without sacrificing performance. This philosophy has driven Rust's widespread adoption in domains demanding both high performance and safety, such as operating systems, WebAssembly, and embedded systems. Tauri chose Rust as its backend precisely for this reason.

Electron is a veteran solution launched by GitHub in 2013. Under the hood, it bundles a complete Chromium browser engine and Node.js runtime into the application, using TypeScript/JavaScript for development. This choice makes it a natural fit for the web developer ecosystem — VS Code, Slack, Discord, and the Figma desktop app are all built on it, with an extremely mature toolchain, community documentation, and third-party library ecosystem. The fundamental reason for Electron's large application size is that it packages a full Chromium instance (~100MB+) and Node.js runtime into every application. Each app instance effectively runs an independent browser process — even a simple Hello World app can exceed 100MB after packaging, and running multiple Electron apps simultaneously results in significant memory consumption. While the community has proposed optimizations like ASAR packaging compression and tree-shaking, this structural disadvantage persists compared to Tauri. In recent years, Tauri's challenger status has grown — Tauri 1.0 released in 2022 and the subsequent Tauri 2.0 (adding mobile support) at one point exceeded Electron in GitHub Stars growth rate, reflecting developers' ongoing interest in lightweight applications and memory efficiency. However, Electron's massive ecosystem and enterprise case studies make its position difficult to displace in the short term.

The migration between these two architectures far exceeds the complexity of ordinary code refactoring: Tauri's Rust Commands need to be rewritten one by one into Electron's ipcMain/ipcRenderer messaging mechanism; native file system operations, system tray management, global shortcut key registration, and inter-process communication APIs work completely differently; the system permission model also shifts from Rust's type-safe system to Node.js's dynamic runtime. This was a comprehensive rewrite of the underlying language, runtime, and native API calling system.

The entire task ran continuously on Codex for over 20 hours without stopping. It independently analyzed the project, built the desktop APP, opened the interface to find issues, and went back to modify the code. The resulting cc-haha 0.4.0 version is now live. While it couldn't complete 100% of the migration, it pushed through the vast majority of the work — the remaining small portion only needed human collaboration with external environment verification.

The Key Isn't Writing Code — It's "Long-Horizon Engineering Capability"

Ajiang repeatedly emphasized that the truly interesting aspect isn't how much code Codex wrote for him, but its outstanding long-horizon performance in real engineering work.

This point deserves elaboration. Previously, when evaluating AI programming tools, we tended to focus on "the quality of a single code generation." But a real engineering migration is a complex, continuous task: it requires understanding the existing architecture, progressively rewriting code, compile-time verification, running tests, discovering issues, and going back to fix them — a cycle that needs to be sustained for hours or even tens of hours. The ability to maintain stable progress in such long-horizon tasks is the true dividing line for current Agent capabilities.

Long-horizon tasks are one of the most critical capability boundaries in the current AI Agent field, with challenges coming from multiple dimensions. From an architectural perspective, the Transformer's self-attention mechanism has computational complexity that grows quadratically with sequence length, limited in practice by GPU memory capacity. Although the Claude series supports a 200K Token context window and GPT-4 has extended to 128K, research shows that even with sufficiently large context windows, models pay significantly less attention to information in the middle of a sequence compared to the beginning and end — this "Lost in the Middle" phenomenon is a key mechanism behind the so-called "Context Drift" in long-horizon tasks, manifesting as the model silently introducing new bugs while fixing one, or making decisions that contradict initial requirements.

Next-generation Agent tools (such as OpenAI's Codex and Anthropic's Claude Code) systematically address this challenge through multiple mechanisms: Persistent Memory (writing key decisions and current progress to external files rather than relying solely on the volatile context window); Tool Call Chaining (decomposing complex tasks into independently verifiable atomic operation sequences); Self-correction Loops (execute → observe results → judge whether they match expectations → rollback and retry if necessary). Together, these mechanisms form the technical foundation for Agents to maintain coherent "working memory" during long-horizon tasks. This design draws from classic software engineering concepts of "Checkpoints" and "Transaction Rollback," migrating them into the AI reasoning process — after completing each milestone, key state is serialized to persistent storage, so if subsequent steps fail, the system can recover from the nearest checkpoint rather than starting over. This is the underlying guarantee that enabled the 20-hour uninterrupted task to complete stably.

On the evaluation front, SWE-bench is currently the most authoritative benchmark for long-horizon coding capability. Published in 2023 by Carlos E. Jimenez and other researchers at Princeton University, it contains 2,294 Issue-PR paired samples from 12 real Python open-source repositories including Django, Flask, and Pytest. It requires models to locate and fix actual bugs in real GitHub repositories based on Issue descriptions — tasks that on average span dozens of files and involve hundreds of lines of code changes. SWE-bench is considered a proxy for "real engineering capability" because its tasks cannot be solved by memorizing training set answers — each Issue fix requires the model to genuinely understand the codebase's architectural intent, trace cross-file dependencies, and generate patches that pass the original test suite. Notably, by early 2025, top Agent systems achieved over 50% resolution rates on SWE-bench Verified (the human-filtered version), compared to less than 5% for the best systems in early 2023 — the pace of this capability leap directly corresponds to real-world challenges like "20-hour uninterrupted architecture migration" and is one of the most compelling metrics for measuring an Agent's practical engineering value.

Driven by "Goal Mode," Not Line-by-Line Instructions

The most critical approach during the migration was using Goal mode in Codex. Ajiang didn't instruct the AI to write code sentence by sentence. Instead, he gave it a clear goal: migrate cc-haha from Architecture A to Architecture B.

But simply stating a goal isn't enough. He specifically emphasized — you must also tell it how to verify completion:

• Can it Build successfully?
• Can it launch the APP?
• Can key pages open properly?
• What parts should not be arbitrarily changed?
• What parts must be left for manual testing?

In his words, the value of setting clear goals isn't making the AI instantly smarter, but rather "turning a complex task into a workflow that can be executed, provide feedback, and be verified." This methodology aligns closely with the software engineering concept of "Design by Contract" — clearly defining preconditions (current state), postconditions (acceptance criteria), and invariants (constraints that must not be violated). Only within this boundary framework can the AI's autonomous actions produce predictable results. This is equally important for everyday users: you don't need to understand every technical detail, but you should at least learn how to define a goal and how to define "what 'done' looks like."

Computer Use: Giving the Model Eyes and Hands

In this project, one of the Codex features Ajiang valued most was Computer Use. He described it aptly: it doesn't give the model more text — it gives the model "a pair of eyes and a pair of hands."

Computer Use is a revolutionary capability first introduced by Anthropic in October 2024 with the Claude 3.5 Sonnet update, subsequently adopted by OpenAI, Google, and other providers, gradually becoming a standard feature of next-generation Agent tools. The core principle is: screenshots are captured at a fixed frequency (typically 1-2fps in practice, balancing Token cost with responsiveness) and passed as visual input to a multimodal large model. The model uses visual understanding to identify the position, type, and current state of UI elements, then outputs standardized JSON-format action instructions (such as mouse coordinate clicks, keyboard input, scrolling). A local execution layer (using libraries like pyautogui or xdotool) converts these instructions into real operating system input events, forming a complete loop of "screenshot observation → visual understanding → action decision → execution feedback." Some implementations use relative coordinates (percentages) instead of absolute pixel coordinates to adapt to different screen resolutions and reduce click offset issues. This architecture relies on the spatial understanding capabilities of Vision Language Models (VLMs) — the model must not only recognize "there's a button here" but understand its semantics ("this is a confirm button; clicking it will trigger a submission") and continuously maintain correct expectations about interface state changes across multi-step task chains, demanding visual reasoning capabilities far beyond simple image classification.

This differs fundamentally from traditional UI automation testing tools. Selenium relies on the DOM tree structure exposed by browsers, and Playwright relies on element selectors (CSS Selectors or XPath) — both require the target software to provide a programmatically accessible interface layer. Computer Use directly understands interface state by "looking" — theoretically capable of operating any visual software, including native desktop applications with no open APIs, legacy enterprise systems, and even rich media interfaces rendered entirely with Canvas. In desktop development and debugging scenarios, this means AI can discover bugs at a purely visual level — white screens, layout misalignment, broken buttons, loading timeouts — just like a real user, without developers needing to pre-embed additional test hooks or logging probes in the code. The strategic significance of this capability lies in dramatically reducing the "last mile" cost of automation test coverage — traditional end-to-end testing (E2E Testing) has extremely high maintenance costs, where any structural UI change can break selectors and cause batch test script failures. Computer Use's visual perception approach is significantly more robust against UI refactoring.

Computer Use still has clear capability boundaries: pixel-precise operations (such as dragging fine sliders or precisely clicking specific cells in dense tables) depend on screenshot resolution and the model's spatial positioning accuracy, with significant error margins; state understanding of high-refresh-rate dynamic interfaces (such as real-time data charts or video playback) suffers from temporal lag; complex gesture operations (multi-touch, rapid sequential clicks) also exceed the stable support range of mainstream implementations. Understanding these boundaries rationally is a prerequisite for properly planning the division between "AI takeover" and "human fallback."

Previously, AI models could at most run tests and read logs. But did the desktop APP actually open? Is there a white screen? Are buttons misaligned? These visual-level issues used to require human eyes and feedback.

With Codex's Computer Use, the model can observe pages itself, judge whether the interface is correct, and go back to modify code. This takes over a portion of the work that previously required repeated manual verification.

However, Ajiang also drew clear boundaries: Note — it takes over "a portion," not everything. Some interaction experiences and functional decisions still require human judgment. Over-glorifying AI's automation capabilities actually introduces risk.

The Toolchain Is the Core, Not Any Single Star Product

Ajiang has a clear-headed assessment of Codex: there's no need to mythologize it. It and the previously viral Claude Code are fundamentally the same category of tool. The real core is how to build your own toolchain that enables AI to work continuously and stably in an Agent environment.

He also shared the plugins and skills he uses most often:

• Brainstorming phase: Super Powers is used the most
• UI design: Recently using DesignPaste frequently
• Video editing: Uses HyperFriends and WebVideo
• Plus some private skills he has accumulated over time

He encourages everyone to use AI to search for plugins and skills suited to their own industry and role — there are vast amounts of developers continuously open-sourcing their practical experience and tools on GitHub.

The Cost Breakdown: $200/Month Subscription vs. $10,000+ in API Calls

On costs, Ajiang provided specific numbers. Over 30 days, he consumed approximately 11 billion Tokens. He subscribes to the Pro 20X tier at $200/month, which he considers "fine, not expensive."

For comparison, if those 11 billion Tokens were billed individually via API, the cost would have exceeded $10,000 — the cost-effectiveness advantage of subscription pricing for heavy usage scenarios is immediately apparent.

This pricing inversion isn't accidental — it's a deliberate business strategy by OpenAI with clear economic logic. Taking GPT-4o as an example, input Tokens cost approximately $0.5–2.5 per million, and output Tokens approximately $1.5–10 per million. Agents generate large volumes of intermediate reasoning steps during task execution, which are billed as output Tokens at higher rates — the theoretical cost of 11 billion Tokens even at the best price tier easily exceeds $5,000, and when reasoning steps account for a high proportion, breaking $10,000 is not far-fetched.

The business logic of subscription pricing is a variant of "Price Discrimination" in economics — locking in high-frequency users with fixed monthly fees while covering low-frequency users with pay-per-use billing, maximizing revenue across different consumer segments. More importantly, Pro subscriptions carry strategic value: heavy users tend to be developers, creators, and enterprise decision-makers — key opinion leaders whose public sharing (like Ajiang's video) generates word-of-mouth and demonstration effects that far exceed the direct revenue contribution of the monthly fee. This is the core logic behind OpenAI's willingness to absorb marginal losses on individual heavy users — essentially trading current-period profit for a growth flywheel of market share and user scale. From a broader perspective, this strategy is highly consistent with early cloud computing providers (AWS, Azure) offering generous free tiers to developers: first create deep dependency among key user groups, then realize long-term commercial value through platform stickiness and ecosystem effects. For light users with relatively low monthly Token consumption, pay-per-use API billing is actually more economical — it's recommended to estimate your actual monthly Token consumption before choosing, and make a rational comparison based on that.

For users who still find the subscription too expensive, he offered an alternative: use Codex with CC-switch to connect to various Chinese domestic models, including DeepSeek, Zhipu, Tongyi Qianwen, MiniMax, Kimi, and others. It's essentially plug-and-play, with very detailed documentation for CC-switch and a low barrier to entry.

CC-switch is an open-source model routing middleware whose core function is to standardize and convert API request formats from tools like Claude Code and forward them to other model services compatible with the OpenAI API specification, enabling "one tool interface, free switching between multiple model backends." This ecosystem exists fundamentally because the OpenAI API specification (especially the Chat Completions interface and Function Calling format) has become the de facto industry standard. The formation of this standard follows a path similar to HTTP, SQL, and other standards throughout history: the first mover establishes interface specifications through market dominance, and followers actively comply to reduce developer migration costs, spawning a thriving ecosystem of unified proxy layer tools like LiteLLM and One-API. Currently, Anthropic Claude, Google Gemini, Meta LLaMA series mainstream deployment platforms, and virtually all major Chinese large models provide OpenAI-compatible interfaces, significantly reducing the engineering cost of ecosystem interoperability. This "standards compatibility" strategy is not uncommon in tech history: Android's reuse of the Linux kernel, various databases' compliance with SQL standards, and browser vendors' implementation of W3C specifications are all essentially "building competitive differentiation on established standards" rather than creating new ones from scratch — in the AI API domain, the OpenAI specification plays a role similar to the TCP/IP protocol in the networking world.

On the capability and pricing dimensions, different Chinese domestic models have their own strengths: DeepSeek-V3/R1, with code understanding and generation capabilities approaching GPT-4 level and extremely competitive API pricing (less than 1/10 of OpenAI models with comparable capabilities on some tasks), has rapidly gained widespread adoption among developers; Moonshot Kimi and MiniMax have unique advantages in ultra-long context processing (supporting 128K or even longer Token windows), making them suitable for scenarios requiring one-time input of large-scale codebases; Zhipu GLM and Tongyi Qianwen excel in Chinese understanding and Chinese document generation. For developers with limited budgets who want to experience Agent workflows, CC-switch provides a viable path to achieving a near-Agent experience at far lower cost than an OpenAI subscription.

Three Pieces of Advice for Everyday People

At the end of the video, Ajiang distilled his insights into three things truly worth doing for ordinary people — he believes what you should learn is definitely not prompt template recipes, nor chasing every new tool name:

1. Make your goals crystal clear: You should at least be very clear about what you want to accomplish.
2. Define your acceptance criteria: Let the AI know "what does it look like when this feature is properly built."
3. Don't blindly trust the AI when it says 'done' — demand evidence: For example, during remote development, have it provide screenshots to confirm it actually performed those operations.

The core message boils down to one sentence: Can you articulate your task clearly and define what "completion" looks like?

In this era of exploding AI tools, his final emphasis is — no amount of talk matters. The tools and resources are all out there. The key is to take action. This is perhaps the most down-to-earth, yet most valuable conclusion behind this "10 billion Token" experiment.

Key Takeaways