Khi chạy đồng thời các AI coding agent như Claude Code hay Codex trong nhiều phiên tmux, tôi gặp một vấn đề. Tôi thường bỏ lỡ việc phiên nào đã xong, phiên nào đang bị chặn và chờ tôi, còn các agent chạy nền thì đến lúc bị dính usage limit mới biết.
Tôi thấy tmux chỉ đến thế là hết giới hạn, nên đã tạo ra comux.
comux là một trình multiplex kiểu tmux dành cho việc chạy AI agent.
- Hiển thị theo thời gian thực trạng thái agent của mọi phiên (
working/ready/blocked) ở thanh bên - Gửi thông báo desktop ngay khi agent kết thúc lượt hoặc đang chờ đầu vào
- Kể cả khi server bị tắt hoặc khởi động lại, khi chạy lại vẫn khôi phục từng agent về đúng điểm đang hội thoại (khác với
tmux-resurrect, nó khởi động lại session) - Có thể xem theo thời gian thực usage của các agent và các thông báo đang tích lại trên thanh trạng thái
Đây là một static binary đơn lẻ không phụ thuộc gì nên có thể chạy ở bất kỳ đâu, như server headless qua SSH.
Nó là một phần của dự án terminal lớn hơn là copad, nhưng cũng có thể cài riêng comux:
# Chỉ cài Comux
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Cài cả Copad (Linux & MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
Nhật ký phát triển trong 4 tháng: https://marshallku.com/dev/road-to-making-my-own-terminal/
Rất mong nhận được phản hồi từ những ai đang chạy nhiều agent cùng lúc.
3 bình luận
Tôi cũng đã đọc rất kỹ bài blog.
Bản thân tôi cũng đang phát triển một terminal với động cơ tương tự, nên có vài điều muốn hỏi.
Cá nhân tôi nghĩ hiếm có thời kỳ nào mà môi trường DX thay đổi nhanh như hiện nay, và mỗi lập trình viên lại trải qua một “thời đại” khác nhau như vậy.
Không biết tác giả có cảm nhận như thế không, nhưng càng trong những lúc như thế này, tôi càng nghĩ việc quyền kiểm soát nằm trong tay mình sẽ có lợi hơn.
Và khi tự hỏi “nền tảng của DX trong thời đại AI là gì?”, tôi cho rằng đó là nền tảng terminal.
Tôi đã thử dùng tất cả các terminal đang thịnh hành gần đây, nhưng việc nhập tiếng Hàn ở hầu hết terminal vẫn còn yếu, và DX/UX khi dùng agent cũng bất tiện. Vì vậy tôi đi đến kết luận là tự phát triển, và tôi nghĩ mình đã đạt được năng suất tốt hơn người khác bằng chính terminal của mình.
Trong trường hợp của tôi, để có được toàn quyền kiểm soát,
tôi nghĩ cũng cần giảm tối đa phụ thuộc vào thư viện bên ngoài, nên đã chọn tự phát triển toàn bộ bằng Zig (trừ những trường hợp bất khả kháng như webview).
Nhìn vào bài blog và code thì thấy bạn chọn Rust, và thay vì tự phát triển, bạn chọn các thư viện bên ngoài có sẵn trong hệ sinh thái Rust như rataui. Tôi tò mò lý do của lựa chọn này là gì.
Trong bài cũng có vẻ đã có những vấn đề do phụ thuộc vào thư viện bên ngoài.
Ngoài ra, vì webview là webview native, mà hầu hết môi trường web không phải là Safari, nên có lẽ khó thực hiện E2E test hoàn chỉnh. Phần này bạn sẽ chỉ giao cho công cụ testing bên ngoài xử lý, hay sau này có kế hoạch đưa cả CEF vào không? Tôi cũng tò mò về điều này.
Bây giờ tôi cũng đã dùng terminal của mình ở mức khá ổn và bước vào giai đoạn ổn định, nên đang suy nghĩ nhiều về việc thêm tính năng, lập kế hoạch hoặc UX. Nhưng trong quá trình phát triển hẳn đã có nhiều crash và đủ loại bug.
Tôi cũng muốn hỏi là sau khi bắt đầu phát triển, khoảng khi nào terminal tự phát triển của bạn ổn định đến mức bạn chuyển sang chạy mọi thứ bằng chính terminal đó, thay vì dùng terminal bên ngoài?
Xin chào!
Cảm ơn bạn đã chia sẻ những trải nghiệm và suy nghĩ rất hay.
Tất nhiên, khi chi phí tạo ra mã nguồn giảm xuống thì con đường tự xây dựng cũng đã mở ra, nhưng cá nhân tôi vẫn nhìn việc áp dụng thư viện bên ngoài theo cách không liên quan đến việc thời đại AI đã đến.
Chỉ khi tôi cho rằng cả hai điều này đều đúng thì tôi mới tự làm.
Có nhiều lý do, բայց cuối cùng thì dù chỉ là một mẩu mã nhỏ, một khi tôi bắt đầu quản lý nó thì nó sẽ thuộc phạm vi mà tôi phải rà soát, kiểm thử, bảo trì, v.v., và tôi nghĩ luôn có những chi phí đi kèm vượt xa việc chỉ viết mã.
Những vấn đề phát sinh trong quá trình phát triển cũng chủ yếu là xung đột với các chương trình khá cốt lõi như window manager, nên tôi nghĩ rằng nếu ngay cả phần đó cũng build from scratch thì tôi sẽ phải dành nhiều thời gian hơn rất nhiều cho việc triển khai và kiểm chứng, hơn cả khoảng thời gian debug và test các xung đột với phụ thuộc bên ngoài.
Ngoài ra, từ khi bắt đầu phát triển đến giờ, dù khá đau khổ, tôi vẫn liên tục dùng chính công cụ mình tạo ra, và tôi cũng nghĩ một phần lý do có thể làm được điều đó là vì tôi đã bắt đầu phát triển dựa trên một mức độ phụ thuộc nhất định.
Giống như trường hợp loại bỏ SwiftTerm trên MacOS, trước hết tôi đưa phụ thuộc bên ngoài vào để kiểm tra xem concept mình muốn có vận hành được không, rồi khi xuất hiện những phần tôi cần tự triển khai thì tôi mới bắt đầu tự làm; nhưng ngay cả ở thời điểm đó, các chương trình của tôi vẫn đang chạy nhờ các phụ thuộc bên ngoài, nên tôi có thể tiếp tục tập trung vào việc ổn định hóa và bổ sung tính năng trên nền đó.
Ngoài ra, nếu đưa webkit vào thì phần lớn ứng dụng web sẽ hoạt động giống hệt khi mở bằng một trình duyệt thông thường!
Gần đây tôi cũng đang tích cực tận dụng công cụ có thể điều khiển headless browser bằng cli, cùng với claude in chrome, và vì tôi muốn tránh việc chồng cả chromium lên terminal rồi dùng bộ nhớ quá mức, nên nếu không có biến động lớn thì có lẽ tôi sẽ không thay đổi nhiều tech stack của webview bên trong terminal.
Cảm ơn bạn đã đọc!
Có vẻ như liên kết cài đặt multiplexer bị thiếu.. Nếu xem mục này trong README, bạn có thể chỉ cài riêng multiplexer.