Flutter - free resource mobile app, desktop, web

Rào cản để thử một AI coding agent trước đây là một cái API key và một cái thẻ tín dụng. OpenCode gỡ cả hai: gateway Zen của nó cho bạn chọn model hosted và dùng ngay, không mất tiền, không cần key.

Nghĩa là lý do cuối cùng để chưa học cách làm việc với agentic coding đã biến mất. Nhưng cũng nghĩa là sắp có rất nhiều người chĩa một model miễn phí vào repo riêng tư mà chưa kịp nghĩ chuyện đó kéo theo cái gì.

Cả hai điều đều đáng coi trọng. Dưới đây là tier free thật sự tốt cho việc gì, nó lấy của bạn cái gì bằng một loại tiền tệ không phải tiền, và cách sắp xếp công việc để bạn không phải trả tiền cho một model frontier chỉ để đổi tên biến.

”Miễn phí” ở đây nghĩa là gì

Có ba thứ khác nhau bị gộp chung dưới một chữ, và giới hạn của chúng khác nhau:

Công cụ thì miễn phí. Bản thân OpenCode là mã nguồn mở. Không giới hạn ở phía client, không license theo ghế, không đo đếm. Cắm API key riêng của bạn từ bất kỳ nhà cung cấp nào thì nó hoạt động như mọi agent harness khác.

Model hosted miễn phí nhưng có quota. OpenCode Zen là gateway tích hợp sẵn. Tier free của nó chạy ở mức 0đ/tháng với khoảng 100 request mỗi ngày, không cần thẻ, được dùng dàn model Zen. Các model được nhóm theo tier chứ không bán lẻ từng con — một tier mặc định với context lớn, một tier nâng cao với cửa sổ context lớn nhất, và một tier fast với context nhỏ nhưng độ trễ thấp hơn hẳn.

Free không có nghĩa là unlimited, và cũng không có nghĩa là riêng tư. Đó là hai điều mọi người hay bỏ qua, và cũng là hai điều quan trọng nhất.

Quota nhỏ hơn bạn tưởng

100 request mỗi ngày nghe rộng rãi cho tới khi bạn ngồi nhìn một agent làm việc. Một câu “sửa cái test đang fail này” có thể đốt năm tới mười lăm request, vì agent đọc file, chạy test, sửa, chạy lại, rồi đọc lỗi lần nữa. Vòng lặp agentic ngốn request theo cụm.

Thực tế: hãy trông đợi vài task thật mỗi ngày, chứ không phải một ngày làm việc dùng agent liên tục. Để học thì ổn. Nhưng đó không phải workflow bạn dám cam kết với một deadline.

Cái giá còn lại là source code của bạn

Đây là phần đáng nói thẳng chứ không phải ghi chú cuối trang: ở tier free, prompt và output nhìn chung được lưu lại và dùng để cải thiện model về sau. Đó là mô hình kinh doanh. Có một model trong dàn được ghi rõ là không bao giờ lưu hay dùng dữ liệu của bạn để train — nếu bảo mật là yêu cầu bắt buộc, đó là con cần tìm và cần kiểm chứng lại với tài liệu hiện hành, vì mấy chính sách này thay đổi.

Có một câu hay được nhắc ở đây — nếu bạn không trả tiền cho sản phẩm thì chính bạn là sản phẩm — và trong trường hợp này nó không phải phép ẩn dụ. Cái được trả chính là code của bạn.

Cũng lưu ý rằng tên model và thành phần tier free thay đổi rất nhanh. Danh sách đã đổi hai lần chỉ trong mấy tháng trước khi bài này được viết. Hãy coi mọi tên model cụ thể bạn đọc trong một bài blog, kể cả bài này, là ảnh chụp tại một thời điểm. Xem danh sách model Zen để biết hôm nay cái gì đang miễn phí, và xem luôn chính sách dữ liệu ở cùng chỗ đó.

Thứ tuyệt đối không được đưa vào model tier free

Không phải kiểu “cẩn thận nhé” chung chung. Đây là danh sách:

• Mọi loại credential — API key, token, mật khẩu, connection string, nội dung .env, private key
• Source riêng tư mà bạn không có quyền tiết lộ — code của công ty, code của khách hàng, mọi thứ đang trong NDA
• Dữ liệu khách hàng — bản ghi người dùng thật, thông tin cá nhân, bất cứ thứ gì lấy từ database production
• Tài liệu nội bộ — tài liệu kiến trúc, hợp đồng, roadmap, biên bản sự cố
• Bất cứ thứ gì thuộc diện tuân thủ quy định — dữ liệu y tế, tài chính, hoặc bị quản lý bởi luật chuyên ngành

Nguyên tắc nằm dưới: nếu bạn cần xin phép mới dám email nó cho một người lạ, thì đừng dán nó vào một model mà bạn chưa đọc chính sách lưu trữ.

Có một cái bẫy riêng của agent mà chat không có: agent đọc cả những file bạn không đưa cho nó. Chĩa nó vào thư mục gốc của repo là nó có thể đọc .env, config/secrets.yml, hay một file fixture đầy dữ liệu khách hàng thật — không cái nào bạn cố ý gửi đi. Model chat chỉ thấy thứ bạn dán vào; agent thấy thứ nó tự mở ra.

Nên trước khi chạy bất kỳ agent nào, free hay trả phí, trên một repo bạn không tạo ra riêng cho mục đích đó:

git ls-files | grep -Ei '\.env|secret|credential|\.pem$|\.key$|token'

Cái gì hiện ra thì phải nằm trong .gitignore, nằm trong file ignore mà agent tôn trọng, hoặc bị dời hẳn ra khỏi cây thư mục.

Bậc thang nâng cấp

Mô hình tư duy hữu ích không phải là free-hay-trả-phí. Mà là ba bậc, khớp với thứ mà task thật sự cần:

Phần lớn mọi người làm ngược ở cả hai đầu. Họ chạy model frontier cho code boilerplate, và chạy model free cho con bug hiểm đã ăn mất hai ngày. Cả hai đều lãng phí — một bên phí token, một bên phí thời gian của chính bạn.

