Claude Code, NotebookLM và Obsidian cho nghiên cứu thông minh hơn

Token hiện nay đang là vấn đề nóng luôn luôn được chú ý trong cộng đồng AI. Trong đó hai skill mã nguồn mở về vấn đề tiết kiệm token đang được cộng đồng lập trình AI bàn tán nhiều nhất mùa hè 2026: Ponytail giúp giảm tới 54% dòng code sinh ra, còn Caveman cắt gọn 65% token trong phản hồi của Agent. Cả hai cùng nhắm vào một nỗi đau quen thuộc của mọi người dùng AI Agent lập trình như Claude Code, Codex hay Gemini CLI, đó là chi phí token ngày càng phình to, nhưng lại giải quyết theo hai hướng hoàn toàn khác nhau: một bên cắt phần code thừa, một bên cắt phần lời thừa.Bài toán lãng phí token trong kỷ nguyên AI AgentCác AI Agent ngày nay không chỉ trả lời một câu hỏi đơn lẻ mà hoạt động theo chuỗi vòng lặp tự động (agentic loop): đọc file, phân tích dự án, viết code, chạy thử và kiểm tra lỗi. Trong quy trình đó, token phần lớn bị lãng phí qua ba kênh chính:Over-engineering (Viết thừa code): Thay vì dùng tính năng có sẵn của ngôn ngữ hoặc trình duyệt, agent thường tự cài thêm thư viện phụ thuộc (dependency) hoặc dựng nên những component phức tạp không cần thiết.Input Overhead (Đọc dư thừa): Nhật ký build, dữ liệu JSON, kết quả tìm kiếm và các file hướng dẫn (SKILL.md) ngốn hàng chục ngàn input token mỗi lần gửi yêu cầu lên nhà cung cấp API.Output Bloating (Nói dài dòng): Agent giải thích dông dài những khái niệm căn bản trước khi đưa ra câu trả lời cốt lõi.Ponytail: biến AI Agent thành "senior dev lười biếng"Dự án Ponytail của nhà phát triển Dietrich Gebert được thiết kế với triết lý: "Mã nguồn tốt nhất là mã nguồn bạn không bao giờ phải viết". Ponytail buộc AI Agent phải suy nghĩ như một lập trình viên senior lâu năm, người luôn luôn tìm giải pháp đơn giản và tốn ít công sức nhất.Chuỗi câu hỏi tự vấn trước khi viết codeTrước khi đặt tay vào viết code, Ponytail bắt buộc Agent phải đi qua một chuỗi câu hỏi tự vấn:YAGNI: Tính năng này có thực sự cần thiết không? Nếu không, bỏ qua lập tức.Tái sử dụng: Đã có sẵn hàm hoặc component tương tự trong dự án chưa?Thư viện chuẩn: Thư viện chuẩn của ngôn ngữ có xử lý được không?Nền tảng gốc: Trình duyệt hoặc hệ điều hành đã hỗ trợ sẵn chưa? (Ví dụ: dùng thẻ <input type="date"> native thay vì cài thư viện Flatpickr nặng nề)Dependency đã cài: Các gói thư viện đã có trong package.json có giải quyết được không?One-liner: Có thể xử lý gọn trong 1 dòng code không?Chỉ khi các bước trên không đáp ứng, Agent mới tiếp tục viết đoạn code tối giản nhất vừa đủ hoạt động.Kết quả benchmark có khác với thực tế khôngTrong thử nghiệm với Claude Code (Haiku 4.5) trên mẫu dự án full-stack FastAPI + React, Ponytail giúp giảm 54% số dòng code mà vẫn giữ nguyên 100% độ an toàn của ứng dụng.Đây là con số do chính tác giả công bố sau khi bản benchmark đầu tiên (giảm 80-94%) bị cộng đồng chỉ ra lỗi baseline, nên xem là tín hiệu tham khảo hơn là số liệu độc lập đã kiểm chứng.Caveman: một hệ sinh thái nén token, không chỉ một skillNếu Ponytail tập trung vào mã nguồn sinh ra, thì Caveman của Julius Brussee lại tấn công cả phần đầu vào lẫn đầu ra của Agent, với khẩu hiệu vui nhộn: "why use many token when few token do trick". Bản Caveman hiện tại không còn là một skill đơn lẻ mà là một bộ công cụ gồm nhiều lớp.Caveman Proxy: nén dữ liệu đầu vàoMột proxy cục bộ được đặt giữa Agent và API provider, tự động định tuyến toàn bộ traffic đi qua. Proxy này nhận diện từng loại payload như JSON, log lỗi, git diff hay kết quả tìm kiếm, rồi nén theo cách giữ lại phần nội dung mà câu trả lời thực sự phụ thuộc vào, trong khi vẫn lưu bản sao trên ổ đĩa để khôi phục chính xác khi cần. Trong một benchmark 54 lượt chạy cố định trên Claude Code, cơ chế này dùng ít hơn 33.2% input token so với chạy trực tiếp, đồng thời vẫn vượt qua toàn bộ các bài kiểm tra đáp án chính xác.Caveman Skill: nén ngôn ngữ phản hồiĐây là phần giúp ngôn ngữ quay về thời người tiền sử nguyên bản: Agent bỏ qua các câu xã giao thừa thãi, đi thẳng vào vấn đề mà không làm biến đổi bất kỳ dòng lệnh hay mã nguồn nào. Phần code, lệnh và log lỗi vẫn được giữ nguyên byte-exact, chỉ phần lời giải thích bị nén lại.Pixel Mode: chuyển file hướng dẫn skill thành ảnhCác file SKILL.md dài dòng được chuyển đổi thành ảnh PNG khi cài skill mới, tận dụng khả năng đọc ảnh (vision) của các mô hình LLM hiện đại để giảm số token cần nạp. Đo trên chính skill Caveman, cách này giúp giảm kích thước từ khoảng 1.069 xuống còn 415 token ước tính, tương đương 61%.Con số 61% được đo trên một trường hợp cụ thể (chính SKILL.md của Caveman), không phải mức giảm trung bình áp dụng cho mọi file hướng dẫn — kết quả thực tế sẽ khác tùy độ dài và cấu trúc của file bạn dùng.Caveman Learn: tự chẩn đoán điểm nghẽn tokenLệnh caveman learn tự động đọc lịch sử làm việc của Agent trên máy (chạy cục bộ, không cần tài khoản), chấm điểm cách thiết lập hiện tại và chỉ ra chính xác những chỗ đang ngốn token nhất để người dùng khắc phục.Con số cần lưu ý khi đọc marketing của CavemanTài liệu chính thức của Caveman có một mục "honest number warning" nói rõ: bản thân Caveman Skill chỉ giảm output token, input và reasoning token gần như không đổi nếu không bật thêm proxy, thậm chí còn cộng thêm khoảng 1.000-1.500 input token mỗi lượt cho phần skill. Con số 65% output token, 33.2% input token (qua proxy) và 61% token skill (qua Pixel Mode) là ba phép đo tách biệt, không cộng dồn thành một con số duy nhất nên đọc kỹ ngữ cảnh trước khi trích dẫn.Có thể kết hợp Ponytail và Caveman trong cùng một phiên làm việc hay chung 1 project khôngPonytail và Caveman không hề dẫm chân nhau. Caveman chịu trách nhiệm giữ cho những gì Agent đọc (input) và nói (output) ngắn gọn nhất có thể, trong khi Ponytail đảm bảo những gì Agent viết (code) đạt độ tối giản cao nhất. Vì cơ chế không chồng lấn, chúng ta hoàn toàn có thể dùng song song cả hai trong cùng một phiên làm việc.Chưa có benchmark độc lập nào đo mức tiết kiệm khi kết hợp cả hai cùng lúc, nhưng cộng theo lý thuyết các con số đã công bố riêng lẻ thì tổng token tiêu thụ mỗi phiên có thể giảm đáng kể, đủ để đáng thử nghiệm trên dự án thật của bạn.Hướng dẫn tích hợp vào workflow lập trình hàng ngàyCả Ponytail và Caveman đều hỗ trợ cài đặt nhanh cho các công cụ lập trình AI phổ biến như Claude Code, Codex, Gemini CLI, Cursor hay Windsurf.Cài đặt PonytailVới Claude Code:claude plugin marketplace add DietrichGebert/ponytail && claude plugin install ponytail@ponytailVới các agent khác chưa hỗ trợ plugin marketplace, bạn có thể sao chép trực tiếp file rules từ repo GitHub vào thư mục dự án.Cài đặt CavemanVới Claude Code:claude plugin marketplace add JuliusBrussee/caveman && claude plugin install caveman@cavemanVới Gemini CLI:gemini extensions install https://github.com/JuliusBrussee/cavemanCài cho Cursor, Windsurf, Cline và các agent khácCaveman hỗ trợ cài qua registry chung:npx skills add JuliusBrussee/caveman -a <tên-agent>Bạn sẽ chọn Ponytail, Caveman hay là cả hai?Tối ưu token không chỉ là chuyện tiết kiệm chi phí, mà còn giúp AI Agent giữ ngữ cảnh sạch, tránh trôi thông tin khi làm việc dài hạn. Nhưng bài học lớn hơn từ cả hai skill này là đừng tin ngay con số phần trăm được quảng cáo, kể cả khi nó đến từ chính tác giả, vì mỗi con số thường chỉ đo một trường hợp cụ thể chứ không phải mức trung bình chung. Cách chắc chắn nhất vẫn là tự chạy benchmark trên codebase thật của bạn trước khi quyết định đưa Ponytail, Caveman, hay cả hai vào workflow hàng ngày.

