Tiết kiệm 80% chi phí Claude Token bằng cách làm chủ NotebookLM

Tháng trước, tôi nâng cấp Claude từ Pro lên Max với giá $200/tháng, nghĩ rằng cuối cùng nó cũng đủ dùng.

Ngày thứ 5: Hết hạn mức hàng tuần.

Nhìn vào nhật ký sử dụng, tôi thấy chính xác tiền đã đi đâu. Một buổi chiều duy nhất nghiên cứu 47 bài báo đã tiêu tốn 10% hạn mức tuần của tôi chỉ trong một lần. Chạy kiểu này hai hay ba lần một tuần, hạn mức đương nhiên không thể trụ nổi.

Vấn đề là tôi cứ bắt Claude làm điều nó không giỏi—đóng vai một công cụ tìm kiếm toàn văn.

Nhồi một log dài 50k ký tự vào cuộc hội thoại và đặt câu hỏi đồng nghĩa với việc toàn bộ log đó bị tính là token đầu vào mỗi lần. Dù bạn có dùng prompt cache (nơi giá chỉ bằng 1/10), phiên chính vẫn tích lũy dần qua mỗi lượt. Tệ hơn, cache có TTL là 1 giờ; nếu bạn chờ quá lâu, bạn phải ghi lại toàn bộ với giá đầy đủ. Cứ như hỏi luật sư một câu nhưng bắt họ đọc to bản hợp đồng 50 trang trước khi họ có thể trả lời mỗi lần vậy.

Claude Code xuất sắc trong suy luận, điều phối và viết mã. Việc đọc tài liệu gốc nên để các công cụ khác xử lý, Claude chỉ thấy các kết luận. Theo logic này, tôi nghĩ đến NotebookLM.

Hãy làm theo hướng dẫn cấu hình này, và tài khoản $20 của bạn có thể làm được việc của tài khoản $200.

Hướng Dẫn

Đây là một bài viết dài; bạn có thể bỏ qua đến phần mình quan tâm:

• I: NotebookLM là gì + Nó làm được gì?
• II: Tại sao lại thêm một lớp Claude bên trên?
• III: Cài đặt kỹ năng (thiết lập 10 phút)
• IV: Hóa đơn token thực tế + Phân tích nguyên lý
• V: Quy trình làm việc cho học giả / sinh viên
• VI: Quy trình cho IPO / Đọc bản cáo bạch
• VII: Quy trình cho Cơ sở tri thức cá nhân
• Tổng kết

Nếu muốn xem quy trình trước, hãy nhảy thẳng đến Phần V.

Luận điểm một câu:

Cách thực sự để tiết kiệm token Claude không chỉ là bật cache; mà là đảm bảo dữ liệu nặng không bao giờ vào Claude ngay từ đầu.

Cụ thể: Để NotebookLM xử lý lưu trữ và truy xuất, còn Claude xử lý suy luận và điều phối. Sự phân công lao động rõ ràng, được tóm tắt bằng phép loại suy này:

NotebookLM là Giáo viên

: Các bài báo, báo cáo tài chính và ghi chú bạn thu thập tạo thành cơ sở tri thức của nó. Bạn hỏi, nó trả lời dựa trên kinh nghiệm với trích dẫn, nằm trong ranh giới của nguồn mà không bịa đặt.

Claude là Trợ lý

: Chịu trách nhiệm viết mã, chạy script, sắp xếp kết quả và điều phối công cụ. Nếu không biết điều gì, nó hỏi Giáo viên, nhận câu trả lời và tiếp tục làm việc.

Bạn là Trưởng dự án

: Bạn chỉ can thiệp tại các điểm quyết định chính.

Nguyên lý chính: Tại sao sự phân công lao động này lại tiết kiệm tiền

1. RAG và Context Stuffing là hai mô hình chi phí khác nhau.

Nhồi 50k ký tự vào chat Claude được tính là token đầu vào. Mỗi câu hỏi đều yêu cầu "xem lại" nó, và chi phí tăng tuyến tính với kích thước tài liệu. Với RAG, NotebookLM dùng tìm kiếm vector để truy xuất các đoạn liên quan nội bộ, và Claude chỉ thấy câu trả lời cô đọng vài trăm từ, khiến chi phí gần như không đổi.

2. Prompt cache có TTL 1h, và tỷ lệ trúng thấp trong các kịch bản nghiên cứu.