Dấu hiệu cần nâng bậc: nếu bạn đã prompt lại ba lần mà câu trả lời vẫn sai theo đúng một kiểu, thì model không phải nút thắt như bạn nghĩ. Hoặc nâng một bậc, hoặc — thường gặp hơn — prompt của bạn đang thiếu bối cảnh mà model không thể tự suy ra. Thử bổ sung bối cảnh trước; cái đó miễn phí.

Cách moi được việc thật sự hữu ích từ tier free

Model free nhỏ hơn và kém kiên nhẫn hơn. Hãy điều chỉnh công việc cho vừa, thay vì kỳ vọng nó hành xử như model frontier.

Giao việc nhỏ hơn. “Refactor module auth” là task của model frontier. “Trong auth/session.py, tách logic refresh token ra thành hàm riêng và cập nhật hai chỗ đang gọi” là task của model free. Phạm vi nhỏ cũng đốt ít request hơn, chuyện này rất đáng khi bạn chỉ có một trăm.

Chỉ đích danh file. Để agent tự mò xem file nào quan trọng vừa tốn request vừa hay sai với model nhỏ. Nêu thẳng ba file nó cần thì tiết kiệm cả hai.

Gom việc cơ học lại làm một lượt. Đổi tên, thêm type hint, chuyển bộ test từ kiểu assertion này sang kiểu khác, viết docstring từ signature có sẵn — đây đúng là thứ model free làm tốt, và kết quả thì kiểm tra rất rẻ.

Dùng nó để đọc codebase. Một trong những cách dùng tier free hay nhất là nhờ một model nhanh giải thích một repo lạ. “Trace xem chuyện gì xảy ra khi một request tới /api/orders” là việc rủi ro thấp, giá trị cao, và không cần khả năng suy luận của frontier.

Dùng tier fast cho việc nhanh. Tier fast context nhỏ thật sự tốt hơn tier context lớn cho việc tra cứu nhanh và sửa một file — độ trễ thấp hơn, và context bạn không dùng tới là context có thể gây nhiễu.

Lựa chọn miễn phí còn lại

Đáng biết: Hermes Agent cũng miễn phí và hoạt động qua nền tảng nhắn tin — bạn điều khiển agent từ Telegram hoặc Discord thay vì từ terminal. Trải nghiệm hoàn toàn khác. Nếu điều hấp dẫn bạn là bấm điện thoại giao việc rồi lát nữa đọc kết quả, thì cái này hợp hơn một công cụ CLI. Mọi lưu ý về dữ liệu vẫn giữ nguyên, cộng thêm một điểm: nền tảng chat còn giữ bản sao của mọi thứ bạn gửi.

Setup khởi đầu không khiến bạn trả giá

1. Cài OpenCode. Setup đúng là chỉ vài phút.
2. Bắt đầu trên repo của chính bạn và không chứa gì bảo mật. Không phải cái monorepo của công ty. Một dự án cá nhân.
3. Xem dàn model free hiện tại và chính sách dữ liệu tại opencode.ai/zen trước task thật đầu tiên, không phải sau.
4. Chạy lệnh quét secret ở trên trên bất kỳ repo nào trước khi chĩa agent vào.
5. Làm ba task thật — một lần sửa bug, một lần refactor nhỏ, một buổi nhờ giải thích code. Bấy nhiêu là đủ để biết công cụ có hợp với cách bạn làm việc không.
6. Khi thấy mình bắt đầu phụ thuộc vào nó, chuyển sang model trả phí tầm trung. Ngay khi output của agent đi vào công việc có người trả tiền, thì cả rate limit lẫn chính sách lưu trữ đều không còn chấp nhận được.

Bước 6 là bước mọi người hay hoãn, thường là hoãn tới lúc dính rate limit giữa sprint. Hãy chuyển trước lúc đó, đừng đợi sau.

Tóm lại cho thẳng thắn

Tier free là cách rất tốt để học và là cách rất tệ để ship hàng. Đó không phải lời chê — tier free sinh ra để làm đúng việc đó, và OpenCode còn khá sòng phẳng khi nói ra sự đánh đổi.

Học trên free. Làm việc trên trả phí. Chỉ nâng lên frontier khi task thật sự khó. Và đọc chính sách lưu trữ trước prompt đầu tiên, chứ không phải sau khi đã dán vào thứ không rút lại được.

Câu hỏi thường gặp

OpenCode miễn phí bản thân công cụ hay chỉ miễn phí model? Công cụ là mã nguồn mở và không đo đếm. Tier free của Zen là phần model hosted, có giới hạn request mỗi ngày. Bạn cũng có thể cắm API key riêng từ bất kỳ nhà cung cấp nào.

Thật sự được bao nhiêu request? Tier free được ghi ở mức khoảng 100 request mỗi ngày. Vòng lặp agent tiêu vài request cho mỗi task, nên hãy tính là vài task đáng kể mỗi ngày chứ không phải dùng liên tục.

Code của tôi có bị dùng để train không? Ở tier free thì nhìn chung là có — prompt và output được lưu lại và dùng để cải thiện model. Có ít nhất một model trong dàn được ghi rõ là không nằm trong diện này. Hãy kiểm chứng lại với tài liệu hiện hành, vì điều khoản có thay đổi.

Dùng cho việc của khách hàng được không? Không, nếu đó là tier free có chính sách giữ dữ liệu để train, trừ khi khách hàng đã đồng ý rõ ràng bằng văn bản. Hãy dùng tier trả phí có cam kết xử lý dữ liệu trong hợp đồng.

Nên bắt đầu với model free nào? Bắt đầu ở tier mặc định cho việc code nói chung, chuyển sang tier nâng cao khi task cần nhiều context hoặc nhiều suy luận hơn, và dùng tier fast cho việc nhanh trên một file. Tên model cụ thể thay đổi liên tục — hãy xem danh sách hiện tại thay vì tin bất kỳ bài blog nào, kể cả bài này.

Model miễn phí có đủ tốt để học agentic coding không? Có, và đó là lập luận mạnh nhất ủng hộ nó. Kỹ năng chia nhỏ task, cung cấp bối cảnh và kiểm chứng output chuyển sang model trả phí gần như nguyên vẹn. Kỹ năng mới là phần bền, không phải model.