Anthropic vừa ra mắt Claude Opus 5 với mức giá giữ nguyên như Opus 4.8 nhưng chất lượng trả lời được nâng lên gần bằng Fable 5, model đắt gấp đôi. Nói cách khác, với mức giá bằng một nửa Fable 5 mà hiệu năng lại áp sát, phần lớn người dùng nhiều khả năng sẽ chọn Opus 5 làm model mặc định, chỉ giữ Fable 5 cho số ít tác vụ thật sự cần đến giới hạn cao nhất. Claude Opus 5 mang đến những nâng cấp nào? Theo thông báo ra mắt của Anthropic, Claude Opus 5 là model Opus mạnh nhất tính đến nay và là đại diện đầu tiên của dòng Opus thuộc thế hệ Claude 5. Anthropic mô tả đây là model chủ động, biết suy nghĩ sâu và tiến gần trí tuệ cấp cao nhất của Claude Fable 5 trong nhiều lĩnh vực, nhưng chỉ tốn một nửa chi phí token. Model có mã API claude-opus-5, context mặc định và tối đa 1 triệu token, tương tự Opus 4.8 và Fable 5, cùng giới hạn đầu ra 128.000 token và chế độ thinking được bật mặc định. Nó đã trở thành model mặc định trên Claude Max và là model mạnh nhất khả dụng trên Claude Pro, đồng thời có mặt trên Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry và cả GitHub Copilot. Vì sao nhiều người sẽ chọn Opus 5 thay vì Fable 5? Câu trả lời không chỉ nằm ở con số giá. Có bốn lý do khiến Opus 5 nhiều khả năng trở thành lựa chọn mặc định cho công việc hằng ngày, trong khi Fable 5 lùi về vai trò công cụ chuyên dụng cho số ít trường hợp đặc biệt. Thắng nhiều hơn thua trên các bài kiểm tra thực tế Trên Frontier-Bench v0.1, bài kiểm tra coding tự động của chính Anthropic, Opus 5 đạt 43,3% trong khi Fable 5 chỉ đạt 33,7%, một khoảng cách gần 10 điểm nghiêng hẳn về Opus 5. Trên CursorBench 3.2 ở mức effort tối đa, Opus 5 đạt khoảng 70,1%, thua Fable 5 chưa tới nửa điểm phần trăm nhưng chi phí chỉ bằng một nửa. Tính chung trên các bài kiểm tra mà cả hai model đều có số liệu, Opus 5 thắng nhiều hơn thua và phần thắng thường lớn hơn phần thua. Cách kiểm chứng nhanh nhất: chạy cùng một tác vụ trên cả hai model ở effort tương đương, rồi so sánh chất lượng đầu ra thay vì chỉ nhìn benchmark được công bố. Không bị ép giữ dữ liệu 30 ngày Fable 5 và Mythos 5 thuộc nhóm Covered Models, bắt buộc lưu giữ prompt và kết quả trong 30 ngày để phục vụ công tác an toàn, đồng thời không hỗ trợ zero data retention (ZDR) trên bất kỳ nền tảng nào, kể cả khi tổ chức đã có thỏa thuận ZDR từ trước. Ngược lại, Opus 5 vẫn vận hành được dưới ZDR như Opus 4.8. Với các đội ngũ xử lý dữ liệu pháp lý, y tế hoặc tài chính, riêng điểm này đã đủ để loại Fable 5 khỏi danh sách lựa chọn mà không cần so hiệu năng. Ít bị gián đoạn bởi bộ lọc an toàn Anthropic cho biết bộ phân loại an ninh mạng của Opus 5 can thiệp ít hơn khoảng 85% so với Fable 5. Với các coding agent chạy nhiều giờ hoặc qua đêm, việc bị chặn giữa chừng vì request chạm ngưỡng an toàn là rủi ro thực sự làm gián đoạn quy trình, và Opus 5 giảm đáng kể tần suất đó. Effort điều chỉnh được, ngân sách dễ đoán hơn Opus 5 hỗ trợ adaptive thinking với effort từ thấp đến tối đa. Mức thấp hoặc trung bình phù hợp cho phản hồi nhanh và khối lượng lớn, còn mức cao hoặc tối đa dành cho coding phức tạp, nghiên cứu sâu và quy trình nhiều bước. Vì phải trả tiền theo effort đã chọn thay vì bị khóa vào một mức giá cố định như Fable 5, đội ngũ có thể tối ưu ngân sách theo từng loại tác vụ thay vì trả giá cao nhất cho mọi request. Cảm nhận ban đầu sau khi dùng thử Opus 5 Sau khi dùng thử Opus 5 cho công việc viết lách và xử lý code hằng ngày, cảm nhận rõ nhất là model này thông minh hơn hẳn Opus 4.8, đặc biệt ở khả năng hiểu ý đồ ngay từ lần yêu cầu đầu tiên mà không cần giải thích lại nhiều lần. Với các tác vụ như tóm tắt tài liệu dài, viết code có logic rẽ nhánh phức tạp hoặc lên kế hoạch nhiều bước, Opus 5 xử lý mượt và ít khi đi lạc đề như bản cũ thường gặp. So với Fable 5 thì vẫn có khoảng cách, dù không lớn như tưởng tượng. Ở những tác vụ đòi hỏi suy luận sâu hoặc phải tự chủ qua nhiều bước liên tiếp mà không có ai can thiệp, Fable 5 vẫn xử lý chắc tay và ít sai sót hơn một chút. Nhưng với phần lớn công việc hằng ngày, mức chênh lệch đó khó nhận ra nếu không đặt hai model cạnh nhau để so sánh trực tiếp. Nếu bạn đang dùng Opus 4.8, đây là thời điểm hợp lý để nâng cấp. Còn nếu đang cân nhắc giữa Opus 5 và Fable 5 cho công việc thông thường, Opus 5 gần như đủ dùng mà không cần trả thêm tiền. Khi nào Fable 5 vẫn là lựa chọn đúng? Fable 5 vẫn giữ được lợi thế ở đúng những chỗ khó nhất. Trên SWE-bench Pro, bộ kiểm tra dùng vấn đề GitHub có thật và được xem là thước đo khắt khe nhất cho công việc coding thực tế, Fable 5 đạt khoảng 80% trong khi Opus 5 đạt khoảng 79%, một khoảng cách nhỏ nhưng vẫn nghiêng về Fable 5. Fable 5 cũng là model duy nhất Anthropic định vị ở cấp Mythos, tức năng lực tổng thể cao hơn Opus theo thiết kế, và điều này thể hiện rõ ở các lĩnh vực chuyên sâu như phân tích y tế chuyên môn hoặc nghiên cứu tự chủ kéo dài nhiều ngày mà không có người giám sát. Nói cách khác, phần thắng của Opus 5 tập trung ở công việc coding và xử lý tri thức hằng ngày, còn lợi thế của Fable 5 nằm ở những bài toán khó nhất và các lĩnh vực đòi hỏi độ tin cậy tuyệt đối. Với đa số người dùng và đội ngũ nhỏ, những bài toán đó chiếm tỷ trọng rất nhỏ trong công việc thường ngày, nên khoản chênh lệch giá gấp đôi khó biện minh được, trừ khi công việc của bạn rơi đúng vào nhóm này. So sánh nhanh Opus 5 và Fable 5 Tiêu chíClaude Opus 5Claude Fable 5 Giá đầu vào5 USD/triệu token10 USD/triệu token Giá đầu ra25 USD/triệu token50 USD/triệu token Context1 triệu token1 triệu token Đầu ra tối đa128.000 token128.000 token Frontier-Bench v0.1 (coding agent)43,3%33,7% SWE-bench Pro (coding thực tế)~79%~80% Lưu giữ dữ liệuHỗ trợ zero data retentionBắt buộc lưu giữ 30 ngày, không có ZDR Tần suất chặn bởi bộ lọc an toànThấp hơn khoảng 85%Cao hơn Phù hợp nhấtCông việc hằng ngày, coding agent, dữ liệu nhạy cảmNghiên cứu khó, dự án tự chủ dài ngày, phân tích y tế chuyên sâu Vậy Opus 5 có thật sự đọ được với GPT-5.6? Trên giấy tờ, câu trả lời là có, nhưng không phải toàn diện. Opus 5 dẫn trước GPT-5.6 Sol ở khả năng suy luận với tình huống mới, thao tác máy tính và phần lớn bài kiểm tra coding công khai, trong khi GPT-5.6 Sol vẫn nhỉnh hơn ở một số bài kiểm tra thao tác dòng lệnh và tìm kiếm thông tin. Không bên nào thắng tuyệt đối, nhưng lần đầu tiên một model tầm giá trung của Anthropic đứng ngang hàng, thậm chí nhỉnh hơn ở nhiều mặt so với model đầu bảng của OpenAI. Câu hỏi đáng quan tâm hơn không phải model nào mạnh hơn mà là model nào thực sự phù hợp với bạn. Nếu công việc hằng ngày xoay quanh code, tài liệu dài và tác vụ nhiều bước, Opus 5 đang là lựa chọn hợp lý cả về giá lẫn chất lượng. Còn nếu bạn đã quen với hệ sinh thái OpenAI hoặc cần đúng thế mạnh của GPT-5.6, chi phí chuyển đổi có thể không đáng để thay đổi. Cách trả lời chắc chắn nhất vẫn là tự chạy thử cùng một việc trên cả hai, vì bảng benchmark không phải lúc nào cũng phản ánh đúng trải nghiệm thật.

