Claude Code gửi 33.000 token trước khi đọc prompt, OpenCode gửi 7.000 token

• Khi đo tại ranh giới API trên cùng mô hình, máy và tác vụ, phần overhead cố định của yêu cầu đầu tiên với Sonnet 4.5 là khoảng 32.800 token với Claude Code và khoảng 6.900 token với OpenCode, chênh 4,7 lần; với Fable 5, mức chênh giảm còn khoảng 3,3 lần
• Phần lớn chênh lệch đến từ schema công cụ. Claude Code dùng khoảng 24.000 token cho định nghĩa 27 công cụ, còn OpenCode dùng khoảng 4.800 token cho 10 công cụ; ngay cả khi tắt toàn bộ công cụ, system prompt vẫn lần lượt khoảng 6.500 token và 2.000 token
• Trong cấu hình thực tế, một tệp lệnh 72KB thêm khoảng 20.000 token vào mỗi yêu cầu, một máy chủ MCP nhỏ thêm khoảng 1.000~1.400 token, khiến riêng yêu cầu đầu tiên có thể lên tới 75.000~90.817 token
• Trong cùng tác vụ tóm tắt tệp, Claude Code tạo ra cache write nhiều hơn OpenCode 5,9~54 lần; khi phân tán tác vụ cho hai sub-agent, mức dùng token tăng 4,2 lần, từ 121.000 token khi chạy trực tiếp lên 513.000 token
• Không thể đánh giá toàn bộ chi phí chỉ bằng overhead cố định. Trong tác vụ nhiều bước, Claude Code gom các lệnh gọi công cụ chạy song song nên dùng khoảng 121.000 token qua 3 yêu cầu, trong khi OpenCode gọi tuần tự 9 lần và dùng khoảng 132.000 token

---

Phương pháp đo tại ranh giới API

• Đặt proxy ghi log giữa Claude Code/OpenCode và API để ghi lại chính xác yêu cầu JSON do harness gửi và khối usage do API trả về
  • Thân yêu cầu gồm các system block, schema công cụ và message
  • Usage gồm input token, cache write/read và output token
  • Thân yêu cầu đã bắt được dùng làm nội dung thực sự được gửi, còn khối usage của API làm cơ sở cho lượng tính phí thực tế
• So sánh mặc định dùng Claude Code 2.1.207 và OpenCode 1.17.18, cả hai cố định ở claude-sonnet-4-5 tính đến tháng 7/2026
  • Một phần các phép đo overhead cố định, thao tác cache và tác vụ nhiều bước được chạy lại với claude-fable-5
  • Cô lập giá trị mặc định trong thư mục cấu hình mới, không có máy chủ MCP, thiết lập người dùng hay bộ nhớ, và workspace trống không có tệp lệnh
• Đo các cấu trúc chi phí khác nhau bằng ba tác vụ
  • T1 dùng Reply with exactly: OK để tách overhead cố định, chạy 3 lần với mỗi harness
  • T2 yêu cầu đọc và tóm tắt một tệp đã chuẩn bị sẵn
  • T3 thực hiện quy trình viết, chạy, kiểm thử và sửa với FizzBuzz cùng script kiểm tra
• Để so sánh system prompt không bao gồm schema công cụ, áp dụng --tools "" cho Claude Code và "tools": {"*": false} cho OpenCode
• Gateway LLM cục bộ thêm một lớp bao cố định khoảng 6.200 token vào mỗi yêu cầu, nên phần này được hiệu chỉnh rồi loại khỏi số đo
  • Số liệu theo từng thành phần được tính từ thân yêu cầu đã bắt, phần gateway không thể thay đổi
  • Chuyển đổi ký tự/token dùng tỷ lệ 4,1~4,4 ký tự trên 1 token theo từng harness, đo trong điều kiện cache lạnh

Schema công cụ làm tăng overhead mặc định