Bài này khai triển từ một ghi chú đang lan truyền trong cộng đồng lập trình viên Việt Nam về các model miễn phí của OpenCode, mà những cảnh báo cốt lõi trong đó — free không phải unlimited, dữ liệu của bạn dùng để train model kế tiếp, tuyệt đối đừng dán secret — đều là những cảnh báo đúng. Tên model và quota trong bài phản ánh thời điểm viết và thay đổi thường xuyên; các link dẫn tới nguồn chuẩn hiện hành.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Sau nửa năm, setup AI của phần lớn mọi người trông giống hệt nhau: mười một con trợ lý tự tạo nhớ mang máng, một nghĩa địa tab trình duyệt, và cảm giác lấn cấn rằng cái mình mò ra hồi tháng Ba đang nằm đâu đó trong một cuộc chat không bao giờ tìm lại được.

Tạo agent là phần dễ. Nền tảng nào — Grok Bot, custom GPT, Claude Projects — cũng làm được trong hai phút. Thứ phân biệt một setup hữu ích với một mớ bừa bộn không phải là số lượng agent. Mà là chúng có dùng chung bối cảnh không, có báo cáo công việc không, và có chạy được khi bạn không ngồi đó không.

Chín thói quen dưới đây đưa bạn tới đó. Mình viết theo hướng không phụ thuộc nền tảng, vì mô hình này sống lâu hơn công cụ bạn đang xài năm nay.

Phần 1 — Dạy hệ thống hiểu bạn là ai

1. Phỏng vấn chính mình trước

Một đội ngũ agent chỉ tốt bằng mức nó hiểu tình hình của bạn. Mà phần lớn mọi người không bao giờ viết cái đó ra, vì nó chán và vì mình đã biết rồi.

Vậy thì để AI moi nó ra. Tạo một skill hoặc prompt lưu sẵn với nhiệm vụ duy nhất là chất vấn bạn — mỗi lần một câu, không gợi ý đáp án, cho tới khi nó tóm tắt lại chính xác công việc, mục tiêu và ràng buộc của bạn.

Bạn đang phỏng vấn tôi để dựng một tài liệu bối cảnh về công việc của tôi.

Quy tắc:
- Hỏi MỖI LẦN MỘT CÂU và chờ tôi trả lời.
- Không bao giờ gợi ý đáp án hay đưa lựa chọn sẵn.
- Câu trả lời nào mơ hồ thì hỏi tiếp, đừng bỏ qua.
- Cần bao phủ: hằng ngày tôi thật sự làm gì, tôi bị đánh giá dựa
  trên cái gì, ai phụ thuộc vào tôi, hiện đang tắc ở đâu, tôi đang
  né việc gì, và trong 90 ngày tới tôi muốn điều gì thành hiện thực.
- Dừng lại khi bạn tóm tắt được tình hình của tôi trong 10 gạch đầu
  dòng mà tôi sẽ gật đầu. Đưa 10 gạch đó ra và hỏi tôi sai chỗ nào.

Quy tắc cuối quan trọng hơn tất cả những cái còn lại. “Đưa bản tóm tắt ra và hỏi sai chỗ nào” là thứ biến một buổi phỏng vấn thành một vòng lặp sửa sai.

Chạy cái này trước khi lập kế hoạch quý, trước khi bắt đầu dự án, trước khi xây bất kỳ automation nào. Lưu kết quả lại. Nó trở thành bối cảnh chung mà mọi agent khác đều đọc.

Vì sao nó hiệu quả: bạn không phải viết tài liệu — thứ mà bạn sẽ chẳng bao giờ viết xong. Bạn chỉ trả lời câu hỏi, việc đó dễ hơn nhiều, còn phần viết thì thứ khác lo.

2. Chỉ một cửa ngõ duy nhất

Bạn có thể có agent cho content, research, lập kế hoạch và việc hành chính. Cái bạn không muốn là mỗi lần dùng lại phải nhớ con nào lo việc gì.

Chọn một agent làm cửa ngõ. Đặt tên cho nó — nói chuyện với Klaus thật sự dễ chịu hơn nói chuyện với Trợ lý 4. Mọi thứ đi qua nó.

Quy tắc vận hành của nó ngắn thôi:

Bạn là chief of staff của tôi. Bạn là agent duy nhất tôi nói chuyện
trực tiếp.

Trước khi tự làm bất kỳ việc gì:
1. Kiểm tra xem có agent chuyên trách nào phụ trách việc đó không.
   Danh sách hiện có:
   - Motion — hình ảnh, video, animation
   - Eyes — research và kiểm chứng thông tin
   - Miner — nghiên cứu nội dung, tìm nguồn, quét đối thủ
   - Coffee — lập kế hoạch buổi sáng và ưu tiên trong ngày
   - Views — chiến lược nội dung và phân phối
2. Nếu có agent phù hợp thì giao việc cho nó và mang kết quả về đây.
3. Chỉ tự làm khi không agent nào phù hợp.
4. Nếu đã giao việc, nói rõ bạn dùng agent nào và vì sao.

Đừng bao giờ bắt tôi phải mở thêm một cuộc trò chuyện khác.

Dòng cuối chính là toàn bộ vấn đề. Chi phí của một setup nhiều agent không nằm ở token, mà ở gánh nặng phải tự điều phối trong đầu. Hãy đẩy phần điều phối đó vào hệ thống.

Mỗi agent chuyên trách cần một mô tả thật sắc. “Trợ lý chung” thì vô dụng với một bộ điều phối. “Lo sinh ảnh, prompt dựng video và brief motion graphics” thì điều phối được. Chief of staff đọc chính những mô tả này để quyết định — mô tả mơ hồ thì điều phối sai.

3. Để cửa ngõ tự thiết kế phần còn lại của đội

Sau khi làm xong buổi phỏng vấn ở thói quen #1, bạn không cần đoán mò xem nên tạo agent gì tiếp theo nữa. Cứ hỏi:

Đây là tài liệu bối cảnh và danh sách agent hiện có của tôi.

Với các mục tiêu trong tài liệu bối cảnh, đang thiếu những vai trò nào?
Quy tắc:
- Không đề xuất thêm một chief of staff thứ hai hay một trợ lý chung.
- Không đề xuất vai trò trùng lặp với agent đã có — thay vào đó hãy
  chỉ ra agent hiện tại nào đã lo phần đó rồi.
- Với mỗi đề xuất: nêu đúng vấn đề lặp đi lặp lại mà nó giải quyết,
  nó cần làm được gì, và nó tuyệt đối không được đụng vào gì.
