# Claude Code và Codex: đo thật chi phí và hiệu năng

[Nathan Sebhastian](https://homus.dev/speakers/nathan-sebhastian) · [Nathan Sebhastian](https://homus.dev/orgs/nathan-sebhastian)

> Năm bài test code thật, ba tầng model mỗi bên, 30 lượt chạy: so thời gian, token, chi phí và cách Claude Code với Codex làm việc.

Topics: Coding Agents, Dev Tools, Evals

Canonical: https://homus.dev/talks/claude-code-vs-codex-real-cost-performance-test-2026

## 1. Câu hỏi của video: năm bài test, ba tầng model, 30 lượt chạy

Nathan Sebhastian mở đầu bằng một câu hỏi: Claude Code hay Codex, nên dùng cái nào hằng ngày? Để trả lời, anh đưa cho cả hai đúng cùng năm bài test về code:

- giải thích một codebase open source thật mà chúng chưa từng thấy;

- build một app đầy đủ từ con số không;

- tách một file khoảng 5.600 dòng mà không làm hỏng gì;

- sửa một bug do người dùng báo lên;

- và cuối cùng là review một pull request có bug nằm sẵn bên trong.

![Slide Five real coding tasks liệt kê năm bài test: explain, build, refactor, bugfix, review](https://homus.dev/photos/qcEkQEZdEyM-0023.jpg)

Slide "Five real coding tasks" trong video đăng ngày 28/10/2026: năm bài test Nathan dùng cho cả Claude Code và Codex, từ giải thích codebase tới review pull request.

Anh cũng thu số liệu cho từng bài: mỗi lượt chạy mất bao lâu, và tiêu tốn bao nhiêu token. Anh không chỉ chạy các model flagship mà chạy ba tầng từ mỗi bên: Haiku đấu với Luna, Sonnet đấu với Terra, và Opus đấu với Sol. Tổng cộng là 30 lượt chạy, và mọi lượt đều được chấm bằng những bài test ẩn mà các model không bao giờ được thấy (theo cách Nathan dựng bài test, video đăng ngày 28/10/2026).

Thứ tự của video: trước hết là vì sao các benchmark không giải quyết được câu hỏi này, rồi một phần tổng quan nhanh về hai công cụ, giá thật và usage limit, sau đó là cả năm bài test để thấy chúng chạy ra sao ngoài đời thật. Cuối video, theo Nathan (video đăng ngày 28/10/2026), bạn sẽ biết Codex và Claude Code khác nhau ở đâu, và cái nào đáng tiền nếu bạn định mua subscription AI.

## 2. Vấn đề thứ nhất: benchmark chính thức là bài tự chấm

Trước khi xem số, Nathan giải thích vì sao phần lớn các bài so sánh mà bạn từng xem đang test sai thứ. Theo anh, benchmark có ba vấn đề.

Vấn đề thứ nhất, theo Nathan (video đăng ngày 28/10/2026): benchmark chính thức được chọn lọc (cherry-picked). Cả hai công ty đều công bố biểu đồ ở mỗi lần ra mắt, và bằng cách nào đó, biểu đồ của bên nào cũng cho thấy model của chính bên đó thắng. Anh gọi đó là tự chấm bài của mình (marking their own homework).

Ví dụ đầu tiên anh đưa ra là biểu đồ ra mắt GPT-6 Astra. Theo Nathan (video đăng ngày 28/10/2026), biểu đồ đó cho thấy Astra có accuracy tốt hơn và chi phí API thấp hơn các model mới nhất ở thời điểm ra mắt. Trên slide tóm tắt của anh ghi: Astra dẫn Fable và rẻ hơn khi chạy, Terminal-Bench 4.0 là 57,9% so với 55,8%, và rẻ hơn Fable 5.1 khoảng 63%.

Tiếp theo là lần ra mắt Opus 5.5. Lần này Opus lại dẫn Astra: 66,4% so với 57,9% trên Terminal-Bench, và 54,4% so với 53,3% trên FrontierCode. Anthropic cũng nói Opus làm việc đó rẻ hơn, thắng Astra trên FrontierCode với khoảng một phần năm chi phí cho mỗi task (slide ghi "khoảng 20% chi phí mỗi task"). Các con số này là số do hai hãng công bố lúc ra mắt, theo video đăng ngày 28/10/2026.

Hai biểu đồ ra mắt mà Nathan đặt cạnh nhau (số do hai hãng công bố, theo slide trong video đăng ngày 28/10/2026): cùng Terminal-Bench, cùng 57,9% cho Astra, nhưng mỗi bên một người thắng.

Vậy là cả hai công ty đều nói mình tốt hơn và rẻ hơn. Và nếu đọc phần chú thích nhỏ (footnote), các con số Terminal-Bench đang so Opus ở mức effort extra high với Astra ở mức effort high. Cùng một benchmark, nhưng khác thiết lập. Theo Nathan (video đăng ngày 28/10/2026), các benchmark độc lập kể một câu chuyện điềm tĩnh hơn nhiều.

## 3. Benchmark độc lập: Senior SWE-bench và Tasteful Solve

Một trong những benchmark độc lập tốt nhất, theo Nathan (video đăng ngày 28/10/2026), là Senior SWE-bench. Lý do anh đưa ra: ngoài việc kiểm tra code có pass test hay không, nó còn có một chỉ số tên là Tasteful Solve, chỉ số này kiểm tra xem lời giải có thật sự là code tốt, chất lượng cao hay không.

Trên bảng này, theo số trong video đăng ngày 28/10/2026, Opus 5.5 đứng đầu với Tasteful Solve rate 39,3%, Astra theo sát ngay sau với 36,8%. Hai bên chỉ cách nhau 2,5 điểm. Ở solve rate cơ bản (basic), khoảng cách còn nhỏ hơn: 61,8% so với 60%.

![Bảng Senior SWE-bench: Opus 5.5, GPT-6 Astra, Fable 5.1, Fable 5, Opus 5, GPT-5.6 Sol với effort, tasteful, basic và avg tokens](https://homus.dev/photos/qcEkQEZdEyM-0228.jpg)

Slide "The top two are 2.5 points apart" trong video đăng ngày 28/10/2026, nguồn ghi là leaderboard Senior SWE-bench của Snorkel, 100 task: Opus 5.5 dẫn 2,5 điểm nhưng dùng gấp 2,2 lần token; bốn model hoà đúng 34,7%.

Và dù Opus nhỉnh hơn một chút, nó cũng dùng nhiều hơn gấp đôi số token: trung bình 41.000 token mỗi task, so với 19.000 của Astra (số trên bảng là 41,3K và 19,0K, video đăng ngày 28/10/2026). Ngay bên dưới hai model này là bốn model hoà nhau đúng 34,7%: Fable 5.1, Fable 5, Opus 5 và GPT-5.6 Sol.

Benchmark này dùng 100 task, nên vài điểm phần trăm không nói lên nhiều. Theo Nathan (video đăng ngày 28/10/2026), ở mức này các model flagship về cơ bản là ngang nhau, và kết quả phụ thuộc vào cách setup, vào instruction và vào đúng những task được chọn nhiều hơn là vào model.

## 4. Vấn đề thứ hai và thứ ba: harness và mức effort

Vấn đề thứ hai, theo Nathan (video đăng ngày 28/10/2026): benchmark test model, còn thứ bạn thật sự dùng là một công cụ. Claude Code và Codex là thứ người ta gọi là agentic harness. Nathan dùng một hình ảnh: hãy coi model là động cơ, còn harness là chiếc xe. Harness quyết định model nhìn thấy gì, được dùng tool nào, sửa file ra sao, và khi nào chạy test.

Theo Nathan (video đăng ngày 28/10/2026), một model rất giỏi đặt trong một harness yếu có thể thua một model kém hơn một chút nhưng có harness tốt hơn.

Hình ảnh động cơ và chiếc xe mà Nathan dùng trong video đăng ngày 28/10/2026: benchmark đo động cơ, còn bạn lái cả chiếc xe.

Vấn đề thứ ba: benchmark chạy ở mức effort high hoặc max. Nhìn lại leaderboard, Opus và Astra đều chạy ở high effort, còn phần lớn các model khác chạy ở extra high hoặc max. Theo Nathan (video đăng ngày 28/10/2026), đó thật sự không phải cách bạn làm việc hằng ngày: chạy model mạnh nhất ở mức reasoning max cả ngày thì bạn sẽ đốt hết usage chỉ trong một giờ.

Theo Nathan (video đăng ngày 28/10/2026), phần lớn mọi người giữ thiết lập mặc định. Vì vậy, thay vì tin biểu đồ của người khác, Nathan test hai công cụ theo đúng cách người ta thật sự dùng chúng.

## 5. Hai công cụ: CLI, open source và bộ model

Trước hết, anh xem bạn thật sự đang chọn giữa những gì. Trong video này, Nathan chỉ dùng bản CLI, vì theo anh (video đăng ngày 28/10/2026) đó là phiên bản thiên về developer nhất của cả hai, và là cách dễ nhất để giao cho hai công cụ đúng cùng một việc.

Khác biệt đầu tiên, theo Nathan (video đăng ngày 28/10/2026): Codex CLI là open source theo license Apache 2.0, nên bạn có thể đọc code, sửa và dùng theo cách bạn muốn. Claude Code thì ngược lại, không được phát hành theo license open source, và code của nó là private. Trên GitHub, theo số anh nói trong video, Claude Code có khoảng 150.000 star và Codex khoảng 130.000 star; cả hai đều rất phổ biến. (Trang repo `openai/codex` ghi license Apache-2.0 và 131,6k star, đọc ngày 29/10/2026.)

Về tính năng, theo Nathan (video đăng ngày 28/10/2026), một năm trước mỗi công cụ có những thứ mà bên kia không có. Đến lúc quay video thì chúng về cơ bản đã hội tụ: skill, hook, project rule, sub-agent, MCP server, cả hai đều có đủ. Bạn không còn chọn theo tính năng nữa; thay vào đó, bạn đang chọn harness và model.

Bộ model, theo video đăng ngày 28/10/2026: phía OpenAI có Astra ở trên cùng, rồi Sol là flagship mà phần lớn mọi người dùng, Terra ở giữa, và Luna rất nhanh, rất rẻ. Phía Anthropic có Fable ở trên cùng, rồi Opus, Sonnet, và Haiku.

![Bảng The lineup: bốn tầng Frontier, Flagship, Mid, Small của Claude Code và Codex](https://homus.dev/photos/qcEkQEZdEyM-0519.jpg)

Slide "Three tiers tested, all at medium effort" (video đăng ngày 28/10/2026): Frontier là Fable 5.1 và GPT-6 Astra, Flagship là Opus 5.5 và GPT-6.1 Sol, Mid là Sonnet 5.5 và GPT-6.1 Terra, Small là Haiku 5.5 và GPT-6 Luna. Dòng dưới ghi medium là mặc định mà phần lớn mọi người thật sự chạy.

Theo Nathan (video đăng ngày 28/10/2026), Astra và Fable mạnh nhất nhưng cũng chậm nhất và đắt nhất, và không phải thứ phần lớn mọi người chạy hằng ngày. Vì vậy anh để hai model này ra ngoài phép so sánh, chỉ so ba tầng dùng hằng ngày: Haiku với Luna, Sonnet với Terra, và Opus với Sol.

## 6. Giá API theo từng tầng

Tiếp theo là giá, vì theo Nathan phần này đã thay đổi nhiều trong thời gian gần với lúc quay (video đăng ngày 28/10/2026). Ở phía API, các model nhỏ có giá y hệt nhau: Haiku và Luna đều là 10 cent cho mỗi triệu token input và 50 cent cho mỗi triệu token output. Theo Nathan, có một điểm cần để ý với Haiku: khi một prompt vượt quá 100.000 token, giá của nó tăng lên gấp 5 lần.

Ở các tầng trên, theo video đăng ngày 28/10/2026, Claude đắt đúng gấp đôi. Sonnet là 2 đô input và 10 đô output, so với 1 đô và 5 đô của Terra. Opus là 4 đô input và 20 đô output, so với 2 đô và 10 đô của Sol (tất cả tính trên mỗi triệu token).

![Bảng API pricing per million tokens: Haiku 5.5 và Luna, Sonnet 5.5 và Terra, Opus 5.5 và Sol](https://homus.dev/photos/qcEkQEZdEyM-0603.jpg)

Slide "Claude costs 2x at the mid and top tiers" (video đăng ngày 28/10/2026, nguồn ghi là trang giá chính thức tháng 10/2026): Opus và Sonnet đắt gấp đôi model GPT cùng tầng, model nhỏ bằng giá nhau. Chú thích dưới slide ghi giá Haiku áp cho prompt tới 100K token, giá GPT áp tới 272K.

## 7. Gói subscription và usage limit

Nhưng phần lớn người xem, theo Nathan, nhiều khả năng sẽ dùng subscription chứ không dùng API, và giá vào cửa là 20 đô ở cả hai bên (tính đến video đăng ngày 28/10/2026). Điều đã thay đổi là: gói Claude Pro 20 đô có Opus, Sonnet và Haiku cùng với Claude Code. Phía OpenAI, gói Plus 20 đô cho bạn Sol, Terra và Luna. Vậy với các model flagship dùng hằng ngày, 20 đô cho bạn cùng một tầng ở cả hai bên.

Theo Nathan (video đăng ngày 28/10/2026), các gói khác nhau ở những model trên cùng. Fable chỉ dùng được qua extra usage credit, và các gói Max giới hạn Fable ở một nửa usage hằng tuần của bạn. Ngược lại, Astra có ngay cả trong gói Plus cho Codex và ChatGPT Work. OpenAI còn có gói Go 8 đô chỉ có Luna, và gói Pro giá 100, 200 hoặc 500 đô. Trong khi đó, các gói Max của Claude là 100 đô cho 5 lần usage của Pro, và 200 đô cho 20 lần.

Usage limit là chỗ hai bên thật sự khác nhau (theo video đăng ngày 28/10/2026). OpenAI công bố ước tính cho gói Plus: 15 tới 160 message mỗi 5 giờ với Sol, 35 tới 285 với Terra, và 350 tới 3.000 với Luna. Các gói ChatGPT Pro, ở thời điểm quay video, không có giới hạn 5 giờ.

![Slide Usage limits on the $20 plans: Luna 350-3,000, Terra 35-285, Sol 15-160 messages mỗi 5 giờ, Claude Pro Not public](https://homus.dev/photos/qcEkQEZdEyM-0743.jpg)

Slide "Codex publishes estimates. Claude doesn't." (video đăng ngày 28/10/2026, nguồn ghi là trang giá Codex tháng 10/2026): số message ước tính mỗi 5 giờ của gói Plus, còn Claude Pro ghi "Not public", có cửa sổ 5 giờ và giới hạn theo tuần.

Phía Anthropic thì không công bố con số (tính đến video đăng ngày 28/10/2026): bạn có một cửa sổ 5 giờ cộng một giới hạn theo tuần, và Claude Code dùng chung một pool với các cuộc chat Claude thông thường. Vì vậy một cuộc chat dài trên website Claude cũng ăn vào quota code của bạn. (Trang giá của Claude ghi Claude Code dùng chung usage limit với phần còn lại của gói, nên việc trong terminal và các cuộc chat lấy từ một pool, đọc ngày 29/10/2026.)

Cảm nhận cá nhân của Nathan (video đăng ngày 28/10/2026): các gói 20 đô cho khối lượng công việc gần như bằng nhau, nhất là khi bạn giữ thiết lập reasoning mặc định với Opus hoặc Sol.

Slide về gói subscription trong video còn ghi thêm (tính đến 10/2026): Claude Free không có Claude Code, gói Pro là 20 đô (17 đô nếu trả theo năm); ChatGPT Free có Luna. Dòng nguồn ghi usage của Claude dùng chung với các app Claude, còn Codex được tính riêng.

## 8. Cách dựng benchmark: medium effort, headless, test ẩn

Nathan dành một chút cho phần setup, vì nó ảnh hưởng tới cách đọc kết quả.

Thứ nhất (video đăng ngày 28/10/2026), mọi model đều chạy ở medium effort, thiết lập dùng hằng ngày, không phải mức max effort mà phần lớn các bài so sánh dùng.

Thứ hai (video đăng ngày 28/10/2026), anh không ngồi prompt từng model bằng tay. Anh viết một benchmark runner nhỏ, tạo một folder mới cho mỗi lượt chạy. Nó đưa đúng cùng một prompt cho mỗi CLI ở chế độ headless, ghi lại thời gian và số token, rồi chấm kết quả bằng những test mà model không bao giờ thấy.

Theo Nathan (video đăng ngày 28/10/2026), cách này làm bài test khách quan hơn, vì model hoặc pass test ẩn, hoặc không. Bench được chạy bằng Python, và nó tóm tắt kết quả ở cuối.

![VS Code mở project agent-bench với file models.toml và terminal chạy python3 bench.py setup](https://homus.dev/photos/qcEkQEZdEyM-0823.jpg)

Project `agent-bench` trong VS Code (video đăng ngày 28/10/2026): file `models.toml` ghép từng cặp model theo tầng, terminal chạy `python3 bench.py setup` kiểm tra hai CLI (claude 2.1.311, codex-cli 0.164.0), tải source repo cho bài explain và refactor, rồi báo sẵn sàng.

Phần ghép cặp và cấu hình một model trong `models.toml` trên màn hình:

```
[pairs]
small = ["claude-haiku", "codex-luna"]
mid = ["claude-sonnet", "codex-terra"]
flagship = ["claude-opus", "codex-sol"]

[models.claude-haiku]
cli = "claude"
label = "Haiku 5.5"
model = "haiku"
effort = "medium"
```

## 9. Task 1: giải thích một codebase chưa từng thấy

Bài test đầu tiên (demo trong video đăng ngày 28/10/2026) là giải thích một codebase với rất ít thông tin đi kèm. Nathan chỉ đưa cho model source code: không README, không docs, không git history. Anh cũng dặn model không được tra cứu gì trên mạng, chỉ đọc code của thư viện Python này (trên màn hình, các câu hỏi xoay quanh thư viện `huey`) và xem model hiểu được tới đâu.

Theo cách Nathan đặt bài (video đăng ngày 28/10/2026), thay vì hỏi "giải thích codebase này" rồi chấm một bài luận, anh hỏi những câu kiểu "chuyện gì thật sự xảy ra nếu…". Những câu này chỉ trả lời được bằng cách lần theo code (tracing).

Ví dụ: một task có ba lần retry và lần nào cũng fail, và nó có gắn một error handler. Error handler chạy bao nhiêu lần? Theo Nathan (video đăng ngày 28/10/2026), phần lớn mọi người sẽ nói một lần, nhưng đáp án thật là bốn lần, vì thư viện thực sự gọi handler ở mỗi lần thử thất bại chứ không chỉ lần cuối. Bạn chỉ biết điều đó nếu thật sự lần theo code.

Trong demo (video đăng ngày 28/10/2026), model ghi câu trả lời vào một file JSON, và Nathan đối chiếu với một answer key đã được kiểm chứng.

![Bảng Task 1: score, time và doc lines của sáu model](https://homus.dev/photos/qcEkQEZdEyM-1023.jpg)

Kết quả Task 1 theo số đo của Nathan (video đăng ngày 28/10/2026): năm model đạt 10/10, GPT-6 Luna 9/10; GPT-6.1 Terra nhanh nhất với 58 giây và 68 dòng giải thích, Haiku 5.5 chậm nhất với 4 phút 18 giây.

Kết quả, theo số đo của Nathan (video đăng ngày 28/10/2026): năm trên sáu model đạt điểm tuyệt đối. Model duy nhất trượt là Luna, và nó trượt đúng câu khó nhất bộ. Câu đó là: bạn lên lịch cho một task chạy sau 60 giây, nhưng nó hết hạn sau 30 giây tính từ bây giờ, vậy nó có chạy không? Nghe thì rõ ràng là không nên chạy, nhưng thư viện tính lại thời điểm hết hạn tương đối mỗi lần task được đưa trở lại hàng đợi, nên thật ra nó có chạy. Luna trả lời là không chạy, và theo Nathan, đó đúng là kiểu câu trả lời bạn nhận được khi đọc code mà không lần theo nó.

Điều thứ hai đáng để ý là độ dài phần giải thích (theo số đo trong video đăng ngày 28/10/2026). Opus mất hai phút rưỡi (bảng ghi 2 phút 36 giây) và viết một bản giải thích 258 dòng, trong khi Nathan chỉ cần các câu trả lời. Terra viết 68 dòng, đạt cùng điểm, trong chưa tới một phút.

Theo Nathan (video đăng ngày 28/10/2026), model Opus có xu hướng giải thích rất chi tiết, còn phía ChatGPT, nhất là Terra, thường đi thẳng vào vấn đề và nói vừa đủ. Anh nói đây là một pattern bạn sẽ còn gặp đi gặp lại trong video.

## 10. Task 2: build app Kanban từ con số không

Ở bài thứ hai (demo trong video đăng ngày 28/10/2026), Nathan muốn các model build một thứ từ đầu, không nhìn vào code có sẵn, không có tham chiếu nào. Anh yêu cầu một Kanban board để quản lý project, với hai màn hình: bản thân board với kéo thả (drag and drop) giữa các cột, và một analytics dashboard hiển thị số task được tạo, hoàn thành và được giao (delegated), báo cáo theo tuần, và một bảng các thành viên trong team.

Stack là FastAPI, SQLite, cùng HTML, CSS và JavaScript thuần, không framework và không thư viện chart. App còn phải có một seed script lấp đầy dữ liệu demo trông như thật. Theo Nathan (video đăng ngày 28/10/2026), spec này có những quy tắc rất dễ làm sai một cách tinh vi, và anh viết 62 test ẩn cho các quy tắc đó.

Phần đầu prompt của Task 2 trên màn hình:

```
Build a kanban project-management web app from scratch in this empty folder. It has two screens: the board, and an analytics dashboard for the team.

**Stack:** Python, FastAPI, SQLite through the standard `sqlite3` module, and plain HTML, CSS and JavaScript served by FastAPI. No frontend build step, no JS frameworks, no chart libraries, no CDNs. The active Python environment already has `fastapi`, `uvicorn`, `httpx` and `pytest`. Do not install anything else.

The app must start with `uvicorn app.main:app`, so `app/main.py` exposes a FastAPI instance named `app`. The SQLite file path comes from the `KANBAN_DB` environment variable (default `kanban.db`), read when the app starts. The board is served at `/` and the analytics dashboard at `/analytics`.

All dates are `YYYY-MM-DD` strings. All bodies and responses are JSON. Invalid input returns 422, an unknown id in the URL returns 404.
```

![Bảng Task 2: hidden tests, time, lines và own tests của sáu model](https://homus.dev/photos/qcEkQEZdEyM-1132.jpg)

Kết quả Task 2 theo số đo của Nathan (video đăng ngày 28/10/2026): năm model đạt 62/62 test ẩn, GPT-6 Luna 60/62; GPT-6.1 Terra xong trong 2 phút 12 giây với 345 dòng, trong khi Haiku 5.5 viết 2.728 dòng và Opus 5.5 viết 2.278 dòng.

Kết quả, theo số đo của Nathan (video đăng ngày 28/10/2026): một lần nữa, tất cả trừ Luna đều đạt điểm tuyệt đối. Nhưng hãy nhìn cột số dòng code. Mỗi model Claude viết từ 1.600 tới 2.700 dòng. Trong khi đó, Terra build được một app pass cả 62 test ẩn chỉ với 345 dòng, trong khoảng 2 phút. Như vậy nhanh hơn Opus hơn 3 lần, với khoảng một phần bảy lượng code.

Và đây là một điều đi ngược với những gì bạn hay nghe. Người ta nói Claude viết nhiều test hơn, còn Codex thì tối giản hơn. Trong lượt chạy của Nathan (video đăng ngày 28/10/2026), model viết nhiều test nhất là Haiku, với 60 test. Đứng thứ hai là Sol với 59 test, nhiều hơn gấp đôi Opus. Vậy "Claude viết nhiều test hơn" hay không là tuỳ bạn đang chạy model nào.

Slide "More tests didn't buy a better score" trong video đăng ngày 28/10/2026 ghi số test mỗi model tự viết: Haiku 60, Sol 59, Opus 27, Sonnet 24, Terra 4 và Luna 4.

Cũng đáng nói thêm, theo số đo trong video đăng ngày 28/10/2026: Terra chỉ tự viết 4 test mà vẫn pass cả 62 test ẩn của Nathan. Theo anh, viết nhiều test hơn không tự động có nghĩa là code tốt hơn; nó có nghĩa là thêm sự tự tin, đổi lại bằng thêm thời gian.

## 11. Demo hai app Kanban: Opus và Sol

Tiếp theo (demo trong video đăng ngày 28/10/2026), Nathan demo nhanh kết quả của Opus và của một model GPT. Anh nói ở đầu đoạn là Opus và Terra; khi chuyển sang app thứ hai, anh gọi nó là kết quả từ GPT Sol, và các đánh giá sau đó của anh đều so Opus với Sol.

App của Opus trước (demo trong video đăng ngày 28/10/2026). Anh mở board. Khi thử kéo một task ra khỏi cột to-do, thao tác bị từ chối, trừ khi task đã được giao cho một thành viên. Anh giao task cho một người, và lúc này kéo được nó sang cột in progress. Mỗi người chỉ được có tối đa ba task đang in progress, nên khi thêm task thứ tư, anh thấy task đó bị từ chối. App còn có trang analytics, nơi xem được bao nhiêu task đã được tạo, bao nhiêu đã hoàn thành, tiến độ theo từng tuần, và những thứ tương tự.

![Kanban board của Opus với bốn cột To do, In progress, Review, Done và thông báo Can't move task](https://homus.dev/photos/qcEkQEZdEyM-1243.jpg)

App Kanban do Opus build, với dữ liệu demo do seed script sinh ra (tên người trên thẻ là dữ liệu giả): kéo một task chưa giao người ra khỏi To do thì hiện "Can't move task: Assign someone before moving this task out of todo"; cột In progress ghi "Max 3 per person" (demo trong video đăng ngày 28/10/2026).

Rồi tới kết quả của GPT Sol (demo trong video đăng ngày 28/10/2026). Nhìn qua, Nathan thấy UI của Opus trực quan hơn nhiều và dễ điều hướng hơn, nhưng anh vẫn test thử. Anh kéo một thẻ ra khỏi to-do và bị từ chối, vì thẻ vẫn chưa được giao người. Anh giao nó cho một người. Lần này lại bị từ chối, vì người đó đã có ba task ở cột in progress. Anh phải đưa một task ra khỏi in progress trước, ví dụ chuyển nó sang review, và lúc đó mới thêm được task cho người đó vào cột in progress. Theo Nathan, các quy tắc cơ bản đều chạy. Trang analytics (trên màn hình có tiêu đề "Team analytics", app có sidebar bên trái) trông khá giống, báo cáo những chỉ số quan trọng như bao nhiêu task được tạo, được giao và được hoàn thành.

Nhìn tổng thể, Nathan thích output của Opus hơn (demo trong video đăng ngày 28/10/2026). Nó có visual hierarchy, UI cố kéo mắt người xem tới những thứ quan trọng trước. Ở bản của GPT Sol, anh thấy mọi thứ như hoà lẫn vào nhau; nó cần màu có độ tương phản cao hơn để các thứ nổi bật lên. Anh phải tập trung thật sự mới đọc được. Font chữ cũng có vẻ quá nhỏ, có lẽ vì sidebar chiếm chỗ, làm hẹp khoảng trống cho board. Tóm lại, anh mất nhiều thời gian hơn để hiểu chuyện gì đang diễn ra trên màn hình.

## 12. Task 3: tách một file khoảng 5.600 dòng

Bài thứ ba (demo trong video đăng ngày 28/10/2026) là refactor một file khổng lồ, khoảng 5.600 dòng code (tiêu đề slide kết quả ghi file 5.644 dòng, thư viện more-itertools). Nathan yêu cầu mỗi model tách nó thành các module nhỏ hơn mà không làm hỏng gì. Mọi hàm vẫn phải import được từ đúng chỗ cũ, và 765 test có sẵn của codebase vẫn phải pass.

Theo Nathan (video đăng ngày 28/10/2026), bộ chấm của anh kiểm tra 6 điều: test pass; test không bị sửa; public API còn nguyên; các ví dụ trong documentation vẫn chạy; file gốc thật sự nhỏ đi; và code thật sự được tách ra các module mới.

![Bảng Task 3: checks, time, tests và doc examples của sáu model](https://homus.dev/photos/qcEkQEZdEyM-1512.jpg)

Kết quả Task 3 theo số đo của Nathan (video đăng ngày 28/10/2026): mọi model pass toàn bộ test, nhưng Luna làm hỏng 2 ví dụ trong docs, Sonnet hỏng 3, Terra xoá 9; Haiku, Opus và Sol giữ đủ, Opus còn thêm phần giữ cho ví dụ được tìm thấy. Cột test ghi 765/765 cho phần lớn model, 767/767 cho Sonnet và 769/769 cho Sol.

Đây là kết quả Nathan thích nhất trong cả video (video đăng ngày 28/10/2026), vì mọi model đều pass mọi test. Nếu chỉ nhìn test suite, bạn sẽ nói cả 6 model đều làm hoàn hảo. Nhưng 3 trong số đó vẫn làm hỏng một thứ gì đó.

Thư viện này có hàng trăm ví dụ nằm trong docstring, những đoạn Python nhỏ chỉ cách dùng từng hàm. Chúng là documentation, nhưng chúng cũng được chạy như test. Theo số đo trong video đăng ngày 28/10/2026, Sonnet để 3 ví dụ như vậy bị fail. Luna để 2 ví dụ fail. Terra thì lặng lẽ xoá 9 ví dụ trong lúc di chuyển code. Không cái nào hiện ra trong test suite bình thường, nên "mọi test đều pass" không giống với "không có gì bị hỏng". Theo Nathan, điều đó cũng đúng khi một người làm refactor.

Opus đi thêm một bước (theo số đo và nhận xét của Nathan, video đăng ngày 28/10/2026). Nó nhận ra rằng sau khi tách, công cụ doctest của Python sẽ không còn tìm thấy các ví dụ qua module cũ nữa. Vì vậy nó thêm một đoạn code nhỏ để các ví dụ vẫn được tìm thấy từ đó. Không ai yêu cầu việc này, nhưng theo Nathan, đó là kiểu việc một senior engineer sẽ làm, và nó cũng giải thích vì sao Opus mất 7 phút (bảng ghi 7 phút 16 giây) trong khi Sonnet và Terra chỉ mất chưa tới 2 phút.

## 13. Task 4: sửa bug từ một báo cáo mơ hồ

Bài thứ tư (demo trong video đăng ngày 28/10/2026): Nathan build một app nhỏ chia chi phí (expense splitting) có bug bên trong. Rồi anh đưa cho model một bug report mơ hồ, giống như một người dùng thật sẽ viết. Anh đọc báo cáo đó là "báo cáo tháng Ba của tôi ghi 1.200, nhưng các hoá đơn của tôi cộng lại là 1.400"; trên slide, báo cáo ghi chính xác là $1,284.40 so với $1,401.15.

Theo Nathan (video đăng ngày 28/10/2026), nguyên nhân thật là báo cáo hằng tháng bỏ sót ngày cuối cùng của mỗi tháng. Ngoài ra còn có một cái bẫy: cách sửa hiển nhiên sẽ crash vào tháng Mười Hai, vì không có tháng thứ 13. Các test ẩn của anh kiểm tra tháng Mười Hai, tháng Hai năm nhuận, và các tháng bình thường.

Cấu trúc Task 4 theo slide và lời Nathan trong video đăng ngày 28/10/2026: con số trong bug report lấy theo slide, nguyên nhân thật nằm ở ngày cuối tháng, và cái bẫy nằm ở tháng Mười Hai.

Kết quả, theo số đo của Nathan (video đăng ngày 28/10/2026): mọi model đều tìm ra bug, tránh được bẫy tháng Mười Hai và sửa xong trong chưa tới 40 giây. Đúng vậy, ngay cả hai model nhỏ nhất là Haiku và Luna cũng làm tốt ở đây. Theo Nathan, với một bug được khoanh vùng rõ trong một codebase nhỏ, bạn thật sự không cần tới model flagship. Trên slide kết quả, thời gian từ 24 giây (Sonnet) tới 37 giây (Opus và Sol), mỗi bản sửa từ 3 tới 6 dòng, model nào cũng 10/10.

Nathan thêm một ghi chú thật lòng về lượt chạy đầu tiên của anh (video đăng ngày 28/10/2026): Sol mất gần 6 phút cho bài này mà gần như không làm gì, nên anh nghĩ nó thật ra đã bị kẹt. Anh chạy lại, và lần thứ hai chỉ mất 37 giây. Vì vậy thời gian của một lượt chạy đơn lẻ có thể nhiễu, và theo anh, bạn nên nhớ điều đó với bất kỳ video so sánh nào, kể cả video này.

## 14. Task 5: review một pull request có cài bug

Bài cuối cùng (demo trong video đăng ngày 28/10/2026): Nathan mở một pull request trên chính app chia chi phí đó, thêm các tính năng sửa, xoá, lịch sử và export, và PR này có 3 bug nằm bên trong. Anh muốn xem các model có tìm ra chúng không.

![Bảng Task 5: planted, extra, time của sáu model và ô A 4th bug I didn't plant](https://homus.dev/photos/qcEkQEZdEyM-1743.jpg)

Kết quả Task 5 theo số đo của Nathan (video đăng ngày 28/10/2026): cả sáu model tìm đủ 3/3 bug đã cài; cột extra ghi Haiku 4, Luna 0, Sonnet 6, Terra 1, Opus 6, Sol 0. Ô bên phải: bug thứ tư anh không cài, lệnh export ghi đè lên bất kỳ file nào, kể cả file dữ liệu của app.

Kết quả thực tế, theo số đo trong video đăng ngày 28/10/2026: cả 6 model tìm ra đủ 3 bug, nhưng chúng khác nhau ở mọi thứ khác mà chúng báo cáo. Nathan nói các model Codex báo 3 bug rồi dừng (trên bảng, Terra có 1 phát hiện thêm, Luna và Sol là 0). Mỗi model Claude viết một bản review đầy đủ với 4 tới 6 phát hiện thêm.

Theo Nathan (video đăng ngày 28/10/2026), một số phát hiện thêm chỉ là bắt bẻ vặt (nitpick), ví dụ một thông báo ghi "exported 1 expenses" thay vì "1 expense". Nhưng một số là bug thật. Opus và Terra đều bắt được một bug thứ tư mà anh không hề cài vào: lệnh export sẵn sàng ghi đè lên bất kỳ file nào bạn chỉ tới, kể cả file dữ liệu của chính app. Nghĩa là chỉ một lỗi gõ là bạn có thể xoá sạch dữ liệu của mình. Cả ba model Claude còn chỉ ra rằng phần export CSV có thể bị spreadsheet formula injection.

Vì vậy, theo Nathan (video đăng ngày 28/10/2026), với code review, thói quen chủ động làm thêm của Claude thật sự có ích. Bạn muốn một reviewer chủ động cảnh báo bạn và cẩn trọng thêm, hơn là một reviewer chỉ báo đúng những gì được hỏi.

## 15. Kết luận 1 đến 3: flagship hoà, Haiku bất ngờ, Terra nhanh nhất

Chạy xong cả năm bài, Nathan rút ra (video đăng ngày 28/10/2026) kết luận và insight của anh từ bài test này.

Thứ nhất, theo số đo của Nathan (video đăng ngày 28/10/2026), hai model flagship hoà nhau tuyệt đối, trừ chuyện giá. Opus và Sol đều đạt điểm tuyệt đối, và tổng thời gian là 18 phút 32 giây so với 18 phút 29 giây: cách nhau 3 giây qua cả 5 bài. Nhưng tính theo giá API, Opus tốn khoảng 5 đô (slide ghi $5.19) còn Sol khoảng 1,24 đô. Cùng một kết quả, hoá đơn gần gấp 4 lần.

![Biểu đồ tổng chi phí theo giá API cho cả năm bài của sáu model](https://homus.dev/photos/qcEkQEZdEyM-2143.jpg)

Slide "Same perfect score, Opus cost 4x Sol" theo số đo của Nathan (video đăng ngày 28/10/2026): Luna $0.07, Terra $0.30, Haiku $0.91 (perfect), Sol $1.24 (perfect), Sonnet $1.51, Opus $5.19. Chú thích ghi chi phí Claude do Claude Code báo, chi phí Codex ước tính từ số token theo giá API chính thức, còn subscription tính tiền theo cách khác.

Thứ hai, theo số đo của Nathan (video đăng ngày 28/10/2026), Haiku là bất ngờ ngoài dự đoán của bài test. Model Claude nhỏ nhất, rẻ nhất lại đạt điểm tuyệt đối ở cả 5 bài với tổng chi phí 0,91 đô, chưa tới một phần năm chi phí của Opus. Nhưng nó không đạt được nhờ thông minh và nhanh, mà nhờ cày (grinding): nó là model chậm nhất tính tổng, và dùng nhiều token nhất ở mọi bài. Theo Nathan, nếu bạn không vội, ví dụ đang làm một side project vào cuối tuần, thì Haiku 5.5 là một lựa chọn bị đánh giá thấp một cách đáng kể.

Thứ ba, theo số đo của Nathan (video đăng ngày 28/10/2026), Terra là model nhanh nhất: năm bài trong chưa tới năm phút rưỡi (slide ghi 5 phút 25 giây), với khoảng 30 cent. Sơ suất duy nhất của nó là xoá vài ví dụ trong documentation ở bài refactor. Theo Nathan, nếu bạn muốn output nhanh và đúng cho công việc hằng ngày, model tầng giữa của Codex rất khó bị đánh bại.

## 16. Kết luận 4 và 5: khác nhau ở phong cách, test xanh chưa phải là xong

Thứ tư, theo Nathan (video đăng ngày 28/10/2026), cả hai bên đều rất có năng lực, nhưng phong cách thì khác hẳn nhau. Trong 30 lượt chạy, 25 lượt đạt điểm tuyệt đối; ngay cả model nhỏ cũng sửa được bug và tìm ra đủ ba bug ẩn trong bài review. Thứ thật sự phân biệt hai công cụ là cách chúng hành xử. Claude viết nhiều hơn: docs dài hơn, nhiều code hơn, nhiều phát hiện review hơn. Còn Codex làm đúng thứ bạn yêu cầu rồi dừng. Theo anh, không model nào tốt hơn một cách mặc định; nó tuỳ vào việc bạn đang implement hay đang review.

Và cuối cùng, theo Nathan (video đăng ngày 28/10/2026), pass test không giống với đúng. Bài refactor đã chứng minh điều này: mọi model đều pass cả 765 test (con số anh nói; bảng Task 3 ghi 767 cho Sonnet và 769 cho Sol), vậy mà một nửa trong số đó vẫn làm hỏng một thứ gì đó. Dù bạn dùng công cụ nào, đừng coi một test suite xanh là vạch đích. Theo anh, ngay cả một lượt test tay hay review nhanh cũng có thể giúp bạn tránh ship thứ bị hỏng.

## 17. Nên dùng công cụ nào

Vậy nên dùng cái nào? Đây là đề xuất của Nathan dựa trên các kết quả này (video đăng ngày 28/10/2026).

Nếu bạn muốn tốc độ và hiệu quả cho việc code hằng ngày, theo Nathan (video đăng ngày 28/10/2026), Codex là một lựa chọn mặc định rất tốt. Terra và Sol đúng ở gần như mọi bài, và Terra là model nhanh nhất trong các bài test, bỏ xa phần còn lại.

Nếu bạn muốn chiều sâu, theo Nathan (video đăng ngày 28/10/2026), ví dụ một reviewer bắt được những thứ bạn không hỏi, hay một lượt refactor bảo vệ những thứ mà test không bao phủ, thì Claude Code là nơi điều đó thể hiện. Trong các bài test của anh, Opus bắt được bug thứ tư, giữ nguyên các doctest, và viết documentation đầy đủ nhất.

Đề xuất cuối của Nathan theo kết quả bài test trong video đăng ngày 28/10/2026, cùng ý với slide "Pick by how you like to work".

Và khi ngân sách eo hẹp, theo Nathan (video đăng ngày 28/10/2026), đừng bỏ qua các model nhỏ. Haiku đạt điểm tuyệt đối ở đây, còn Luna chỉ kém vài điểm. Với những task được khoanh vùng rõ như sửa bug hay review một PR, model ở tầng nào cũng làm tốt.

Nếu dư ngân sách, theo Nathan (tính đến video đăng ngày 28/10/2026), bạn cũng có thể đăng ký cả hai công cụ với giá 20 đô mỗi tháng mỗi bên. Khi đó bạn dùng Codex để viết code, còn Claude để lên plan và review task. Trong bài test của anh, các model Codex viết code gọn (lean code) và nhanh, còn các model Claude là những reviewer chu đáo nhất. Chúng giỏi ở những việc khác nhau, nên hãy để chúng kiểm tra công việc của nhau. Theo anh, đó là tốt nhất của cả hai thế giới. Nhưng nếu không có ngân sách, cứ chọn một cái, và nó sẽ xử lý ổn mọi thứ bạn giao.

Nathan nhắc lại rằng đây là những lượt chạy đơn lẻ trên bộ test của riêng anh (video đăng ngày 28/10/2026), và kết quả của bạn có thể khác. Theo anh, bài test tốt nhất là mua gói 20 đô trong một tháng và tự chạy bài test của bạn trên đúng loại việc bạn thật sự làm, vì đó là benchmark duy nhất thật sự có ý nghĩa với bạn. Có người sẽ thích Codex hơn, có người thích Claude Code hơn, và theo anh điều đó cũng hay, vì cả hai thật sự đều là công cụ tốt. Anh cảm ơn những ai đã xem tới cuối.

## Nguồn và liên kết

- Tên gốc: Claude Code vs Codex - Real Cost & Performance Test (2026)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=qcEkQEZdEyM](https://www.youtube.com/watch?v=qcEkQEZdEyM)

- Kênh YouTube Nathan Sebhastian (Nathan Sebhastian): [youtube.com/channel/UCvS59S24crXmGfIEiejcr9g](https://www.youtube.com/channel/UCvS59S24crXmGfIEiejcr9g)

- Claude Code docs, trang Overview (Claude Code có trong terminal, IDE, desktop app và browser; đọc ngày 29/10/2026): [code.claude.com/docs/en/overview](https://code.claude.com/docs/en/overview)

- Codex docs, trang Pricing (Codex có trong các gói ChatGPT Free, Go, Plus, Pro, Business, Edu, Enterprise; đọc ngày 29/10/2026): [developers.openai.com/codex/pricing](https://developers.openai.com/codex/pricing)

- Repo Codex CLI của OpenAI (license Apache-2.0, 131,6k star; đọc ngày 29/10/2026): [github.com/openai/codex](https://github.com/openai/codex)

- Trang giá Claude (Claude Code dùng chung usage limit với phần còn lại của gói; Max có 5x hoặc 20x usage của Pro; đọc ngày 29/10/2026): [claude.com/pricing](https://claude.com/pricing)

- Leaderboard Senior SWE-bench của Snorkel AI, nguồn của bảng Tasteful Solve trong video (đọc ngày 29/10/2026): [snorkel.ai/leaderboard/senior-swe-bench](https://snorkel.ai/leaderboard/senior-swe-bench)

Nguồn: https://homus.dev/talks/claude-code-vs-codex-real-cost-performance-test-2026 · cập nhật 2026-10-29