• Trong yêu cầu đầu tiên của prompt T1 chỉ dài 22 ký tự, Claude Code gửi khoảng 32.800 token, còn OpenCode gửi khoảng 6.900 token
  • System prompt của Claude Code gồm 3 block, 27.344 ký tự; OpenCode gồm 1 block, 9.324 ký tự
  • Schema 27 công cụ của Claude Code dài 99.778 ký tự, còn 10 công cụ của OpenCode dài 20.856 ký tự
  • Claude Code chèn một block <system-reminder> dài 7.997 ký tự trước prompt thực tế, chứa loại agent, skill khả dụng và ngữ cảnh người dùng
  • OpenCode gửi system block, 10 công cụ lập trình và prompt người dùng mà không có scaffolding message đầu tiên riêng
• Ở cả hai bên, định nghĩa công cụ chiếm tỷ trọng lớn nhất
  • Trong khoảng 33.000 token của Claude Code, khoảng 24.000 token là định nghĩa công cụ
  • Trong khoảng 6.900 token của OpenCode, khoảng 4.800 token là định nghĩa công cụ
  • Công cụ của Claude Code không chỉ có chức năng lập trình mà còn gồm các tính năng agent nền và orchestration như CronCreate, Monitor, nhóm Task, quản lý cây công việc và thông báo đẩy
• Khi loại bỏ toàn bộ công cụ, system prompt của Claude Code là 26.891 ký tự, khoảng 6.500 token; OpenCode là 8.811 ký tự, khoảng 2.000 token
  • Cả hai harness đều có prompt giảm nhẹ khi công cụ bị vô hiệu hóa
  • Phần chênh còn lại đến từ hướng dẫn hành vi như giọng điệu, chỉ dẫn an toàn, quy tắc quản lý công việc và thông tin môi trường
• Với Fable 5, Claude Code rút gọn prompt tùy mô hình nên chênh lệch giảm còn khoảng 3,3 lần
  • System instruction giảm từ 27.787 ký tự ở Sonnet xuống 10.526 ký tự ở Fable
  • Vẫn giữ cùng 27 công cụ nhưng schema cũng giảm từ 99.778 ký tự xuống 82.283 ký tự
  • Yêu cầu của OpenCode giống hệt nhau ở cấp byte trên cả hai mô hình

Tổng mức sử dụng thay đổi theo dạng tác vụ

• Ở T2, tác vụ đọc và tóm tắt một tệp, cả hai harness đều cho kết quả chính xác nhưng cấu trúc yêu cầu khác nhau
  • Claude Code dùng 6 yêu cầu HTTP và tổng input khoảng 199.000 token
  • OpenCode dùng 4 yêu cầu và khoảng 41.000 token, cộng thêm 1 lệnh gọi Haiku để tạo tiêu đề phiên
  • Phần lớn usage là cache read, được tính phí bằng 1/10 giá input
• Dù có giảm giá cache, cache write ở yêu cầu đầu tiên, cache read ở mỗi lượt và mức chiếm dụng cửa sổ ngữ cảnh đều tăng theo kích thước payload
  • Baseline 33.000 token đã chiếm khoảng 1/6 cửa sổ 200.000 token ngay trước khi có mã nguồn
• Ở T3, tác vụ viết, chạy, kiểm thử và sửa, cách gọi công cụ bù lại khác biệt overhead mặc định
  • Claude Code gom 2 lần ghi tệp và 2 lần chạy script vào một vòng công cụ song song, ghi nhận 3 yêu cầu mô hình và tổng input khoảng 121.000 token
  • OpenCode chỉ gọi một công cụ mỗi lượt, ghi nhận 9 yêu cầu và 1 lệnh gọi tiêu đề, tổng input khoảng 132.000 token
  • Tổng input nhìn chung được quyết định bởi tích của baseline mỗi yêu cầu và số yêu cầu, cộng thêm phần tăng của hội thoại
• Khi hội thoại tiến triển, Claude Code tăng số <system-reminder> từ 3 ở lượt đầu lên 4 tại thời điểm vòng công cụ đầu tiên
• Payload bổ sung theo lượt của OpenCode khoảng 400~2.200 ký tự, chỉ tăng theo nội dung hội thoại

Token do cấu hình thực tế thêm vào