- Xếp hạng theo số giờ tiết kiệm được mỗi tháng. Ghi rõ cách bạn ước lượng.

Hai quy tắc “không” là phần chịu lực. Cứ để tự do, model sẽ đề xuất một con trợ lý chung chung và một con điều phối trùng lặp, vì đó là hai hình dạng phổ biến nhất trong dữ liệu huấn luyện của nó. Cấm hai cái đó đi thì bạn nhận được đề xuất bám theo vấn đề thật của mình.

Khi ưu tiên thay đổi, cứ nói cho chief of staff biết cái gì đã đổi và để nó thiết kế lại đội ngũ. Đội hình nên là thứ có thể vứt đi và dựng lại.

Phần 2 — Kiểm soát ai được biết gì

4. Tách bộ nhớ chung khỏi bộ nhớ riêng

Phần lớn nền tảng giờ đều có bộ nhớ lâu dài. Sai lầm là quăng tất cả vào chung một đống.

Hai tầng:

Phép thử rất đơn giản: agent khác có ra quyết định tệ hơn nếu không biết điều này không? Có thì là bộ nhớ chung. Chỉ ảnh hưởng tới công việc của một agent thì để riêng.

Chuyện này càng quan trọng khi đội càng đông. Nhiều agent có thể cùng dùng lịch của bạn — nhưng bối cảnh về lý do sáng thứ Ba là khung giờ bất khả xâm phạm thì phải nằm ở bộ nhớ chung, không thì con nào cũng đặt lịch đè lên.

Khi bảo agent ghi nhớ điều gì, hãy nói rõ:

Lưu vào bộ nhớ chung: team ship hàng vào thứ Năm, không bao giờ thứ Sáu.
Lưu vào bộ nhớ riêng của bạn: tôi thích bản nháp 400 chữ, không phải 800.

Thêm một thói quen: phần lớn công cụ cho phép tách một tin nhắn quan trọng thành thread riêng. Hãy dùng nó. Đào sâu một nhánh ý tưởng trong thread phụ, giữ cuộc trò chuyện chính sạch sẽ. Thread chính là xương sống của hệ thống — đừng làm nó rối bằng những lần thăm dò.

Phần 3 — Nối công cụ, ghi lại công việc

5. Bắc cầu tới những app nền tảng của bạn không hỗ trợ

Nền tảng AI nào cũng có sẵn plugin. Không nền tảng nào có đủ hết. Khi bạn cần YouTube, Reddit, LinkedIn, một CRM hay một API tìm kiếm không được hỗ trợ sẵn, một nền tảng tích hợp như Composio đứng ở giữa — hàng trăm tích hợp nằm sau một kết nối duy nhất mà agent của bạn gọi được.

Rồi ghi cái cầu đó vào bộ nhớ chung, để mọi agent đều biết năng lực này tồn tại:

Lưu vào bộ nhớ chung: YouTube, LinkedIn, Reddit và Perplexity đều
truy cập được qua Composio. Hãy kiểm tra Composio trước khi nói với
tôi rằng việc gì đó không làm được.

Không có dòng đó, agent sẽ liên tục báo với bạn rằng nó không làm được những việc nó làm được. Năng lực không được ghi ra thì coi như không tồn tại.

Lưu ý bảo mật, và cái này không phải tùy chọn: một cầu nối tích hợp đang giữ credential sống của các tài khoản của bạn. Cấp scope hẹp nhất mà vẫn chạy được, xem lại từng kết nối thật sự làm được gì, và tuyệt đối đừng cho một agent chạy tự động không giám sát quyền ghi vào thứ mà bạn sẽ đau tim nếu nó ghi đè sai. Sự tiện lợi là thật, nhưng bán kính thiệt hại cũng thật.

6. Ghi log công việc của agent ra ngoài cuộc chat

Ngay khi bạn bắt đầu giao việc từ cả điện thoại lẫn laptop, mọi thứ tuột khỏi tầm kiểm soát. Công việc biến mất vào những cuộc hội thoại chẳng ai mở lại.

Cách xử lý là biến việc ghi log thành một phần của task, không phải chuyện làm cho có sau đó. Một skill kiểu “ghi việc này vào tracker” chạy trước khi bắt đầu làm:

Khi tôi giao một task research hoặc task nhiều bước:
1. Tạo project trong tracker TRƯỚC, trước khi làm bất cứ điều gì.
2. Thêm một task cho mỗi việc con, kèm: agent phụ trách, thời gian
   bắt đầu, đang chờ điều gì, và một trường link cho kết quả.
3. Giao việc.
4. Cập nhật task với ghi chú tiến độ và link kết quả khi xong.
5. Đưa tôi link project trong phần trả lời.

Bạn yêu cầu so sánh 5 nhà cung cấp voice agent, thì tracker có project trước khi bất kỳ phần research nào diễn ra. Về sau bạn thấy được cái gì đã chạy, cái gì đã xong, ai làm, kết quả nằm ở đâu — mà không phải đào bới lịch sử chat.

Giá trị không nằm ở việc diễn trò quản lý dự án. Nó nằm ở chỗ công việc không còn bốc hơi.

Phần 4 — Dạy một lần, rồi tự động hóa

7. Làm mẫu cho những workflow không diễn tả được bằng lời

Có những quy trình thiên về thị giác và thật sự khổ sở khi phải viết ra. Bấm chỗ nào, trong bốn cái nút giống nhau thì chọn cái nào, layout xê dịch thì xử lý sao.

Nếu nền tảng của bạn cho agent một máy tính đám mây dùng chung kèm chế độ ghi hình “teach a task”, hãy dùng nó đúng cho những việc này. Bấm ghi, làm quy trình ở tốc độ bình thường, bấm dừng. Agent phân tích thao tác vừa rồi và biến nó thành một skill tái sử dụng được.

Việc phù hợp: tìm ảnh và lưu theo một quy ước đặt tên cụ thể; thao tác với giao diện không có API; bất kỳ việc gì mà bước kế tiếp phụ thuộc vào cái đang hiển thị trên màn hình.

Việc không phù hợp: bất cứ thứ gì đã có API sạch sẽ. Ghi lại thao tác click đè lên một API được hỗ trợ vừa chậm hơn vừa dễ vỡ hơn nhiều. Làm mẫu là để lấp chỗ trống.

