Hầu hết các nền tảng agent đều chen vào giữa bạn và nhà cung cấp model, rồi thu thêm một khoản phí trên mỗi token đi qua. Sharkly thì không làm vậy. Việc dùng model ở đây theo cơ chế bring-your-own-key: một lượt chạy sẽ được tính vào gói Claude Code, Codex hoặc API vốn đã gắn với Runtime thực thi nó, chứ không trừ vào số dư token mà Sharkly bán cho bạn. Nghe thì có vẻ đơn giản hơn thực tế, và trước khi kết luận rằng điều này quan trọng, cần thành thật về cả những gì nó khiến bạn tốn kém lẫn những gì nó giúp bạn tiết kiệm.
Mô hình bán lại tác động thế nào đến động lực của bạn
Hãy bắt đầu với nền tảng thực sự bán token cho bạn, vì đó là kiểu mặc định trong nhóm sản phẩm này, và cần gọi tên thẳng thắn thay vì lảng tránh.
Khi một nền tảng bán lại quyền truy cập model, doanh thu của họ gắn chặt với số token mà các Agent của bạn đốt. Đó không phải một lỗi ngầm giấu kín, mà là mô hình kinh doanh vận hành đúng như thiết kế, và nó tạo ra một động lực rất dễ đoán: nền tảng chẳng có lý do gì để làm cho một lượt chạy trở nên rẻ hơn. Một prompt hiệu quả hơn, một context window nhỏ hơn, một Runtime kết thúc với ít token hơn — tất cả đều làm giảm doanh thu của nền tảng từ tài khoản của bạn. Không có gì buộc một bên bán lại token phải chuyển tiếp những đợt giảm giá mà nhà cung cấp model gốc đưa ra, và cũng chẳng có gì thưởng cho họ khi giúp bạn chi ít hơn. Bạn đang trả một khoản phí chênh lệch cho việc điều phối, nhưng khoản phí đó lại được định giá bằng đúng loại "tiền tệ" mà nền tảng muốn bạn tiêu nhiều hơn.
Chi phí thứ hai âm thầm hơn và chỉ lộ ra về sau. Nếu nhóm của bạn đã có gói Claude Code hoặc Codex, hoặc đã cam kết chi tiêu API với một nhà cung cấp, rất có thể bạn đã thương lượng được mức giá cho việc đó: một hạng đăng ký, một mức chiết khấu theo sản lượng, một mức giá cam kết sử dụng. Nhưng nếu chuyển lượng sử dụng đó qua một bên bán lại, bạn đang trả hai lần cho cùng một lợi thế: một lần cho bên bán lại để có quyền truy cập, và bạn đánh mất lợi ích từ mức giá mình đã tự thương lượng trực tiếp, bởi giờ mức giá của bên bán lại mới là mức được áp dụng. Mối quan hệ giá cả bạn xây dựng với nhà cung cấp model không đi cùng bạn vào một nền tảng bán lại token dưới tài khoản của chính họ.
Thử đặt một con số, dù chỉ đại khái. Một nhóm chạy vài Agent qua bên bán lại với mức phí chênh lệch khiêm tốn trên mỗi token, cộng thêm khoản cam kết chi tiêu họ đã có trực tiếp với nhà cung cấp model, là đang trả hai lần cho cùng số token: một lần theo mức giá đã thương lượng mà họ không còn dùng được nữa, một lần theo mức giá bất kỳ mà bên bán lại quyết định thu. Nhân con số đó lên cho cả một Sprint chạy, chứ không chỉ một Task đơn lẻ, và khoảng cách sẽ tích lũy đúng theo hướng mà bên bán lại mong muốn.
Không điều nào trong số này khiến việc bán lại token trở thành không trung thực. Nó chỉ khiến đây thành một mô hình mà lợi ích của nền tảng và lợi ích chi phí của bạn hướng về hai phía khác nhau, và điều đó đáng để biết trước khi bạn giao các lượt chạy của mình cho một nhà cung cấp.
BYOK thực sự khiến bạn tốn những gì
Sự tách biệt này cũng không hề miễn phí về phía Sharkly, và một bài viết chỉ liệt kê ưu điểm của bring-your-own-key sẽ đọc như quảng cáo hơn là một lời giải thích trung thực về sự đánh đổi. Vậy nên hãy nói thẳng những cái giá phải trả.
Bạn tự quản lý key và quota. Không ai ở lớp điều phối đứng ra theo dõi giới hạn tốc độ của gói Claude Code hay số credit còn lại trong tài khoản API của bạn thay bạn. Nếu nhóm bạn chạy năm Agent với cùng một API key Anthropic và key đó chạm giới hạn tốc độ, thì đó là ràng buộc mà chính bạn phải nhận ra và tính toán trước, giống hệt như khi một người trong nhóm gọi trực tiếp các lệnh đó từ terminal.
Một lượt chạy có thể thất bại vì lý do chẳng liên quan gì đến Sharkly. Nếu gói Claude Code gắn với một Runtime bị giới hạn tốc độ, hoặc tài khoản API đứng sau nó hết credit, lượt chạy sẽ dừng lại, và lỗi hiện ra dưới dạng lỗi token hoặc lỗi xác thực từ nhà cung cấp model, chứ không phải sự cố của Sharkly. Gỡ lỗi trong trường hợp này đồng nghĩa với việc phải kiểm tra hai hệ thống thay vì một: Task bị kẹt là do có vấn đề gì đó trong Sharkly, hay do gói bên dưới đã cạn? Đó là một mối nối thực sự, và là cái giá trực tiếp của việc không có một bể token do nền tảng kiểm soát để làm phẳng mọi thứ.
Khả năng theo dõi chi tiêu nằm ở hai nơi. Bảng điều khiển mức sử dụng của Sharkly hiển thị mức tiêu thụ theo từng Agent, nhưng hóa đơn thực tế lại xuất hiện trên hóa đơn Claude Code, Codex hoặc nhà cung cấp API của bạn, chứ không nằm trong một mục duy nhất nào của Sharkly. Nếu nhóm tài chính của bạn muốn một con số duy nhất cho câu hỏi "tháng này việc lập trình bằng AI tốn của chúng ta bao nhiêu", họ sẽ phải đối chiếu hai nguồn thay vì đọc một bản tóm tắt, và việc đối chiếu đó là công việc thủ công mà phải có người thực sự làm.
Còn có cả chi phí onboarding nữa, và cần nói rõ thay vì mặc định bỏ qua. Mỗi Runtime bạn kết nối đều cần được cấu hình key hoặc gói riêng, phải có người trong nhóm chịu trách nhiệm gia hạn và xoay vòng các thông tin xác thực đó, và một nhân viên mới muốn chạy Agent cần có quyền truy cập vào tài khoản nhà cung cấp bên dưới, chứ không chỉ một lời mời tham gia Sharkly. Một nền tảng bán lại có thể giấu tất cả những thứ đó sau một lần đăng ký duy nhất. BYOK thì không, và đó là chủ ý của thiết kế, nên một nhóm đang cân nhắc Sharkly nên dự trù thật sự một hai giờ để thiết lập cho mỗi Runtime, thay vì kỳ vọng con số đó bằng không.
Không điểm nào trong đó là lý do để tránh BYOK. Đó là danh sách trung thực những gì bạn phải gánh để đổi lấy việc không phải trả phí chênh lệch trên token, và một nhóm nên bước vào với hiểu biết đó, thay vì phát hiện ra nó ngay giữa lúc có sự cố.
Lớp quản lý vẫn đáng đồng tiền ở chỗ nào
Vì Sharkly không bán token cho bạn cũng không làm phẳng các giới hạn tốc độ của nhà cung cấp, thật hợp lý khi đặt câu hỏi lớp điều phối này thực chất đang làm gì. Cụ thể là ba việc.
Nó quyết định một lượt chạy sẽ thực thi trên Computer nào. Runtime của một Agent cần một máy chủ, dù local hay cloud, với các repository và tài nguyên mà Task yêu cầu, và việc phân bổ đó là nhiệm vụ của Sharkly, bất kể ai là người trả tiền cho số token mà lượt chạy tiêu thụ. Việc tính tiền token và việc bố trí nơi thực thi là hai vấn đề tách biệt, và BYOK chỉ loại nền tảng ra khỏi vấn đề thứ nhất.
Nó giữ con người trong luồng phê duyệt. Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, trao quyền và chấp nhận kết quả. Bước đánh giá đó — ai là người phê duyệt một Task trước khi nó được merge hoặc đóng lại — không phụ thuộc vào việc ai đang trả tiền cho lệnh gọi model bên dưới. Một mức phí bán lại rẻ hơn không mua được cho bạn một quy trình đánh giá tốt hơn, và mô hình BYOK cũng không lấy đi của bạn thứ đó.
Và nó cho bạn một bảng điều khiển mức sử dụng hiển thị tiêu thụ theo từng Agent, dù bản thân token được tính tiền ở nơi khác. Bạn có thể thấy Agent nào đốt nhiều nhất trong một Sprint, những loại Task nào tốn kém khi tự động hóa, và Runtime nào đang chạy quá tải — tất cả mà không đòi hỏi Sharkly phải là bên thu tiền cho chính những token mà nó đang báo cáo. Giá trị của bảng điều khiển không phụ thuộc vào việc Sharkly có nắm hóa đơn hay không.
Hình hài thực sự của sự tách biệt là thế này: Sharkly quản lý công việc chạy ở đâu, ai đánh giá nó, và nó tốn của bạn bao nhiêu, mà không cần đồng thời là nhà cung cấp bán cho bạn chính thứ đang được đo lường.
Cân nhắc xem sự đánh đổi đó có đáng không
Nếu nhóm bạn nhỏ, chỉ có một Runtime và hiếm khi chạm giới hạn tốc độ, câu hỏi bán lại hay BYOK có lẽ cũng không thay đổi ngày làm việc của bạn bao nhiêu, dù theo hướng nào. Sự đánh đổi trở nên thực sự rõ ràng khi bạn chạy nhiều Agent trên cùng một gói bên dưới, điều phối các Crew trên nhiều hơn một Computer, hoặc cố trả lời câu hỏi "Sprint này việc lập trình bằng AI thực sự tốn của chúng ta bao nhiêu" cho nhiều hơn một nhóm. Đến lúc đó, một nền tảng mang động lực ngầm muốn giữ chi tiêu token của bạn ở mức cao là một khoản chi phí bạn không thể nhìn thấy đầy đủ, còn một nền tảng chỉ đơn thuần cho bạn biết mình đã chi bao nhiêu, mà không đồng thời là bên bán thứ đó cho bạn, thì xứng đáng với sự bất tiện phải xem hai bảng điều khiển.
Canh bạc của Sharkly là bài toán điều phối, chứ không phải bài toán đo đếm, mới là thứ đáng để thu tiền. Đây là lớp nằm trên những agent bạn đã chạy, chứ không phải một nhà cung cấp thứ hai chen giữa bạn và số token chúng tiêu thụ. Nếu bạn đã trả tiền trực tiếp cho Claude Code hoặc Codex và muốn các lượt chạy có thể được phân bổ, đánh giá và quan sát được mà không có khoản phí chênh lệch nào chồng lên token, thì đó chính là lớp mà Sharkly được xây dựng để trở thành. Xem bảng giá hiện tại để biết chính xác phần chi phí theo ghế ngồi trông như thế nào.