• Khi thêm AGENTS.md 72KB của kho production, cả hai harness đều tăng hơn 20.000 token mỗi yêu cầu
  • Số đo OpenCode tăng từ 13.152 token lên 33.336 token
  • Claude Code tăng từ 39.005 token lên 59.243 token
  • Claude Code 2.1.207 bỏ qua AGENTS.md; phải đổi tên thành CLAUDE.md thì mới chèn vào user message đầu tiên
  • OpenCode đọc cả hai tên tệp và chèn vào system prompt
  • Nếu không kiểm tra tên tệp mà harness thực sự nhận diện, tệp lệnh có thể bị âm thầm bỏ qua
• Một máy chủ MCP nhỏ dạng công khai thêm khoảng 1.000~1.400 token mỗi yêu cầu cho mỗi server
  • 5 server thêm 4.900 token vào payload của Claude Code và 6.967 token vào số đo OpenCode
  • Số công cụ tăng từ 27 lên 69 với Claude Code, và từ 10 lên 52 với OpenCode
  • Server production có API phong phú có thể gửi schema lớn hơn
  • Chế độ print của Claude Code âm thầm bỏ qua .mcp.json ở phạm vi dự án nếu không có --mcp-config rõ ràng, nên cần xác nhận kết nối tại ranh giới API
• Các framework workflow dựa trên story như BMAD mở rộng persona, protocol và checklist dạng template lớn bằng slash command
  • Bản thân template 8.405 ký tự trong thử nghiệm tương đương khoảng 2.100 token, nhưng khi vào lịch sử hội thoại sẽ được gửi lại trong mọi yêu cầu sau đó
  • Trong phiên có 9 yêu cầu, cùng một template được nạp 9 lần, nên chi phí tăng theo kích thước template × số yêu cầu
• Yêu cầu đầu tiên trong cấu hình thực tế lớn hơn nhiều so với overhead mặc định
  • OpenCode dùng 11 máy chủ MCP cho email/lịch, quản lý tác vụ, quản lý tham khảo, phân tích sản phẩm, cùng tệp lệnh 72KB; ghi nhận 179 công cụ, schema 277KB và cache write lạnh 90.817 token
  • Claude Code dùng 4 máy chủ MCP, plugin đã cài và cùng tệp lệnh, ghi nhận 118 công cụ, payload 311KB và khoảng 75.000 token
  • Nếu loại trừ lớp bao gateway, cấu hình OpenCode lớn gấp khoảng 12 lần mặc định khoảng 7.000 token

Chi phí của sub-agent và extended thinking

• Khi Claude Code phân tán tác vụ song song cho hai sub-agent, mức 121.000 token khi chạy trực tiếp tăng lên 513.000 token, tức 4,2 lần
  • Có tổng cộng 9 yêu cầu mô hình qua ba loại yêu cầu: phiên chính, lệnh gọi sub-agent, v.v.
  • 5 lệnh gọi sub-agent mỗi lần tự bootstrap bằng system prompt 3.554 ký tự và 24 công cụ trong 27 công cụ mặc định
  • Cấu trúc là mỗi sub-agent chịu chi phí ban đầu, rồi parent lại đọc lịch sử thực thi của nó
• Sub-agent của OpenCode gửi một profile rút gọn chỉ dùng system prompt 1.379 ký tự và 5 công cụ
  • Vì quá trình chạy qua gateway không hoàn tất bình thường, tổng usage sub-agent của OpenCode không được định lượng
  • Chỉ so sánh khác biệt thiết kế quan sát được trong payload đã bắt
• Output extended thinking được tính theo giá output, cao gấp 5 lần đơn giá input, và các block suy luận đi vào lịch sử hội thoại rồi được gửi lại trong các yêu cầu sau
  • Do chính sách thinking của gateway khiến không thể xác nhận cấu hình của hai harness có thực sự được áp dụng hay không, số liệu đo không được công bố
  • Chỉ giữ lại cấu trúc chi phí khi block suy luận tham gia vào lịch sử làm đối tượng xác nhận

Tính kinh tế và độ ổn định của prompt cache