8. Routine mới là thứ khiến hệ thống chạy không cần bạn

App chat dành cho lúc bạn đang suy nghĩ. Routine dành cho lúc bạn không.

Routine là một công việc lặp lại mà agent chạy theo lịch hoặc theo trigger. Đặt tên, viết yêu cầu, và chỉ định skill hay agent cần gọi.

Hai loại trigger, giải quyết hai vấn đề khác nhau:

• Theo lịch — mỗi giờ, mỗi ngày, hoặc khoảng thời gian tùy chỉnh. Hợp với bản tin tổng hợp, rà soát định kỳ, báo cáo lặp lại.
• Theo sự kiện — tin nhắn Slack, hoạt động Git, tin nhắn Teams và tương tự. Hợp với việc phản ứng lại những thứ bạn không kiểm soát được thời điểm.

Vì routine chạy trên cloud nên nó vẫn tiếp tục khi laptop đã tắt và điện thoại đang nằm trong ngăn kéo. Đó là khác biệt giữa một trợ lý và một hệ thống.

Hãy bắt đầu từ những cái nhàm chán nhất. Một bản brief 7 giờ sáng mỗi ngày, đọc lịch và hộp thư rồi nói cho bạn ba việc thật sự quan trọng, có giá trị hơn bất kỳ automation thông minh nào bạn sẽ xây sau này rồi chẳng bao giờ tin tưởng.

Đặt rào chắn cho mọi thứ chạy không giám sát: agent chạy tự động nên mặc định chỉ tạo bản nháp và thông báo, không gửi, không đăng, không xóa. Chỉ chuyển một routine sang chế độ hoàn toàn tự động sau khi bạn đã theo dõi output của nó vài tuần và lần nào nó cũng đúng.

9. Lưu profile trình duyệt đã đăng nhập

Máy tính của agent trở nên hữu ích hơn hẳn khi nó dùng lại được một profile trình duyệt đã đăng nhập sẵn.

Đăng nhập agent vào dịch vụ một lần, trong profile đã lưu của nó. Dạy nó thao tác. Gắn thao tác đó vào một routine. Phiên đăng nhập được giữ lại — nên bạn không phải dán mật khẩu vào cuộc trò chuyện mỗi lần chạy.

Đó mới là lập luận bảo mật thật sự của tính năng này, và nên nói thẳng ra: credential nằm trong profile đã lưu tốt hơn credential nằm trong lịch sử chat. Lịch sử chat bị tóm tắt, bị export, rồi bị nạp ngược vào các bối cảnh khác. Một phiên trình duyệt được lưu thì không.

Hai quy tắc nếu bạn làm cách này:

1. Dùng tài khoản riêng cho việc của agent ở những dịch vụ cho phép — đừng dùng tài khoản chính.
2. Không bao giờ dán mật khẩu, API key hay mã 2FA vào cuộc trò chuyện, kể cả “chỉ lần này để setup thôi”. Hãy đăng nhập thủ công ngay trong profile đó.

Ráp lại thành một hệ thống

Một cuối tuần là đủ, theo thứ tự này:

1. Chạy buổi tự phỏng vấn. Lưu kết quả làm tài liệu bối cảnh.
2. Tạo chief of staff. Dán quy tắc điều phối vào. Đưa nó tài liệu bối cảnh.
3. Hỏi nó đang thiếu agent nào. Xây hai con đầu bảng. Không phải tám.
4. Tách bộ nhớ. Dữ kiện chung ở tầng trên, ghi chú từng agent ở tầng dưới.
5. Nối một cây cầu cho công cụ mà bạn cứ ước gì nó chạy được, rồi ghi vào bộ nhớ chung.
6. Thêm phần ghi log vào chỉ dẫn của chief of staff.
7. Dựng một routine — bản brief buổi sáng là lựa chọn đầu tiên kinh điển.
8. Sau đó mới tính tới chuyện dạy bằng làm mẫu và lưu profile.

Bước 1–3 mang lại phần lớn giá trị. Phần còn lại là lãi kép.

Điều gì thật sự khiến nó chạy được

Setup tốt nhất không phải setup nhiều agent nhất. Mà là setup trong đó mỗi agent biết rõ vai trò của mình, có đủ bối cảnh cần thiết, báo cáo lại việc đã làm, và biến được một quy trình bạn từng làm tốt thành thứ dùng lại được.

Ba kiểu hỏng cần canh chừng:

Quá nhiều agent. Mỗi agent là một quyết định điều phối. Năm con sắc nét hơn mười lăm con mờ nhạt — và một danh sách mờ nhạt còn làm hỏng khả năng điều phối của chief of staff, vì nó chọn dựa trên chính mấy dòng mô tả đó.

Bộ nhớ không bao giờ được dọn. Bộ nhớ chung đã lỗi thời còn tệ hơn không có bộ nhớ chung, vì agent hành động theo nó một cách rất tự tin. Rà lại mỗi tháng và xóa những gì không còn đúng.

Routine không ai đọc. Một automation tạo ra output mà bạn lướt qua là chi phí thuần túy. Nếu bạn đã bỏ qua output của một routine hai lần liên tiếp, hoặc sửa nó, hoặc xóa nó.

Câu hỏi thường gặp

Có cần nền tảng cụ thể nào không? Không. Mô hình này chạy trên mọi hệ thống có trợ lý tùy chỉnh lưu được và có bộ nhớ — Grok Bot, custom GPT, Claude Projects. Chỉ thói quen 7 và 8 cần tính năng riêng của nền tảng (máy tính cho agent, routine theo lịch).

Nên bắt đầu với bao nhiêu agent? Hai: chief of staff, và một con chuyên trách cho việc lặp lại nhiều nhất của bạn. Chỉ thêm khi bạn thấy rõ agent hiện có cho ra kết quả tệ hơn hẳn so với một con chuyên trách.

Cái gì vào bộ nhớ chung, cái gì để riêng? Chung nếu agent khác sẽ ra quyết định tệ hơn khi không biết. Riêng nếu nó chỉ ảnh hưởng tới công việc của chính agent đó.

Để agent chạy không giám sát có an toàn không? Có, nếu kỷ luật về scope. Mặc định cho routine chạy tự động quyền đọc và chỉ xuất bản nháp. Mọi thứ gửi đi, đăng lên, tiêu tiền hay xóa dữ liệu đều nên cần bạn duyệt, cho tới khi bạn đã theo dõi nó chạy đúng trong nhiều tuần.