Nhiều người nghĩ bật cache là giải quyết tất cả. Trên thực tế, prompt cache của Anthropic mặc định hết hạn sau 1 giờ. Nếu bạn suy nghĩ vài phút, chuyển tác vụ hoặc mở phiên mới, lần gọi tiếp theo phải ghi lại cache với giá cache_creation đầy đủ. Các phiên nghiên cứu theo nhịp "hỏi, nghĩ, hỏi lại", tỷ lệ trúng thường rất tệ. Đây là nguyên nhân thực sự khiến hóa đơn tăng vọt.

3. Đầu ra dựa trên thực tế hiệu quả hơn.

Câu trả lời của NotebookLM bị giới hạn trong các nguồn bạn tải lên, mỗi câu đều có trích dẫn [1][2] liên kết lại văn bản. Nó không bịa đặt. Khi Claude dùng những câu trả lời này để đưa ra quyết định, bạn không phải liên tục yêu cầu nó "kiểm tra lại", tiết kiệm vô số thời gian.

Ai nên bỏ qua:

• Tài liệu < 5k token hoặc chỉ kiểm tra một hai lần—cứ hỏi thẳng Claude.
• Chỉ cần hỏi đáp thuần túy mà không tích hợp quy trình—cứ dùng giao diện web NotebookLM.
• Những ai coi trọng tốc độ phản hồi hơn hóa đơn—cách này chậm hơn khoảng 3 lần.
• Những ai cần hiểu cấu trúc code/định nghĩa—NotebookLM tốt hơn cho RAG văn bản.

Ai nên đọc tiếp:

• Những ai muốn các bước cài đặt cụ thể và những cạm bẫy cần tránh.
• Những ai muốn thấy các kịch bản chuyển thành cấp lệnh như thế nào.
• Người dùng Claude Code muốn biến NotebookLM thành một kỹ năng.

Phần I: Làm quen với NotebookLM

Lần đầu tôi mở NotebookLM vì một người bạn giới thiệu. Danh sách đọc cho luận văn của cô ấy có hơn 60 bài báo. Trước đây cô ấy dùng Ctrl-F trong file PDF; giờ cô ấy thả tất cả vào một notebook và hỏi, "Ai ủng hộ quan điểm X, ai phản đối và bất đồng ở đâu?"—câu trả lời trả về với trích dẫn [1][2][3] có thể nhảy đến đúng đoạn khi nhấp vào.

Cô ấy nói cách này tiết kiệm hơn mười giờ mỗi tuần.

Tôi dùng thử một tuần với sự hoài nghi và đã nghiện. Dưới đây là những ưu điểm của NotebookLM:

1. Hỗ trợ 50 nguồn miễn phí / 300 cho Pro.
2. Sức mạnh xử lý miễn phí—tải lên, lập chỉ mục, tạo nội dung và trò chuyện đều dùng tài nguyên tính toán của Google.
3. Ngoài hỏi đáp, nó có thể tự động tạo podcast âm thanh (tuyệt cho việc đi làm), bản đồ tư duy, PPT, flashcard, v.v. từ một notebook.
4. Podcast rất ấn tượng—nghe hai "người lạ" AI thảo luận về tài liệu của bạn từ những góc độ bạn chưa từng nghĩ đến thường hé lộ những hiểu biết mới.

Định dạng không bao giờ là vấn đề: PDF, URL, bản ghi YouTube, Google Docs, văn bản thuần, OCR hình ảnh và bản ghi âm đều có thể là nguồn.

Đối với nhiều người, NotebookLM đã là một công cụ độc lập mạnh mẽ. Nếu nhu cầu của bạn chỉ là "ngồi xuống và hỏi," bạn có thể dừng đọc ở đây.

Nhưng tôi thấy nó mắc kẹt ở hai chỗ:

1. Chuyển đổi ngữ cảnh phá vỡ luồng làm việc.

Nghiên cứu một chủ đề: Hỏi → nhận câu trả lời → nhấp trích dẫn để nhảy đến nguồn → đọc một đoạn → quay lại notebook để sao chép câu trả lời → chuyển sang Claude Code để dùng → chạy thử nghiệm → tìm thấy nguồn bị thiếu → chuyển sang Google Search để tải xuống → quay lại notebook để thêm nguồn → tiếp tục hỏi... Chuyển tab 200 lần một buổi chiều.

2. Nó bị cô lập khỏi các công cụ cục bộ.