• Cả hai harness đều đặt cache breakpoint đúng. Payload được ghi một lần theo TTL 5 phút với giá 1,25 lần giá input cơ bản, rồi các lần sau được đọc với giá 1/10
• Có ba loại chi phí cache không giảm được
  • Nếu gián đoạn hơn 5 phút, toàn bộ stack phải được ghi lại, nên chi phí write tái phát sau các khoảng nghỉ như họp hoặc ăn
  • Cache read cũng lặp lại theo số yêu cầu, nên vòng lặp công cụ tuần tự và phân tán sub-agent làm tăng chi phí
  • Mức chiếm dụng cửa sổ ngữ cảnh không chịu ảnh hưởng của giảm giá cache; bootstrap 85.000 token chiếm hơn 40% cửa sổ 200.000 token, và khi bắt đầu nén còn phát sinh thêm chi phí tóm tắt
• OpenCode duy trì prefix giống hệt ở cấp byte trong mọi yêu cầu và lần chạy đã bắt
  • Trong ba phiên T1, byte của công cụ, system và message giống nhau; cache write của các lần chạy lặp lại là 0
  • Phiên T3 gồm 9 yêu cầu cũng giữ một prefix ổn định
• Claude Code tạo các loại yêu cầu và mục cache khác nhau theo từng phiên: thăm dò warm-up, hội thoại chính, lệnh gọi sub-agent
  • Ngay trong cùng workspace, byte system và scaffolding message đầu tiên cũng thay đổi theo từng lần chạy
  • Trong cùng tác vụ tóm tắt tệp, nó ghi 53.839 cache token qua 5 yêu cầu và ghi lại toàn bộ prefix khoảng 43.000 token một lần ở giữa tác vụ
  • Cache write của OpenCode trong cùng tác vụ là 1.003 token
• Việc Claude Code ghi lại cache lớn ở giữa phiên cũng xuất hiện trong các thử nghiệm lặp lại
  • Hai lần chạy đầu lần lượt ghi lại 43.342 token và 36.899 token; lần chạy thứ ba dùng cache vừa warm nên gần như không ghi
  • Với Fable 5, nó cũng ghi lại 50.053 token mà không có cache read, tạo chênh lệch 52 lần, tương tự mức 54 lần của Sonnet
  • Tùy độ nóng của cache, lượng cache write của Claude Code cao hơn OpenCode 5,9~54 lần
  • Đơn giá cache write là 1,25 lần giá cơ bản ở tầng 5 phút và 2 lần ở tầng 1 giờ
• Một lần cache miss đơn lẻ có thể do gateway eviction, nhưng hiện tượng này tái lập qua nhiều lần chạy và độ bất ổn prefix cũng được xác nhận từ byte bắt được trước yêu cầu
  • Khi prefix lớn, có nhiều loại, bị ghi lại lặp lại và cộng thêm sub-agent, bảng usage của Claude Code có thể tăng nhanh hơn

Chất lượng kết quả và audit log

• Cả hai harness đều hoàn thành chính xác mọi tác vụ được đánh giá
  • Kết quả tóm tắt tệp đều chính xác
  • Tác vụ nhiều bước đều vượt qua script kiểm chứng do từng harness viết và kết thúc bình thường
  • Trong phạm vi này, có thể so sánh chênh lệch chi phí token cần để đạt cùng kết quả
• Chưa đo liệu agent nền, skill và orchestration của Claude Code trong các tác vụ kỹ thuật thực tế khó hơn có nâng chất lượng tương xứng với chi phí bổ sung hay không
  • Để đánh giá điều đó cần bộ kiểm thử phù hợp, đủ số lần chạy lặp và đánh giá tỷ lệ pass riêng
• Cũng xác nhận được những lãng phí không liên quan đến chất lượng
  • Ghi lại giữa phiên một cache prefix giống hệt ở cấp byte tương đương mua lại cùng nội dung với giá premium
  • Nếu harness âm thầm bỏ qua tệp lệnh, sẽ không thu được bất kỳ lợi ích nào từ tệp đó