Có ai đang dùng song song cả Codex lẫn Claude Code không? Mình mới phát hiện plugin Codex cho Claude Code do chính OpenAI phát hành. Nói thật là đến giờ mới biết nên cũng có cảm giác như người tối cổ. Điểm hay nhất là từ nay có thể gọi Codex ngay trong phiên Claude Code hiện tại để review code, phản biện hướng triển khai hoặc nhận riêng một tác vụ, không phải chuyển qua lại giữa nhiều tab và session như trước. Plugin Codex cho Claude Code có gì đáng chú ý? Plugin openai/codex-plugin-cc được thiết kế cho người đã quen làm việc trong Claude Code nhưng muốn tận dụng thêm Codex. Thay vì để hai agent cùng nhảy vào chỉnh một file, bạn có thể phân vai rõ ràng: Claude Code triển khai, Codex kiểm tra; hoặc Claude Code giữ luồng chính còn Codex xử lý một vấn đề độc lập ở chế độ nền. Theo tài liệu chính thức, plugin cung cấp ba nhóm khả năng. Nhóm review gồm /codex:review và /codex:adversarial-review. Nhóm giao việc có /codex:rescue. Nhóm quản lý phiên và tác vụ nền gồm /codex:transfer, /codex:status, /codex:result và /codex:cancel. Nhờ vậy, Codex trở thành một cộng sự nằm ngay trong workflow Claude Code thay vì là một cửa sổ tách rời. Không phải một Codex runtime tách biệt Plugin không tạo thêm một hệ thống Codex mới. Nó sử dụng Codex CLI và Codex app server đang cài trên máy, đồng thời dùng lại trạng thái đăng nhập, repository hiện tại và cấu hình trong config.toml. Điều này giúp việc tích hợp gọn hơn, nhưng cũng có nghĩa mọi lượt gọi vẫn được tính vào giới hạn sử dụng Codex của tài khoản. Điều kiện trước khi cài Bạn cần Node.js 18.18 trở lên và một tài khoản ChatGPT, kể cả gói Free, hoặc OpenAI API key. Nếu Codex CLI chưa có trên máy, lệnh /codex:setup có thể hướng dẫn cài; cách thủ công là chạy npm install -g @openai/codex. Nếu chưa đăng nhập, dùng !codex login ngay trong Claude Code. Cách cài Codex plugin trong Claude Code Quy trình cài đặt khá ngắn. Trong Claude Code, lần lượt chạy các lệnh sau: /plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /reload-plugins /codex:setup Lệnh cuối kiểm tra Codex đã được cài và xác thực hay chưa. Sau khi hoàn tất, danh sách slash command của Codex sẽ xuất hiện trong Claude Code, đồng thời agent codex:codex-rescue cũng có mặt trong mục /agents. Chạy thử ở chế độ nền Một bài thử ít rủi ro là yêu cầu Codex review thay đổi hiện tại bằng /codex:review --background, sau đó dùng /codex:status để xem tiến độ và /codex:result để lấy kết quả. Review nhiều file có thể mất thời gian, vì vậy chạy nền sẽ không chặn luồng làm việc chính của Claude Code. Ba cách phối hợp Codex và Claude Code hiệu quả Giá trị của plugin không nằm ở việc có thêm một AI, mà ở cách phân vai. Nếu cả hai cùng sửa một khu vực mà không có ranh giới, bạn dễ gặp xung đột code, lặp phân tích và tốn context. Ba luồng dưới đây rõ trách nhiệm hơn. Claude viết, Codex review Đây là cách dễ áp dụng nhất. Sau khi Claude Code hoàn thành một tính năng, chạy /codex:review để Codex thực hiện review chỉ đọc. Lệnh này có thể kiểm tra thay đổi chưa commit hoặc so sánh branch với nhánh gốc bằng /codex:review --base main. Codex không sửa file trong chế độ này, nên bạn vẫn giữ quyền quyết định cuối cùng. Ví dụ, Claude vừa thêm luồng thanh toán qua ba module. Thay vì yêu cầu Claude tự đánh giá lại phần việc của chính mình, hãy để Codex rà lỗi logic, trường hợp biên và tác dụng phụ giữa các file. Sau đó Claude Code có thể đọc nhận xét, chọn điểm hợp lý và sửa trong cùng phiên. Giao hẳn một task cho Codex Với một bài toán có thể tách độc lập, dùng /codex:rescue. Chẳng hạn: /codex:rescue --background điều tra nguyên nhân kiểm thử tích hợp không ổn định. Claude Code tiếp tục xử lý UI hoặc tài liệu, trong khi Codex điều tra test ở nền. Lệnh này hỗ trợ --background, --wait, --resume và --fresh, nên có thể tiếp tục một task trước đó hoặc buộc mở một lượt mới. Điểm quan trọng là mô tả đầu ra và phạm vi file rõ ràng. Giao “sửa mọi thứ đang lỗi” cho Codex trong khi Claude cũng đang chỉnh toàn repository vẫn có nguy cơ đụng nhau. Một task tốt nên có mục tiêu cụ thể, tiêu chí hoàn thành và vùng code sở hữu riêng. Dùng adversarial review để chất vấn hướng phát triển dự án /codex:adversarial-review phù hợp khi bạn không chỉ muốn bắt bug mà còn muốn chất vấn quyết định thiết kế. Có thể thêm trọng tâm, ví dụ: /codex:adversarial-review --base main challenge the caching and retry design. Codex sẽ soi giả định ẩn, trade-off, phương án thay thế và các rủi ro như mất dữ liệu, race condition, rollback hoặc độ tin cậy. Nói vui thì đây là lúc hai ông có thể “cãi nhau ỏm tỏi”, nhưng tranh luận chỉ hữu ích khi có người cầm trịch. Hãy đặt câu hỏi hẹp, yêu cầu bằng chứng và chốt tiêu chí ra quyết định; nếu không, phiên phản biện rất dễ biến thành chuỗi ý kiến nối tiếp mà không tạo ra thay đổi thực tế. Chuyển phiên và quản lý tác vụ nền Plugin còn giải quyết một vấn đề quen thuộc: đã thảo luận dài trong Claude Code nhưng muốn chuyển nguyên mạch công việc sang Codex. /codex:transfer tạo một Codex thread bền vững từ phiên Claude Code hiện tại và trả về lệnh codex resume <session-id>. Nhờ đó, bạn không phải viết lại toàn bộ bối cảnh bằng tay. Khi nào nên dùng transfer Hãy dùng transfer khi task đã vượt khỏi một lần review ngắn và bạn muốn tiếp tục trực tiếp trong Codex App hoặc TUI. Ví dụ, Claude Code đã cùng bạn điều tra kiến trúc trong một phiên dài, nhưng giai đoạn tiếp theo cần Codex thực hiện nhiều vòng chỉnh sửa. Việc chuyển phiên giữ lại lịch sử có cấu trúc và giảm rủi ro mất các quyết định đã thống nhất. Theo dõi, lấy kết quả và hủy tác vụ Với task chạy nền, /codex:status cho biết tiến độ, /codex:result trả kết quả cuối cùng và session ID, còn /codex:cancel dừng job đang chạy. Ba lệnh này nghe đơn giản nhưng rất cần thiết để workflow nhiều agent không trở thành một hộp đen. Nếu task đi sai hướng, hủy sớm thường tiết kiệm limit hơn chờ kết quả rồi làm lại. Cẩn thận vòng lặp review và giới hạn sử dụng Lưu ý quan trọng: OpenAI cảnh báo rõ rằng review gate có thể tạo vòng lặp Claude/Codex kéo dài và tiêu hao giới hạn sử dụng nhanh. Khi bật bằng /codex:setup --enable-review-gate, plugin dùng Stop hook, tức cơ chế tự động kích hoạt khi Claude chuẩn bị kết thúc câu trả lời, để gọi một lượt review có mục tiêu. Nếu Codex tìm thấy vấn đề, phản hồi của Claude bị chặn để Claude xử lý trước. Cơ chế này hữu ích trước khi ship, nhưng không nên bật rồi bỏ mặc. Review gate mạnh nhưng cần giám sát Kịch bản dễ gặp là Codex nêu vấn đề, Claude sửa, Codex review lại và phát hiện một điểm mới; chu kỳ tiếp tục vì tiêu chí “đủ tốt” chưa được định nghĩa. Đây chính là phiên bản tự động của việc để hai agent review qua lại liên tục. Chi phí không chỉ là limit mà còn là thời gian và nguy cơ thay đổi quá mức một bản vá vốn đã ổn. Một bộ nguyên tắc vận hành an toàn Phân vai trước khi chạy: một agent triển khai, một agent review hoặc một agent sở hữu một task độc lập. Giới hạn phạm vi: nêu rõ branch, file, loại rủi ro và tiêu chí hoàn thành. Ưu tiên chạy nền cho review nhiều file, nhưng kiểm tra trạng thái định kỳ. Chỉ bật review gate khi đang chủ động theo dõi và tắt bằng /codex:setup --disable-review-gate sau khi hoàn tất. Không yêu cầu Claude review lại toàn bộ kết quả Codex rồi tiếp tục yêu cầu Codex review toàn bộ phần sửa của Claude nếu chưa có điểm dừng rõ ràng. Dùng /codex:cancel khi task lệch hướng thay vì cố cứu một vòng chạy tốn kém. Làm sao kết hợp Codex và Claude Code hiệu quả? Trước đây mình thường mở Codex và Claude Code song song, đôi lúc còn để cả hai cùng nhảy vào một file để tiết kiệm thời gian. Plugin chính chủ của OpenAI tạo ra cách làm gọn hơn: Claude Code giữ vai trò điều phối, Codex vào review, phản biện hoặc nhận task riêng mà không cần chuyển tab liên tục. Bắt đầu tốt nhất là cài plugin, chạy một lượt /codex:review --background trên dự án nhỏ và quan sát cách ba lệnh status, result, cancel hoạt động. Khi đã quen mới thử rescue, transfer và review gate. Hai AI có thể bổ trợ nhau rất tốt, miễn là con người vẫn đặt ranh giới, ngân sách và điểm dừng.