Khi xử lý sự cố trực tuyến, tôi có thể tìm kiếm log trong notebook. Nhưng tôi cũng cần grep cấu hình cục bộ trong terminal, kiểm tra sự kiện k8s và khởi tạo pod—ứng dụng web không thể chạy lệnh cục bộ. Lúc nào cũng "đọc trên web → gõ thủ công → quay lại."

Ứng dụng web NotebookLM định vị mình là điểm đến cuối cùng. Bạn hỏi, nó trả lời, hết chuyện. Nhưng tôi muốn nó trở thành một mắt xích trong dây chuyền lắp ráp—được lên lịch, xử lý hàng loạt, với đầu ra chảy sang bước tiếp theo.

Đây là lúc Claude vào cuộc.

Phần II: Thêm Lớp Claude Bên Trên

Biến NotebookLM thành một công cụ cho Claude. Một điều là đủ: Khi Claude cần kiến thức chuyên ngành, nó hỏi Giáo viên.

Luồng hoạt động

Giáo viên (NotebookLM) là một bàn trợ giúp chỉ đọc: Bạn đổ 47 bài báo vào một lần và để đó. Chúng ở đó chờ câu hỏi. Không cần phải đưa lại ghi chú hay code—các quan điểm trong bài báo đã đủ để hỗ trợ mọi truy vấn.

Đoạn prompt sau mã hóa sáu bước, kỷ luật và ID notebook cụ thể thành định dạng mà Claude Code có thể chạy (nhớ thay ID):

1# Vai trò
2Bạn là trợ lý nghiên cứu của tôi. Giáo viên chủ đề của tôi là một notebook NotebookLM cố định 
3(id: 6634ad4d-0594-4700-bddf-4a400ad46fa2) chứa 47 bài báo liên quan.
4Bạn nói chuyện với giáo viên thông qua kỹ năng notebooklm đã cài đặt (lệnh `/notecraft chat`).
5
6# Nguyên tắc Sắt
71. Với bất kỳ câu hỏi nào liên quan đến quan điểm bài báo, công thức, phương pháp hoặc cạm bẫy đã biết, **hãy hỏi giáo viên qua /notecraft chat trước**. 
8   Không trả lời từ trí nhớ và không yêu cầu tôi dán văn bản bài báo vào chat.
92. Giáo viên là một **bàn trợ giúp chỉ đọc**: Không đưa ghi chú, code hay kết quả thử nghiệm trở lại notebook. 
10   Cơ sở tri thức vẫn tĩnh với 47 bài báo.
113. Câu trả lời của giáo viên bao gồm trích dẫn [1][2]. Giữ nguyên các trích dẫn này trong đầu ra của bạn cho tôi.
124. Bạn tự quyết định có hỏi lại giáo viên trong quá trình xử lý hay không—không cần xác nhận từng bước với tôi.
135. Nếu giáo viên không thể trả lời hoặc trích dẫn yếu, hãy nói rõ "Giáo viên không có câu trả lời"; đừng bịa đặt.
14
15# Quy trình làm việc
16① Tôi đưa cho bạn một chủ đề / vấn đề phụ.
17② Xác định các điểm cần kiến thức chuyên ngành (quan điểm bài báo, phương pháp trước đây, công thức, chế độ hỏng).
18③ Truy vấn giáo viên về những điểm này qua /notecraft chat để nhận câu trả lời có trích dẫn.
19④ Thực thi dựa trên câu trả lời: viết mã, chạy script, grep file cục bộ, sắp xếp kết quả.
20⑤ Nếu có câu hỏi mới trong quá trình thực thi, quay lại bước ③ và hỏi giáo viên cho đến khi giải quyết xong.
21⑥ Đầu ra cuối cùng cho tôi:
22   - Kết luận (kèm [trích dẫn] từ giáo viên)
23   - Mã / kết quả thử nghiệm của bạn
24   - Một phần riêng cho các câu hỏi mở mà giáo viên chưa đề cập
25
26# Định dạng đầu ra
27Sử dụng khung này cho mỗi lần bàn giao:
28
29## Giáo viên nói
30(Các điểm chính từ /notecraft chat, giữ nguyên [trích dẫn])
31
32## Tôi đã làm gì
33(Mã bạn viết / lệnh đã chạy / kết quả quan sát được)
34
35## Kết luận
36(Câu trả lời cho chủ đề ban đầu của tôi)
37
38## Giáo viên chưa đề cập
39(Các điểm giáo viên không trả lời được hoặc có trích dẫn yếu, để tôi theo dõi thủ công)
40
41# Bắt đầu
42Chủ đề đầu tiên của tôi là: <Viết câu hỏi của bạn ở đây>