• 185 bản ghi yêu cầu/phản hồi đã bắt được ghi vào chuỗi hash SHA-256 bằng thư viện mã nguồn mở @systima/aiact-audit-log
  • Chuỗi được xác minh đến cuối không gián đoạn và kết quả toàn vẹn là VALID
  • Có thể tái dựng nội dung gửi/phản hồi theo cùng cấu trúc và cung cấp dữ liệu toàn vẹn cho bên thứ ba
  • Đây là cùng cách ghi bản ghi có cấu trúc được cung cấp cho logging theo EU AI Act Article 12

Giới hạn của phép đo và cách tái lập

• Kết quả là snapshot tháng 7/2026 trên một máy, hai phiên bản harness và mẫu nhỏ
  • T1 và T2 mỗi tác vụ chạy 3 lần, mỗi điều kiện hệ số cấu hình chạy 1 lần
  • Điều kiện mặc định và cache dùng Sonnet 4.5 và Fable 5, còn điều kiện hệ số cấu hình chỉ dùng một mô hình
  • Prompt của harness thay đổi thường xuyên, nên phương pháp đo tại ranh giới API sẽ bền hơn các con số riêng lẻ
• Có gateway cục bộ trong đường đo
  • Số liệu thành phần dùng thân yêu cầu mà gateway không thể thay đổi
  • Số đo được hiệu chỉnh lớp bao cố định bằng mốc cache lạnh, còn các số warm run không phân biệt được nguyên nhân thì bị loại trừ
  • Đã có trường hợp gateway âm thầm thay mô hình bằng snapshot mới hơn mô hình được cố định, nên cũng cần xác nhận mô hình thực sự phản hồi tại ranh giới
  • Trên đường Fable xảy ra việc tiếp tục phiên server cũ và chạy công cụ phía host, nên kết quả Fable nhiều bước của Claude Code bị loại trừ
• Sự hội tụ chi phí của T3 là một quan sát duy nhất từ một dạng tác vụ
  • Với tác vụ bắt buộc phải chạy tuần tự, số yêu cầu và tổng usage của Claude Code có thể tăng trở lại
  • Điều kiện loại bỏ công cụ và sub-agent của OpenCode trả về stream sai qua gateway, nên chỉ dùng kích thước payload đã bắt
  • Số liệu cấu hình thực tế là thiết lập của một người dùng và có thể khác trong môi trường khác
• Thiết bị tái lập là một HTTP proxy gồm khoảng 200 dòng Node code
  • Proxy chuyển tiếp yêu cầu tới model endpoint đồng thời ghi thân yêu cầu và khối usage phản hồi ra đĩa và chuỗi audit
  • Đặt ANTHROPIC_BASE_URL trỏ tới proxy, đo mặc định trong thư mục cấu hình mới và workspace trống, rồi lần lượt thêm tệp lệnh, máy chủ MCP và workflow
  • Nếu dùng gateway, trước tiên cần đo lớp bao của chính nó bằng yêu cầu tối thiểu và xác nhận mô hình nào thực sự phản hồi
  • Nếu có logging tại ranh giới API để tái dựng chính xác nội dung agent production đã gửi tới mô hình tại một thời điểm cụ thể, bạn cũng có được sổ sách token kèm theo

[GN⁺]

Ý kiến trên Hacker News