Thói quen nào giá trị nhất trong danh sách này? Buổi tự phỏng vấn. Mọi thói quen còn lại đều tốt lên khi hệ thống thật sự hiểu tình hình của bạn, và đều xuống cấp khi nó không hiểu.

Bài này khai triển từ một bộ chín mẹo đang được chia sẻ trong cộng đồng AI Việt Nam, vốn được viết ra sau một tuần dùng Grok Bot hằng ngày. Phần prompt và cách đóng khung trong bài là của mình; còn các thói quen nền tảng thì đáng học bất kể bạn đang dùng nền tảng nào.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

The barrier to trying an AI coding agent used to be an API key and a credit card. OpenCode removed both: its Zen gateway ships hosted models you can select and start using immediately, at no cost and with no key.

Which means the last excuse for not learning how agentic coding works is gone. It also means a lot of people are about to point a free model at a private repository without thinking about what that involves.

Both things are worth taking seriously. Here’s what the free tier is actually good for, what it costs you in a currency that isn’t money, and how to structure your work so you’re not paying for a frontier model to rename variables.

What “free” means here

Three separate things get bundled under the word, and they have different limits:

The tool is free. OpenCode itself is open source. There’s no cap on the client, no seat licence, no metering. Bring your own API key from any provider and it behaves like any other agent harness.

The hosted models are free with a quota. OpenCode Zen is the built-in gateway. Its free tier runs at $0/month with roughly 100 requests per day, no credit card, access to the Zen model lineup. The models are grouped into tiers rather than sold individually — a default tier with large context, an advanced tier with the largest context window, and a fast tier with a small context window and much lower latency.

Free is not unlimited, and it is not private. Those are the two things people skip, and they’re the two that matter.

The quota is smaller than it sounds

100 requests a day sounds generous until you watch an agent work. A single “fix this failing test” can burn five to fifteen requests as the agent reads files, runs the suite, edits, re-runs, and reads the error again. Agentic loops consume requests in bursts.

Practically: expect a handful of real tasks per day, not a full workday of continuous agent use. That’s fine for learning. It is not a workflow you can commit to a deadline.

Your code is the other price

This is the part that deserves a flat statement rather than a footnote: on the free tier, prompts and completions are generally retained and used to improve future models. That is the business model. One model in the lineup is documented as never storing or training on your data — if privacy is the requirement, that’s the one to check for and verify against the current docs, because these policies change.

There’s a saying that gets repeated here — if you’re not paying for the product, you’re the product — and in this case it’s not a metaphor. The payment is your code.

Note also that model names and free-tier composition churn fast. The lineup shifted twice in the months before this was written. Treat any specific model name you read in a blog post, including this one, as a snapshot. Check the Zen model list for what’s actually free today, and check the data policy at the same time.

What never goes into a free-tier model

Not a vague “be careful.” A list:

• Credentials of any kind — API keys, tokens, passwords, connection strings, .env contents, private keys
• Private source you don’t own the disclosure rights to — employer code, client code, anything under NDA
• Customer data — real user records, PII, anything from a production database
• Internal documents — architecture docs, contracts, roadmaps, incident write-ups
• Anything under a compliance regime — health, financial, or regulated data

The rule underneath: if you’d need permission to email it to a stranger, don’t paste it into a model whose retention policy you haven’t read.

One trap specific to agents rather than chat: an agent reads files you didn’t explicitly hand it. Point it at a repo root and it may read .env, config/secrets.yml, or a fixture full of real customer records — none of which you meant to send. Chat models only see what you paste; agents see what they open.

So before running any agent, free or paid, on a repo you didn’t create for the purpose:

git ls-files | grep -Ei '\.env|secret|credential|\.pem$|\.key$|token'

Anything that turns up should be in .gitignore, in an ignore file the agent respects, or moved out of the tree entirely.

The escalation ladder

The useful mental model isn’t free-versus-paid. It’s three tiers, matched to what a task actually needs:

Most people get this backwards in both directions. They run frontier models on boilerplate, and they run free models on the gnarly bug that’s eaten two days. Both waste money — one in tokens, one in your time.

The tell for escalating: if you’ve re-prompted three times and the answer is still wrong in the same way, the model isn’t the bottleneck you think it is. Either escalate a tier, or — more often — your prompt is missing context the model can’t infer. Try the context first; it’s free.

Getting genuinely useful work out of a free tier

Free models are smaller and less patient. Adapt the work to fit rather than expecting them to behave like a frontier model.

Give it a smaller job. “Refactor the auth module” is a frontier-model task. “In auth/session.py, extract the token-refresh logic into its own function and update the two call sites” is a free-model task. Smaller scope also burns fewer requests, which matters when you have a hundred.

Point at files explicitly. Letting an agent discover which files matter costs requests and often goes wrong with a smaller model. Naming the three files it needs saves both.

Batch mechanical work. Renames, adding type hints, converting a test suite from one assertion style to another, writing docstrings from existing signatures — this is exactly what free models are good at, and the results are cheap to verify.

Read a codebase with it. One of the best uses of a free tier is asking a fast model to explain an unfamiliar repo. “Trace what happens when a request hits /api/orders” is low-risk, high-value, and doesn’t need frontier reasoning.

Use the fast tier for fast things. The small-context fast tier is genuinely better for quick lookups and single-file edits than the big-context tier — lower latency, and context you don’t use is context that can distract.

The other free option

Worth knowing about: Hermes Agent is also free and works over messaging — you drive the agent from Telegram or Discord rather than a terminal. Different ergonomics entirely. If the appeal is kicking off a task from your phone and reading the result later, that’s a better fit than a CLI. The same data-handling caution applies, with an extra wrinkle: a chat platform keeps its own copy of everything you send.

A starting setup that won’t burn you

1. Install OpenCode. Setup is genuinely a couple of minutes.
2. Start on a repo you own and that contains nothing confidential. Not the work monorepo. A side project.
3. Check the current free lineup and its data policy at opencode.ai/zen before your first real task, not after.
4. Run the secret sweep above on any repo before pointing an agent at it.
5. Do three real tasks — a bug fix, a small refactor, an explain-this-code session. That’s enough to know whether the tool fits how you work.
6. When you find yourself relying on it, move to a paid mid-tier model. The moment agent output goes into work someone pays for, both the rate limit and the retention policy stop being acceptable.