Những điểm chính rút ra:

• 47 bài báo không bao giờ vào chat Claude—token phiên chính chỉ dành cho suy luận và code.
• Giáo viên chỉ được tham vấn, không tham gia thực thi—sức mạnh của nó là truy xuất chuyên ngành có trích dẫn.
• Bạn chỉ can thiệp ở bước ①—Claude tự quyết định khi nào tham vấn giáo viên.
• Cơ sở tri thức là tĩnh—47 bài báo là đủ.

Đây là lý do "kết nối chúng" mạnh hơn "dùng riêng lẻ": Việc tiết kiệm chuyển tab và token là lợi ích phụ. Hãy xem những lợi ích đó lớn đến mức nào.

Phần III: Cài đặt NotebookLM Client & Kỹ năng

Google không cung cấp client NotebookLM chính thức, nhưng @icebear0828 đã viết một client bên thứ ba. Sau khi cài đặt, các agent có thể truy cập NotebookLM qua dòng lệnh hoặc ngôn ngữ tự nhiên.

https://github.com/icebear0828/notebooklm-client

Cài đặt cơ bản:

1# Cài đặt client
2npm i notebooklm-client
3
4# Xuất phiên đăng nhập (mở trình duyệt để đăng nhập Google)
5npx notebooklm export-session
6
7# Trò chuyện với một notebook
8# npx notebooklm chat <notebook-id> --transport auto --question "Tóm tắt cái này cho tôi"
9
10# Dùng `/notecraft` trong agent để tự động hóa các thao tác NotebookLM sau khi cài đặt
11npx notebooklm skill install

Sau khi cài đặt, chỉ cần nói "Kiểm tra phần X trong notebook đó" trong chat, Claude sẽ tự động gọi nó—không cần giải thích cú pháp mỗi lần.

Phần IV: Kiểm tra thực tế—Tiết kiệm được bao nhiêu tiền? (Opus 4.7)

Những con số này không phải mô phỏng; chúng đến từ một phiên nghiên cứu thực tế được trích từ nhật ký phiên của Claude Code.

Về phía NotebookLM, việc tải lên, truy xuất và tạo nội dung hoàn toàn miễn phí bởi Google và không ảnh hưởng đến hóa đơn của bạn. Tất cả các con số dưới đây chỉ tính phía Claude Opus.

Thiết lập kiểm tra:

• Tài liệu: 47 bài báo liên quan đến Image + LiDAR SLAM, tất cả trong một notebook NotebookLM.
• Mô hình: Claude Opus 4.7
• Lượt: 5 vòng hỏi đáp chuyên sâu (từ "phương pháp tái tạo SLAM tốt nhất" đến "cạm bẫy của backend 3DGS so với NeRF").
• Phương pháp: Hội thoại thông thường trong Claude Code, với trợ lý gọi /notecraft chat mỗi vòng.

Kết quả (Phương pháp này):

Hóa đơn được xác định bởi đầu vào token + cache_creation và đầu ra. Các mức giá rẻ hơn (cache_read + đầu vào) ít hơn 1/10 giá, vì vậy chúng ta sẽ tập trung vào các phần đắt tiền:

Tổng cộng cho 5 vòng: $0.55, trung bình khoảng $0.11 mỗi vòng.

Con số chính: cache_creation chỉ là 17,379.

cache_creation là số lượng token để ghi nội dung mới vào cache. Trong 5 vòng này, chỉ có câu trả lời của giáo viên (~3-6k token) + các gia tăng hệ thống nhỏ được lưu vào cache—tổng cộng 17,000.

Không một từ nào từ 47 bài báo lọt vào `cache_creation` của Claude—đó là bí quyết tiết kiệm.

So sánh: Nhồi 47 bài báo trực tiếp vào prompt

47 bài báo tổng cộng 384,000 từ ≈ 500,000 token. Nhồi prompt truyền thống trông như thế này:

So sánh công bằng nhất là hàng thứ hai (Phiên đơn, nhiều lượt)—kịch bản tốt nhất cho phương pháp truyền thống. Dù vậy, chênh lệch chi phí 5 vòng là 17 lần ($9.59 so với $0.55). Các kịch bản đa phiên còn tệ hơn (86 lần).