• Thứ thực sự đốt rất nhiều token là sub-agent. Tôi giao một tác vụ lớn cho Claude Code thì nó lập tức khởi chạy 7 sub-agent, và tiêu hết ngân sách trước khi có cái nào hoàn thành. 5 giờ sau thử lại vẫn y như vậy
  Nếu để agent chính thực hiện cùng tác vụ đó tuần tự thì hoàn toàn không có vấn đề. Tôi không biết nó kém hiệu quả như vậy là do chi phí giao tiếp và điều phối, hay vì người dùng sub-agent thường dùng tài khoản doanh nghiệp và trả theo token nên Anthropic muốn tăng doanh thu

  • Ngược lại, ở giai đoạn khám phá và lập kế hoạch cho các dự án phức tạp, hành vi tò mò của Fable có thể chính xác là thứ cần thiết. Nếu không chỉ muốn agent điều phối chia prompt thành nhiều góc nhìn khám phá, mà còn muốn từng sub-agent điều tra codebase theo góc nhìn đó và mở rộng đệ quy các manh mối mới, thì dùng Fable ở mọi bước là hợp lý
    Còn nếu muốn áp dụng song song một tác vụ đã được lên kế hoạch tốt lên nhiều mục tiêu, thì cần nói rõ để sub-agent hạ cấp xuống model ít tò mò hơn. Tính nhất quán của kết quả cũng có thể tốt hơn
  • Mỗi sub-agent phải đọc lại một phần codebase để có được ngữ cảnh cần cho tác vụ. Khi tác vụ kéo dài, ngữ cảnh của agent điều phối cũng biến mất khỏi cache, nên sau khi sub-agent kết thúc lại phải trả toàn bộ chi phí lần nữa
    Nếu chạy tuần tự, các file về cơ bản chỉ bị đọc khoảng một lần và mọi request đều tận dụng cùng prefix cache
  • Nếu khách hàng chọn gói đắt hơn để né vấn đề, công ty sẽ có động lực tiêu cực trong việc sửa vấn đề đó. Dù có vài kỹ sư có giải pháp, họ vẫn có thể gặp phải sự thờ ơ của số đông, sự cản trở của một số người, và đôi khi là sự đối địch chủ động ở đâu đó trong tầng quản lý
    Trong môi trường như vậy, chiến lược tốt nhất có thể là đưa tính năng mới lên gói cao nhất trước để thu hồi chi phí rồi mới hạ xuống các gói thấp hơn, hoặc rút thang lên để đối thủ khó bắt kịp
  • Mỗi sub-agent đều gửi cùng một system prompt khoảng 30 nghìn token. Nếu dùng Fable/Opus, 7 agent dễ dàng tiêu hết 30% hạn mức sử dụng 5 giờ trước cả khi chúng bắt đầu làm việc
  • Sau khi học được mẹo này, tôi đang cấm rõ ràng sub-agent Fable. Hôm qua, sau một đợt refactor lớn, tôi yêu cầu lập kế hoạch review trước để xem xét mã phức tạp; ở bước đầu nó đề xuất 8 agent Fable và 1 agent để xác minh kết quả, nên tôi phê duyệt
    Nhưng ở bước xác minh, nó định khởi chạy 41 agent xác minh Fable. Kiểu gì nó cũng tìm ra đường vòng

• Tôi cho rằng Claude Code dùng nhiều token là để Anthropic kiếm nhiều tiền hơn và đẩy người dùng vào gói thuê bao. Chính sách không cho dùng quyền thuê bao trong các coding agent khác cũng củng cố điều này. Tôi dùng pi

  • Khi nhìn Anthropic như một người bán token, nhiều quyết định bắt đầu trở nên dễ hiểu. Chừng nào người dùng chưa phản ứng hoặc yêu cầu cơ chế bảo vệ, họ sẽ tiếp tục tạo ra lý do để người dùng tiêu nhiều token hơn qua kênh của họ
  • Tôi từng thấy trong hồ sơ liên quan đến IPO rằng doanh thu thuê bao rất nhỏ, khoảng 5%. Tuy nhiên 5% đó là thuê bao Claude cá nhân, còn phần lớn thuê bao Claude Code có lẽ được tính vào mảng doanh nghiệp
    API và enterprise chiếm 75–85% tổng doanh thu, thuê bao doanh nghiệp khoảng 10–15%, thuê bao cá nhân khoảng 5%
  • Thực ra logic phải ngược lại. Người dùng thuê bao trả phí cố định hằng tháng, nên Anthropic có động lực để Claude Code dùng ít token hơn
  • Mặt khác, hành vi như vậy cũng làm tăng mức tiêu thụ token của người dùng thuê bao thông thường vốn nằm trong gói phí cố định. Trông giống bất tài hơn là ác ý