Step 6 is the one people postpone, usually until a rate limit hits mid-sprint. Move before that, not after.

The honest summary

The free tier is an excellent way to learn and a bad way to ship. That isn’t a criticism — it’s what a free tier is for, and OpenCode is unusually upfront about the trade.

Learn on free. Work on paid. Escalate to frontier only when a task is genuinely hard. And read the retention policy before the first prompt, not after you’ve pasted something you can’t unpaste.

FAQ

Is OpenCode itself free, or just the models? The tool is open source and unmetered. Zen’s free tier is the hosted-model part, with a daily request cap. You can also plug in your own API key from any provider.

How many requests do I actually get? The free tier is documented at roughly 100 requests per day. Agent loops consume several requests per task, so plan on a handful of substantial tasks rather than continuous use.

Is my code used for training? On the free tier, generally yes — prompts and completions are retained and used to improve models. At least one model in the lineup is documented as excluded from this. Verify against the current docs, because these terms change.

Can I use it for client work? Not on a free tier with a training-retention policy, unless the client has explicitly agreed in writing. Use a paid tier with contractual data handling.

Which free model should I start with? Start on the default tier for general coding, switch to the advanced tier when a task needs more context or more reasoning, and use the fast tier for quick single-file work. Specific model names change often — check the current list rather than trusting any blog post, including this one.

Is a free model good enough to learn agentic coding? Yes, and that’s the strongest argument for it. Learning how to scope tasks, supply context, and verify output transfers completely to paid models. The skill is the durable part, not the model.

This piece expands on a note circulating in Vietnamese developer communities about OpenCode’s free models, whose central warnings — free isn’t unlimited, your data trains the next model, never paste secrets — are the right ones. Model names and quotas here reflect what was published at the time of writing and change frequently; the links go to the current source of truth.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Most people’s AI setup looks the same after six months: eleven half-remembered custom assistants, a browser tab graveyard, and a nagging sense that the thing you figured out in March is buried in a chat you’ll never find again.

Creating agents is the easy part. Every platform — Grok Bot, custom GPTs, Claude Projects — makes it a two-minute job. What separates a useful setup from a cluttered one is not how many agents you have. It’s whether they share context, report their work, and can run without you sitting there.

Nine habits get you there. They’re written platform-agnostically, because the pattern outlives whichever tool you’re using this year.

Part 1 — Teach the system who you are

1. Interview yourself first

An agent team is only as good as its understanding of your situation. And most people never write that down, because it’s tedious and they already know it.

Make the AI extract it instead. Create a skill or saved prompt whose only job is to interrogate you — one question at a time, no answers offered, until it can state your work, goals and constraints back to you accurately.

You are interviewing me to build a context document about my work.

Rules:
- Ask ONE question at a time and wait for my answer.
- Never suggest an answer or offer multiple choice.
- When an answer is vague, ask a follow-up instead of moving on.
- Cover: what I actually do day to day, what I'm measured on, who
  depends on me, what's currently blocked, what I'm avoiding, and
  what I want to be true in 90 days.
- Stop when you can summarise my situation in 10 bullets I'd agree
  with. Show me those bullets and ask what's wrong with them.

That last rule matters more than the rest. “Show me the summary and ask what’s wrong with it” is what turns an interview into a correction loop.

Run this before quarterly planning, before starting a project, before building any automation. Save the output. It becomes the shared context every other agent reads.

Why it works: you’re not writing documentation, which you’d never finish. You’re answering questions, which is much easier, and something else does the writing.

2. One front door

You might have agents for content, research, planning and admin. What you don’t want is to remember which one handles what, every single time.

Pick one agent to be the front door. Give it a name — it genuinely helps to talk to Klaus rather than Assistant 4. Everything goes through it.

Its operating rule is short:

You are my chief of staff. You are the only agent I talk to directly.

Before doing any task yourself:
1. Check whether a specialist agent covers it. Here is the roster:
   - Motion — images, video, animation
   - Eyes — research and fact-checking
   - Miner — content research, sourcing, competitor scans
   - Coffee — morning planning and daily priorities
   - Views — content strategy and distribution
2. If one fits, delegate to it and bring the result back here.
3. Only handle it yourself if no specialist fits.
4. If you delegated, say which agent you used and why.

Never make me open another conversation.

That last line is the whole point. The cost of a multi-agent setup isn’t tokens, it’s the mental overhead of routing. Move the routing into the system.

Give each specialist a sharp description. “General assistant” is useless to a router. “Handles image generation, video editing prompts, and motion graphics briefs” is routable. The chief of staff reads these descriptions to decide — vague descriptions produce bad routing.

3. Let the front door design the rest of the team

Once you’ve done the interview from habit #1, you no longer have to guess which agent to build next. Ask:

Here is my context document and my current agent roster.

Given the goals in the context document, what roles are missing?
Rules:
- Do not propose a second chief of staff or a general assistant.
- Do not propose a role that overlaps an existing one — say which
  existing agent already covers it instead.
- For each proposal: the specific recurring problem it solves, what
  it should be able to do, and what it should never touch.
- Rank by how much time it saves me per month. Show your estimate.

The two “do not” rules are load-bearing. Left alone, models propose a generic helper and a duplicate coordinator, because those are the most common shapes in their training data. Ban them and you get proposals shaped by your actual problems.

When priorities shift, tell the chief of staff what changed and let it redesign the roster. Teams should be disposable.

Part 2 — Control who knows what

4. Split shared memory from private memory

Most platforms now offer persistent memory. The mistake is dumping everything into one pile.

Two tiers:

The test is simple: would another agent make a worse decision without knowing this? If yes, it’s shared. If it only matters to one agent’s job, keep it private.

This matters more as the roster grows. Several agents may use your calendar — but the context about why Tuesday mornings are protected belongs in shared memory, or every one of them will book over it.

Be explicit when you tell an agent to remember something:

Save to shared memory: we ship on Thursdays, never Fridays.
Save to your own memory: I prefer your drafts at 400 words, not 800.

One more habit: most tools let you branch an important message into its own thread. Use it. Explore a tangent in a branch, keep the main conversation clean. The main thread is your system’s spine — don’t clutter it with exploration.