Mình đã nghe rất nhiều về repo gstack của CEO Y Combinator thế là tò mò cài vào thử, thứ khiến mình bất ngờ nhất không phải các workflow xịn mà là tư duy thật sự khác biệt của vị CEO này. Đó là lệnh đầu tiên trong cả hệ thống: /office-hours với sáu câu hỏi bắt đầu nhưng lại không hỏi về code chỉ hỏi những thứ mà hầu hết mọi người chưa trả lời được trước khi bắt tay vào build. gstack là gì và tại sao Garry Tan tạo ra nó gstack là bộ công cụ mã nguồn mở của Garry Tan, CEO Y Combinator, chủ yếu được thiết kế ra dành cho Claude Code. Ý tưởng cốt lõi của repo là thay vì dùng AI như một người viết code đơn thuần, Garry Tan muốn biến Claude thành cả một nhóm AI agent làm việc thu nhỏ, mỗi thành viên phụ trách một vai trò khác nhau từ người định hướng sản phẩm, kiểm tra bảo mật, đến người kiểm thử và phát hành. Toàn bộ quy trình chạy theo vòng lặp có thứ tự: suy nghĩ → lên kế hoạch → xây dựng → kiểm tra → thử nghiệm → phát hành → đánh giá lại . Cụ thể hơn, gstack chia Claude Code thành 23 vai trò chuyên biệt tất nhiên trong workflow kết quả của bước trước tự động được chuyển sang bước tiếp theo mà không cần bạn làm thủ công. Một số lệnh nổi bật như sau: /office-hours 6 câu hỏi buộc bạn suy nghĩ lại tính năng trước khi viết dòng code đầu tiên /plan-ceo-review tìm xem bạn đang làm quá nhiều hay quá ít so với thực tế cần /review bắt lỗi nghiêm trọng mà các công cụ kiểm tra tự động thông thường không thấy /qa mở trình duyệt thật, thao tác thật, tìm lỗi thật /cso chạy kiểm tra bảo mật theo chuẩn quốc tế tự động /ship đồng bộ, kiểm tra, đẩy code và tạo pull request trong một lệnh duy nhất Kết quả gstack hoạt động thế nào? Garry Tan cho biết tốc độ làm việc của ông năm 2026 nhanh hơn khoảng 810 lần so với năm 2013 khi đo bằng dòng code hoàn chỉnh mỗi ngày (11.417 so với 14 dòng). Trong 60 ngày, ông ship 3 dịch vụ production và hơn 40 tính năng, tất cả trong khi vẫn điều hành Y Combinator toàn thời gian. Andrej Karpathy, đồng sáng lập OpenAI, cũng chia sẻ rằng ông không gõ một dòng code nào kể từ tháng 12/2025 nhờ các tác nhân AI. Nhưng trong tất cả các lệnh đó, /office-hours là thứ đáng chú ý nhất vì một lý do ngược lại với phần còn lại, nó không giúp bạn làm việc nhanh hơn mà nó giúp bạn không làm nhầm thứ ngay từ đầu. Tại sao /office-hours lại được xếp đầu tiên Garry Tan đặt /office-hours ở đầu workflow vì một quan sát đơn giản: hầu hết các sản phẩm thất bại không phải vì code kém mà vì làm sai thứ mọi người cần. Họ bỏ hàng tuần viết một tính năng không ai cần, hoặc xây dựng đúng tính năng nhưng lại sai đối tượng, hoặc giải quyết một vấn đề mà người dùng đã có cách giải quyết tốt hơn từ lâu. Lệnh này có hai chế độ: Startup mode dành cho founder và người build sản phẩm thật, và Builder mode dành cho side project, hackathon, open source. Bài này tập trung vào Startup mode, nơi 6 câu hỏi được áp dụng đúng nghĩa nhất. 6 câu hỏi của /office-hours và tại sao mỗi câu đều đáng giá Đây không phải 6 câu hỏi để trả lời qua loa rồi tiếp tục đến các phần sau. Chúng được thiết kế để bạn suy nghĩ thật, vì câu trả lời càng trung thực thì kết quả Claude tạo ra càng bám sát đúng thứ bạn thực sự cần và bạn sẽ tiết kiệm được rất nhiều thời gian về sau. Bạn có thể xem nội dung gốc đầy đủ 6 cau hỏi tại office-hours/SKILL.md.tmpl. Demand reality: Nhu cầu có thật không? Câu hỏi gốc: "Ai cụ thể đang gặp vấn đề này? Họ đang giải quyết tạm bằng cách nào?" Không phải người dùng nói chung hay team marketing mà tác giả muốn hướng đến một người thật, có tên(càng tốt) đang vật lộn với vấn đề cụ thể là gì. Nếu bạn không biết được một người như vậy, bạn sẽ chưa thực sự hiểu họ cần gì. Ví dụ cụ thể: Thay vì "người dùng muốn quản lý task tốt hơn", phải là "Minh, project manager tại công ty 20 người, đang copy-paste giữa Notion và Google Sheet mỗi sáng thứ Hai vì hai tool không sync được." Tất nhiên đây là ví dụ mọi người tự áp dụng vào trường hợp của mình. Status quo: Họ đang dùng gì thay thế? Câu hỏi gốc: "Giải pháp thay thế tạm thời hiện tại của họ là gì? Bạn cần tốt hơn bao nhiêu để họ chịu đổi sang dùng giải pháp của bạn?" Mọi người đều đang giải quyết vấn đề theo một cách nào đó, dù là Excel, sticky note, hay nhóm chat WhatsApp. Nếu giải pháp hiện tại của họ đủ tốt, họ chẳng có lý do gì để chuyển dữ liệu và phải học sử dụng lại một nền tảng hoàn toàn mới, vì vậy giải pháp của bạn phải làm thực sự tốt hơn để họ còn cân nhắc. Desperate specificity: Ai đang cần giải pháp này đủ nhiều? Câu hỏi gốc: "Ai đang cần giải pháp đến mức có thể dùng bản beta xấu xí của bạn ngay hôm nay?" Đây là câu phân biệt "nice-to-have" và "must-have". Nếu bạn không tìm được ai sẵn sàng dùng một bản chưa hoàn chỉnh, chưa có UI đẹp, còn nhiều lỗi, thì vấn đề bạn đang giải quyết chưa đủ cấp bách. Người dùng thật của giai đoạn đầu là người cần đến mức họ chịu đựng được cả sản phẩm chưa đẹp nhưng có sửa đổi và hướng đi phù hợp. Narrowest wedge: Phần nhỏ nhất là gì? Câu hỏi gốc: "Phần nhỏ nhất có thể ra mắt ngày mai là gì? Không phải toàn bộ sản phẩm mà là phần nhỏ nhất." Không phải phiên bản đầu tiên đầy đủ tính năng mà là phần nhỏ hơn nữa. Câu hỏi này thường cắt bỏ 80% những thứ bạn tự thêm vào vì nghĩ "làm luôn cho tiện". Đây là lỗi mà mình rất hay bị khiến cho mọi thứ vượt tầm kiểm soát, phần này giúp mọi người ra mắt phần nhỏ nhất trước, lắng nghe phản hồi từ người dùng thật rồi mới quyết định mở rộng tiếp. Lưu ý: Nhiều người hay nhầm "phần nhỏ nhất" với "phiên bản đầu tiên đầy đủ tính năng". Thực ra phần nhỏ nhất đúng nghĩa có thể chỉ là tính năng nhỏ giải quyết một vấn đề duy nhất, cho một nhóm người dùng duy nhất, không hơn không kém. Observation and surprise: Bạn đã xem người thật dùng chưa? Câu hỏi gốc: "Bạn đã ngồi xem người thật dùng sản phẩm chưa? Họ dùng theo cách bạn không ngờ không?" Câu hỏi này có lẽ nên để cho vòng lặp thứ hai trở đi, khi bạn đã có bản thử nghiệm trong tay. Thay vì hỏi cảm nhận qua tin nhắn hay khảo sát, hãy ngồi xem trực tiếp hoặc xem lại video ghi màn hình khi họ dùng. Những phát hiện đáng giá nhất thường không phải từ lời họ nói mà từ những thao tác họ làm mà bạn không thiết kế, hoặc những bước họ bỏ qua dù bạn nghĩ là quan trọng. Lưu ý: Nếu bạn đang ở vòng đầu tiên và chưa có sản phẩm nào, mình nghĩ có thể bỏ qua câu này và quay lại sau khi đã ra mắt phần nhỏ nhất ở bước 4. Future-fit: Tầm nhìn 2 đến 3 năm Câu hỏi gốc: "2-3 năm nữa, thứ bạn đang build có còn phù hợp không, hay trend đang đi ngược lại?" Không phải để dự đoán tương lai chính xác, mà để tránh build thứ đang chết dần. Nếu xu hướng đang làm cho vấn đề bạn giải quyết trở nên ít cấp bách hơn trong 2 năm tới, đó chắc chắn là tín hiệu cần xem xét lại từ đầu còn nếu bạn muốn đánh nhanh thắng nhanh để tránh big tech ra sản phẩm giống hệt bạn thì hãy bỏ qua câu hỏi này. Ví dụ thực tế: một ý tưởng tưởng đơn giản bị lật ngược hoàn toàn Trong tài liệu của gstack, Garry Tan lấy một ví dụ rất thực tế. Bạn mở /office-hours và nói: "Tôi muốn làm một app tóm tắt lịch làm việc hàng ngày." Claude không đồng ý ngay và bắt đầu làm theo. Thay vào đó, nó phản hồi: thứ bạn vừa mô tả không chỉ là app tóm tắt lịch mà thực chất là một trợ lý cá nhân AI toàn diện. Hai thứ này khác nhau hoàn toàn về quy mô, độ phức tạp kỹ thuật và kỳ vọng của người dùng. Chỉ từ một câu mô tả ban đầu, /office-hours giúp bạn nhìn ra: 5 tính năng bạn đang mô tả mà chưa nhận ra 4 giả định cần kiểm chứng trước khi bắt tay làm 3 hướng triển khai khác nhau với mức độ phức tạp khác nhau 1 gợi ý: ra mắt phần nhỏ nhất trước, phần còn lại để làm dần về sau Toàn bộ quá trình đó xảy ra rồi cho ra kết quả sẽ được lưu lại thành tài liệu để các bước tiếp theo trong quy trình tự động đọc và tiếp tục. Khả năng mở rộng của 6 câu hỏi này ra ngoài repo gstack 6 câu hỏi của /office-hours không phụ thuộc vào Claude Code, không cần cài gstack. Chúng là tư duy, cách YC partners ngồi đánh giá startup, và bạn có thể áp dụng ngay hôm nay bằng bất kỳ công cụ AI nào đang dùng. Sự khác biệt khi dùng qua gstack là khi Claude sẽ không để bạn trả lời qua loa. Nó giúp Claude hiểu yêu cầu cụ thể hơn và nó không tiếp tục cho đến khi câu trả lời đủ thực tế. Đó là lý do vì sao/office-hours là skill đáng sợ nhất trong cả repo, không phải vì nó khó dùng, mà vì nó hỏi đúng thứ bạn đang bỏ qua. Thử ngay hôm nay: Trước khi làm sản phẩm tiếp theo, paste 6 câu hỏi trên vào Claude, Gemini, hay ChatGPT cùng với mô tả ý tưởng của bạn. Yêu cầu nó hỏi từng câu một và không cho phép bạn bỏ qua. Kết quả thường bất ngờ hơn bạn nghĩ, kể cả với những ý tưởng bạn đã nghĩ rất kỹ. gstack hiện có hơn 117k lượt star trên GitHub và vẫn đang tăng. Với mình, phần đáng giá nhất không phải các lệnh kỹ thuật như /review hay /ship, mà chính là /office-hours vì đây là lệnh duy nhất trong cả bộ công cụ buộc bạn dừng lại và suy nghĩ trước khi làm bất cứ điều gì.