• Như phép so sánh hợp lý của PUSH_AX, chuyện này giống tình huống nhà thầu A đòi 33 nghìn đô còn B đòi 7 nghìn đô, nên ta cần xem liệu mình có đang đo đúng đối tượng hay không
  Theo đó, bài viết sẽ được bổ sung các tác vụ chuyên sâu hơn, so sánh kết quả định tính, và dữ liệu tái hiện input/output nhanh nhất có thể

  • Tôi thắc mắc liệu một phần đáng kể trong 33 nghìn token có phải là dữ liệu ngữ cảnh như cuộc trò chuyện gần đây hay không

• Vấn đề không chỉ là system prompt lớn. Môi trường chạy coding agent cũng đang dùng công cụ hung hăng hơn ngay cả với các yêu cầu nhỏ nhặt. Trong thử nghiệm, các prompt như “Hey” hay “commit” đôi khi gây ra hơn 30 lần gọi công cụ
  https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
  Có thể thấy rõ lạm phát token, tức số token mà các tác vụ đơn giản tiêu thụ cứ tiếp tục tăng

  • Thật khó chịu khi Opus sửa một lỗi chính tả trong comment rồi chạy mọi thứ có thể chạy như test và lint. Nó còn tạm stash các thay đổi hiện tại để chủ động kiểm tra xem tất cả test vốn đã pass chưa
    Tôi cũng có lỗi vì đã ghi trong rule rằng phải xác minh mọi thay đổi bằng test, nhưng nếu đã nhấn mạnh chữ I trong AI đến vậy thì tôi cũng kỳ vọng nó có đủ phán đoán để không bỏ cà chua vào salad trái cây
  • Khi nhận prompt mơ hồ như “Hey” hay “commit”, nó sẽ lục lại hội thoại trước đó và các ngữ cảnh khác để suy luận việc cần làm, khiến số lần gọi công cụ tăng lên. Prompt rõ ràng hơn thì tốt hơn
  • Việc commit thì chẳng phải tự làm cũng được, không cần giao cho LLM sao?

• Sau 6 tháng dùng Claude, gần đây tôi đã chuyển sang Codex. Codex cởi mở hơn, dễ theo dõi quá trình làm việc của model hơn, và trải nghiệm người dùng trong luồng phê duyệt cũng tốt hơn. Nhìn chung minh bạch hơn, và chi phí chuyển đổi gần như bằng 0
  Tôi không thích việc Claude trở nên kém minh bạch hơn từ khoảng tháng 2, kể cả system prompt, và 33 nghìn token trông là quá nhiều

  • Hiện tôi dùng cả hai, và thực tế gần như có thể dùng thay thế cho nhau. Tôi cũng thích việc Codex là mã nguồn mở và OpenAI nói rõ rằng có thể dùng quyền thuê bao trong các agent khác
    Gần đây OpenAI đã trở nên thân thiện với người tiêu dùng hơn nhiều
  • Tôi tò mò sau khi nó kém minh bạch hơn thì bạn đã thử những thiết lập nào. Hiện giờ có nhiều mục cài đặt hơn rất nhiều

• Tác nhân pi có system prompt nhỏ hơn, và có thể xem toàn bộ nội dung tại đây
  https://github.com/earendil-works/pi/blob/main/packages%2Fco...

  • Có thể liên quan đến kiểu tối giản này, nhưng Pi thiếu hầu hết các công cụ cần thiết để LLM hoạt động hiệu quả và hiệu suất. Tôi hiểu triết lý bắt đầu từ một nền trống rồi thêm những gì mình muốn, nhưng theo tiêu chuẩn của tôi thì nó quá trống
  • Tôi thắc mắc liệu việc đặt ngày và cmd mỗi lần gọi system prompt có làm vô hiệu hóa cache hay không
    Nếu chỉ bị vô hiệu hóa khi ngày hoặc thư mục gốc thay đổi thì thực tế chuyện đó cũng đủ hiếm
  • Nếu cần một tác nhân tối thiểu để tùy biến mạnh, tốt hơn là tự làm thay vì kéo về hơn 130 phụ thuộc bắc cầu trong gói pi-coder “tối thiểu”. Không khó, học được nhiều, và ở bước khởi đầu cũng có thể nhờ LLM khác giúp