Tại sao cache không giúp ích cho cách truyền thống? Cache của Anthropic mặc định 1 giờ cho các gói trả phí. Giữa lúc suy nghĩ, chuyển cửa sổ hoặc bắt đầu phiên mới, cache trước đó thường bị loại bỏ.

Trong phương pháp này, các bài báo không bao giờ vào Claude, vì vậy cache hit không quan trọng.

Khi tài liệu tăng gấp đôi (100, 200 bài báo), khoảng cách mở rộng tuyến tính. cache_creation truyền thống tăng theo số lượng bài báo; phương pháp này gần như không đổi.

Dành cho những ai chạy nghiên cứu trên Opus: Một năm các phiên nghiên cứu có thể tạo ra chênh lệch $2,000—chỉ cần giữ các bài báo ra khỏi Claude cũng đủ tiết kiệm để nâng cấp lên Max một lần nữa.

Cái giá phải trả: Chậm hơn 3 lần

Nếu bạn quan tâm đến vài giây thời gian phản hồi hơn là hóa đơn hàng tháng, thiết lập này không dành cho bạn.

Các phần sau đây phác thảo ba quy trình làm việc phù hợp với NotebookLM.

Phần V: Quy trình cho Nhà nghiên cứu / Sinh viên

Một danh sách đọc là một ranh giới tri thức tự nhiên.

Nỗi đau: Hàng chục bài báo mỗi học kỳ, kiểm tra đi kiểm tra lại cùng một file PDF. Ctrl-F kiệt sức, và ChatGPT có thể bịa đặt mà không có trích dẫn.

Công thức tài liệu (Tải lên một lần, dùng cả học kỳ):

• 20-50 file PDF bài báo liên quan đến chủ đề
• Đề cương khóa học, bản ghi bài giảng
• Email cố vấn, bản nháp chương, ghi chú đọc

Câu hỏi "chết chóc" cho Giáo viên:

• "Hai bài báo nào có kết luận mâu thuẫn và dựa trên giả định nào?"
• "Phương pháp X xuất hiện bao nhiêu lần trong kho tài liệu này và được sử dụng như thế nào?"
• "Công thức 3 trong Bài báo A và công thức 7 trong Bài báo B có thực sự tương đương không?"

Vai trò của Claude: Thúc đẩy dự án—lấy khái niệm/công thức từ giáo viên → viết code để tái tạo → chạy thử nghiệm → sắp xếp ghi chú. Các bài báo gốc không bao giờ vào phiên Claude.

Phần VI: Quy trình cho IPO / Bản cáo bạch

Một bản cáo bạch dài 300-600 trang và thời gian đầu tư chỉ có ba ngày. Con người không thể đọc hết kịp.

Nỗi đau: IPO diễn ra nhanh. Tài liệu dài 500+ trang bao gồm lịch sử công ty, mô hình kinh doanh, tài chính, rủi ro và nhà đầu tư nền tảng. Đọc một bản mất ít nhất 4 giờ. Với 5-8 IPO mỗi tuần, không thể làm được.

Thông tin giá trị nhất không phải là lời khen bản thân; mà là "cờ đỏ" ẩn trong các yếu tố rủi ro và giao dịch với bên liên quan. Con người dễ bỏ sót những điều này.

Công thức tài liệu (Một notebook cho mỗi công ty):

• Bản cáo bạch đầy đủ—Cốt lõi.
• Tiết lộ nhà đầu tư nền tảng—Ai đang hậu thuẫn họ và trong bao lâu?
• Báo cáo tài chính đối thủ—Điểm chuẩn cho định giá.
• Nghiên cứu của nhà bảo lãnh/người bảo lãnh phát hành—Logic định giá chính thức.
• Phỏng vấn ban quản lý & Các vòng gọi vốn trước đây—Bước nhảy định giá.

Câu hỏi "chết chóc" cho Giáo viên:

Để quyết định có đầu tư hay không, hãy hỏi 8 câu hỏi này thường mất hàng giờ để tìm:

1. "Sản phẩm cốt lõi là gì? Cơ cấu doanh thu đã thay đổi như thế nào trong 3 năm? Mức độ tập trung khách hàng?"
2. "So với các đối thủ (A, B, C) về biên lợi nhuận gộp, tăng trưởng và R&D như thế nào?"
3. "Ai là nhà đầu tư nền tảng, số tiền và thời gian khóa?"
4. "Phân tích việc sử dụng số tiền huy động được. Phần lớn nhất là gì? Pha loãng sau IPO?"
5. "Yếu tố rủi ro nào áp dụng cho toàn ngành so với riêng công ty?"
6. "Định giá quá khứ: Bội số nhảy từ vòng cuối lên IPO? Khóa vòng cuối?"
7. "Có dấu hiệu lợi nhuận một lần thổi phồng lợi nhuận không? Dòng tiền có khớp với lợi nhuận ròng trong 3 năm không?"
8. "Giao dịch với bên liên quan tính theo % doanh thu? Có bên liên quan nào trong số năm khách hàng lớn nhất không?"

Mỗi câu trả lời đều bao gồm trích dẫn [Số trang].

Vai trò của Claude:

Xử lý hàng loạt là linh hồn của quy trình này:

Nhóm IPO hàng tuần = [Cổ phiếu A, Cổ phiếu B, Cổ phiếu C, ...]

Claude tóm tắt 8 công ty thành một bảng quyết định markdown → Bạn xem qua và đặt hàng trong 15 phút.

5-8 IPO = 40-64 truy vấn. Tổng tài liệu khoảng 1 triệu token. Phương pháp truyền thống sẽ đốt $50+ mỗi tuần; phương pháp này tốn dưới $2.

Phần VII: Quy trình cho Cơ sở tri thức cá nhân

Xây dựng "Bộ não thứ hai" của bạn.

Nỗi đau: Tìm kiếm của Obsidian chỉ nhận diện từ khóa. Nó không thể trả lời "Quan điểm của tôi về X đã thay đổi như thế nào trong ba năm?" Các ghi chú rải rác và đa dạng về định dạng.

Công thức tài liệu:

• Xuất dữ liệu toàn bộ từ Obsidian / Notion
• Điểm nổi bật từ Kindle, clip từ Readwise
• Nhật ký công việc, biên bản họp, tài liệu đánh giá

Câu hỏi "chết chóc" cho Giáo viên:

• "Tôi đã viết gì về 'sự tập trung' trong ba năm qua? Quan điểm của tôi có thay đổi không?"
• "Ở đâu 'Nguyên tắc' và 'Tư duy Nhanh và Chậm' chồng chéo hoặc mâu thuẫn về thiên kiến nhận thức?"
• "Thái độ của từng cá nhân đối với Dự án X trong tất cả biên bản họp tháng trước là gì?"

Vai trò của Claude: Các câu hỏi về sự tiến hóa của tư duy cần AI hội thoại + toàn bộ tài liệu. Claude tổng hợp các câu trả lời nhiều vòng của giáo viên thành các bản tóm tắt có cấu trúc (dòng thời gian, so sánh quan điểm, danh sách theo dõi).

Điểm chung của ba quy trình: Truy vấn lặp lại, xuyên tài liệu, ranh giới riêng tư. Nếu bạn gặp bất kỳ điểm nào trong số này, chi phí thiết lập 15 giây sẽ tự trả trong vòng một tuần.

Suy nghĩ cuối cùng

Những điểm cần lưu ý:

1. storage_state.json chứa phiên Google đang hoạt động của bạn. Hãy giữ nó an toàn.
2. notebooklm-client được kỹ thuật đảo ngược. Google không chính thức hỗ trợ nó; backend có thể thay đổi.

Cốt lõi của điều này là Phân công Lao động:

• NotebookLM là Giáo viên: Trả lời kiến thức chuyên ngành với trích dẫn, không bịa đặt.
• Claude là Trợ lý: Điều phối công cụ, viết mã, sắp xếp kết quả, hỏi giáo viên khi bí.
• Bạn là Trưởng dự án: Can thiệp chỉ tại các điểm quyết định chính.

Tôi đã dùng nó trong một tháng, và số tiền tiết kiệm được đủ cho vài bữa tối ngon. Quan trọng hơn, nghiên cứu hàng chục bài báo không còn khiến tôi lo lắng về hạn mức—sự tự do của việc "không phải đếm token" gây nghiện hơn cả số tiền tiết kiệm được.

Nếu bạn thích bài viết này, hãy theo dõi tôi @MinLiBuilds.

Cuối cùng, tôi giới thiệu phần đầu tiên của loạt bài về cache của tôi, giải thích cơ chế caching một cách đơn giản để giúp bạn tiết kiệm token:

https://x.com/MinLiBuilds/status/2041178722230030384