Part 3 — Connect the tools, log the work

5. Bridge to the apps your platform doesn’t support

Every AI platform ships plugins. None ships all of them. When you need YouTube, Reddit, LinkedIn, a CRM, or a search API that isn’t natively supported, an integration platform like Composio sits in between — hundreds of integrations behind one connection your agents can call.

Then record the bridge in shared memory, so every agent knows the capability exists:

Save to shared memory: YouTube, LinkedIn, Reddit and Perplexity are
reachable through Composio. Check Composio before telling me
something isn't possible.

Without that line, agents will keep telling you they can’t do things they can do. Capabilities that aren’t written down don’t exist.

Security note, and it’s not optional: an integration bridge holds live credentials to your accounts. Grant the narrowest scopes that work, review what each connection can actually do, and never give a scheduled, unattended agent write access to something you’d hate to have wrongly rewritten. The convenience is real; so is the blast radius.

6. Log agent work somewhere outside the chat

The moment you start delegating from both phone and laptop, you lose track. Work disappears into conversations nobody reopens.

Fix it by making logging part of the task, not an afterthought. A skill like “log this work to the tracker” that fires before the work starts:

When I assign research or a multi-step task:
1. Create a project in the tracker FIRST, before doing anything.
2. Add a task per subtask, with: owner agent, start time, what it's
   waiting on, and a link field for the output.
3. Delegate the work.
4. Update the task with progress notes and the output link when done.
5. Give me the project link in your reply.

Ask for five voice-agent vendors compared, and the tracker gets a project before any research happens. Later you can see what ran, what finished, who did it, and where the output went — without archaeology through chat history.

The value isn’t project management theatre. It’s that work stops evaporating.

Part 4 — Teach once, then automate

7. Demonstrate the workflows you can’t describe

Some processes are visual and genuinely painful to write down. Where to click, which of four similar buttons, what to do when the layout shifts.

If your platform gives agents a shared cloud computer with a “teach a task” recording mode, use it for exactly these. Start recording, do the process at normal speed, stop. The agent analyses what you did and turns it into a reusable skill.

Good candidates: sourcing images and saving them with a specific naming convention; navigating an interface with no API; anything where the next step depends on what’s currently on screen.

Bad candidates: anything with a clean API. Recording clicks over a supported API is slower and far more brittle. Demonstration is for the gaps.

8. Routines are what make it run without you

Chat apps are for when you’re thinking. Routines are for when you’re not.

A routine is a recurring task the agent runs on a schedule or a trigger. Give it a name, the instruction, and which skill or agent it should invoke.

Two trigger types, and they solve different problems:

• Schedule — hourly, daily, custom interval. Good for digests, reviews, recurring reports.
• Event — Slack message, Git activity, Teams message, and similar. Good for reacting to things you don’t control the timing of.

Because routines run in the cloud, they keep running with your laptop shut and your phone in a drawer. That’s the difference between an assistant and a system.

Start with the boring ones. A daily 7am brief that reads your calendar and inbox and tells you the three things that actually matter is worth more than any clever automation you’ll build later and never trust.

Set a guardrail on anything unattended: unattended agents should default to producing drafts and notifications, not sending, publishing, or deleting. Move an individual routine to fully automatic only after you’ve watched its output for a couple of weeks and it’s been right every time.

9. Save logged-in browser profiles

An agent’s computer becomes far more useful when it can reuse a browser profile that’s already signed in.

Log the agent into a service once, in its saved profile. Teach it the task. Attach the task to a routine. The session persists — so you’re not pasting a password into a conversation on every run.

That’s the real security argument for this feature, and it’s worth stating plainly: credentials in a saved profile are better than credentials in your chat history. Chat history gets summarised, exported, and fed back into other contexts. A stored browser session doesn’t.

Two rules if you do this:

1. Use a dedicated account for agent work where the service allows it — not your primary account.
2. Never paste a password, API key or 2FA code into a conversation, including “just this once to set it up.” Sign in interactively in the profile instead.

Putting it together

A weekend’s worth of setup, in order:

1. Run the self-interview. Save the output as your context document.
2. Create the chief of staff. Paste in the routing rule. Give it the context document.
3. Ask it what agents are missing. Build the top two. Not eight.
4. Split memory. Shared facts up top, per-agent notes below.
5. Connect one bridge for the tool you keep wishing worked, and record it in shared memory.
6. Add logging to the chief of staff’s instructions.
7. Build one routine — a morning brief is the standard first one.
8. Only then consider demonstrations and saved profiles.

Steps 1–3 deliver most of the value. The rest is compounding.

What actually makes it work

The best setup is not the one with the most agents. It’s the one where each agent knows its role, has the context it needs, reports what it did, and can turn a process you’ve already done well into something reusable.

Three failure modes to watch for:

Too many agents. Every agent is a routing decision. Five sharp ones beat fifteen fuzzy ones — and a fuzzy roster degrades the chief of staff’s routing, because it’s choosing from descriptions.

Memory that’s never pruned. Stale shared memory is worse than no shared memory, because agents act on it confidently. Review it monthly and delete what’s no longer true.

Routines nobody reads. An automation producing output you skim past is pure cost. If you’ve ignored a routine’s output twice in a row, either fix it or delete it.

FAQ

Do I need a specific platform for this? No. The pattern works on any system with persistent custom assistants and memory — Grok Bot, custom GPTs, Claude Projects. Only habits 7 and 8 need platform-specific features (agent computer, scheduled routines).

How many agents should I start with? Two: the chief of staff, and one specialist for your most repetitive task. Add more only when routing to an existing agent visibly produces worse output than a dedicated one would.

What goes in shared memory vs private? Shared if another agent would make a worse decision without it. Private if it only affects one agent’s own work.

Is it safe to let agents run unattended? With scope discipline, yes. Give unattended routines read access and draft-only output by default. Anything that sends, publishes, spends or deletes should require you to approve it, until you’ve watched it behave correctly for weeks.

What’s the single highest-value habit here? The self-interview. Every other habit gets better when the system actually knows your situation, and every one of them degrades when it doesn’t.

This piece expands on a set of nine tips circulating in Vietnamese AI communities, originally written up after a week of daily use with Grok Bot. The prompts and framing here are my own; the underlying habits are worth stealing regardless of which platform you’re on.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.