• Rốt cuộc điều quan trọng không phải là kích thước prompt thô. Nếu vậy thì Pi và các biến thể của nó phải có chi phí thấp nhất. Cốt lõi là tính hiệu quả của prompt, và chủ nghĩa tối giản prompt thường bị nhầm với hiệu quả prompt. Dù vậy Claude Code trông vẫn cồng kềnh so với những việc nó làm
  Điều còn quan trọng hơn là chất lượng công cụ. Công cụ tệ hoặc có lỗi sẽ làm số lượt gọi qua lại tăng mạnh, xóa sạch mọi lợi thế mà ban đầu định tiết kiệm
  Vài tháng trước, tôi đã benchmark đầy đủ 7 tác nhân trên 8 tác vụ, dữ liệu và trace có tại https://github.com/dirac-run/dirac. Tôi có liên quan trực tiếp đến một trong số đó nên không thể tuyên bố trung lập, nhưng đây là tài liệu có thể tái lập. Phần lớn tác vụ liên quan đến refactor, nên Dirac, vốn mạnh ở neo bằng hash và phân tích cây cú pháp trừu tượng, thắng với khoảng cách lớn

  • Có nhiều đối thủ và cạnh tranh rất khốc liệt, nên nếu có dư địa cải thiện thì ai đó sẽ hiện thực hóa, và sau đó khả năng cao là nó sẽ lan nhanh sang các sản phẩm khác

• Ở chỗ làm tôi bị buộc phải dùng Claude Code, nhưng dùng --system-prompt "" là giải quyết đơn giản. Giá mà họ cũng cho phép các môi trường chạy khác

  • Nếu để trống bằng --system-prompt "" thì chẳng phải ngay cả system prompt cơ bản để mô hình hiểu các công cụ khả dụng cũng biến mất sao?
  • Tôi đã dùng như vậy từ lâu rồi, không hiểu sao mọi người không dùng
  • Tôi không biết tùy chọn này. Nếu có tài liệu phân tích hiệu quả thực tế trước/sau khi áp dụng hoặc biểu đồ hiệu năng trong môi trường sử dụng thực tế thì tôi muốn xem
  • Tôi thắc mắc tùy chọn này dùng khi khởi động Claude, hay được gửi kèm mỗi lần gửi prompt

• Khi lần đầu thử nghiệm mô hình local, tôi kết nối với Claude Code thì nó hoạt động rất tốt nhưng chậm
  Nhờ Claude hỗ trợ thiết lập mitmproxy và bắt toàn bộ system prompt đầu tiên của Claude Code, khi kiểm tra lại thì đó là JSON 162KB. Từ đó tôi bắt đầu thử nghiệm Pi, OpenCode, Hermes

  • Hiện khi chạy /context trong phiên mới của Claude Code, nó chỉ dùng 23 nghìn token trong ngữ cảnh 1 triệu token của Opus 4.8. Hiển thị là system prompt 3,9 nghìn, công cụ hệ thống 13,9 nghìn, tác nhân tùy chỉnh của người dùng 235, file bộ nhớ 28, tính năng 4,9 nghìn, tin nhắn 8, buffer nén 3 nghìn token
    System prompt 4 nghìn token tương đương khoảng 15–20KB. Tôi muốn nhờ bạn đưa nội dung đã bắt lên Gist, nhưng có thể có dữ liệu nhạy cảm, và rất có khả năng 162KB nhìn thấy không chỉ là system prompt

• Thứ tôi làm gửi ít hơn: https://maki.sh

  • Khi ngữ cảnh quá dài, maki được cho là sẽ loại bỏ ảnh và các khối suy luận, đồng thời tóm tắt cuộc trò chuyện trước đó để tự động nén lịch sử
    Nhưng tóm tắt cuộc trò chuyện trước đó về cơ bản chẳng phải sẽ vô hiệu hóa context cache, khiến dù dùng ít token hơn nhưng lại tiêu thụ token đắt hơn sao?