OpenCode.io.vn
Quay lại Blog
24 tháng 5, 2026OpenCode Vietnam8 phút đọc

Cách dùng Cursor Composer 2.5 trong OpenCode: setup API proxy, giá token và rủi ro bảo mật

Hướng dẫn cấu hình Cursor Composer 2.5 trong OpenCode qua proxy OpenAI-compatible, kèm phân tích giá token, Cursor API key, ToS và rủi ro bảo mật khi dùng proxy bên thứ 3.

#cursor#composer-2.5#opencode#huong-dan#ai-coding#api-proxy#terminal
Cách dùng Cursor Composer 2.5 trong OpenCode: setup API proxy, giá token và rủi ro bảo mật

Cách dùng Cursor Composer 2.5 trong OpenCode: setup API proxy, giá token và rủi ro bảo mật

Nếu bạn thích workflow terminal của OpenCode nhưng lại muốn thử Composer 2.5 của Cursor, cộng đồng đang chia sẻ một cách làm khá thú vị: dùng một proxy OpenAI-compatible để OpenCode có thể gọi model này.

Nghe thì đơn giản, nhưng với người mới sẽ có 3 câu hỏi lớn:

  1. Cách này thực chất hoạt động như thế nào?
  2. Phải cấu hình OpenCode ra sao?
  3. Có rủi ro gì về bảo mật, độ ổn định và điều khoản sử dụng?

Bài viết này sẽ đi từng bước thật dễ hiểu.

⚠️

Bài viết dựa trên một bài Reddit và thảo luận từ cộng đồng, không phải tài liệu chính thức của Cursor. Vì vậy hãy xem đây là một cách làm thử nghiệm, không phải hướng dẫn production chính thức.


Tóm tắt nhanh

Ý chính của bài Reddit là:

  • Giờ đã có cách dùng Composer 2.5 của Cursor trong OpenCode
  • Cách này đi qua một API proxy bên thứ 3
  • Proxy đó chuyển request thành chuẩn mà OpenCode hiểu được
  • Theo bài post, mức giá được nhắc tới là:
    • $0.50 / 1 triệu input tokens
    • $2.50 / 1 triệu output tokens
  • Bạn vẫn cần có Cursor API key, và theo bài viết thì điều này yêu cầu gói Cursor $20/tháng

Nói ngắn gọn: thay vì chỉ dùng Composer bên trong Cursor IDE, bạn có thể gọi nó từ OpenCode để giữ workflow terminal quen thuộc.


Tại sao nhiều người muốn làm vậy?

Lý do không hẳn vì Cursor IDE kém. Ngược lại, Cursor rất mạnh.

Nhưng có nhiều developer thích harness của OpenCode hơn vì:

  • thích làm việc trong CLI/TUI
  • muốn dùng nhiều model trong cùng một giao diện
  • muốn tự chỉnh config, provider, workflow
  • muốn gắn với môi trường terminal, automation hoặc server

Tức là họ không đổi vì ghét Cursor. Họ đổi vì thích trải nghiệm làm việc của OpenCode, nhưng vẫn muốn dùng model của Cursor.


Cách này hoạt động như thế nào?

Có 3 thành phần trong luồng này:

  1. OpenCode: công cụ bạn đang dùng để chat với coding agent
  2. Proxy OpenAI-compatible: lớp trung gian để OpenCode có thể gửi request theo format quen thuộc
  3. Cursor / Composer 2.5: model đích mà bạn muốn dùng

Luồng đơn giản là:

OpenCode -> Proxy bên thứ 3 -> Cursor Composer 2.5

Vì Cursor hiện không public một API “chuẩn OpenAI-compatible” dành riêng cho OpenCode, nên cộng đồng mới dùng proxy để nối hai bên lại với nhau.


Bạn cần chuẩn bị gì trước?

Trước khi bắt đầu, hãy chuẩn bị:

  • đã cài OpenCode
  • tài khoản Cursor trả phí
  • Cursor API key
  • chấp nhận đây là một cách làm không chính thức

Nếu bạn đang làm việc với dữ liệu nhạy cảm, code nội bộ hoặc dự án của team, hãy đọc kỹ phần rủi ro ở cuối bài trước khi dùng.


Bước 1: lấy Cursor API key

Theo bài Reddit, bạn cần có Cursor API key và điều này gắn với gói Cursor $20/tháng.

Sau khi có key, bạn nên lưu nó vào biến môi trường, thay vì hard-code trực tiếp trong file config.

macOS / Linux

export CURSOR_API_KEY="crsr_..."

Nếu muốn tự động load mỗi lần mở terminal, bạn có thể thêm dòng này vào file như .zshrc hoặc .bashrc.

Windows PowerShell

$env:CURSOR_API_KEY="crsr_..."
💡

Đừng dán API key thẳng vào file cấu hình nếu có thể tránh. Dùng biến môi trường sẽ an toàn hơn và dễ thay key hơn sau này.


Bước 2: mở file cấu hình của OpenCode

Bạn cần chỉnh file:

~/.config/opencode/opencode.json

Trong file này, bạn thêm một provider mới cho Cursor thông qua proxy.

Đây là cấu hình được cộng đồng chia sẻ:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "cursor/composer-2.5",
  "provider": {
    "cursor": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Cursor API via Standard Agents",
      "options": {
        "baseURL": "https://cursor-api.standardagents.ai/opencode/v1",
        "apiKey": "{env:CURSOR_API_KEY}"
      },
      "models": {
        "composer-2.5": {
          "name": "Cursor 2.5",
          "cost": {
            "input": 0.5,
            "output": 2.5
          },
          "limit": {
            "context": 200000,
            "output": 65536
          }
        }
      }
    }
  }
}

Nếu bạn đã có opencode.json từ trước, chỉ cần thêm phần provider mới và chỉnh model mặc định cho phù hợp, không nhất thiết phải ghi đè toàn bộ file.


Bước 3: hiểu config này theo cách dễ nhất

Với người mới, đoạn JSON trên khá đáng sợ. Thật ra nó chỉ đang nói 5 ý chính.

1. Chọn model mặc định

"model": "cursor/composer-2.5"

Nghĩa là khi OpenCode khởi động, model mặc định sẽ là Composer 2.5 trong provider tên cursor.


2. Báo cho OpenCode biết đây là provider kiểu OpenAI-compatible

"npm": "@ai-sdk/openai-compatible"

Ý nghĩa thực tế:

  • OpenCode không cần hiểu riêng API của Cursor
  • nó chỉ cần biết đây là một endpoint nói cùng “ngôn ngữ” với chuẩn OpenAI-compatible

3. Chỉ ra địa chỉ proxy trung gian

"baseURL": "https://cursor-api.standardagents.ai/opencode/v1"

Đây là endpoint của bên thứ 3.

Tức là OpenCode không gọi thẳng Cursor, mà gọi qua proxy này trước.

Đây cũng chính là phần nhạy cảm nhất của toàn bộ cách làm.


4. Lấy API key từ biến môi trường

"apiKey": "{env:CURSOR_API_KEY}"

Nghĩa là OpenCode sẽ đọc key từ biến môi trường CURSOR_API_KEY mà bạn đã export ở bước 1.


5. Khai báo thông tin model

"composer-2.5": {
  "name": "Cursor 2.5",
  "cost": {
    "input": 0.5,
    "output": 2.5
  },
  "limit": {
    "context": 200000,
    "output": 65536
  }
}

Phần này chủ yếu để OpenCode biết:

  • tên model để hiển thị
  • giá token để ước tính chi phí
  • context window khoảng 200K token
  • output tối đa khoảng 65K token
ℹ️

Các con số về giá và limit trong config này là thông tin được bài post cộng đồng chia sẻ. Trước khi dùng nghiêm túc, bạn nên tự kiểm tra lại vì chính sách giá và quota có thể thay đổi.


Bước 4: khởi động lại OpenCode và kiểm tra

Sau khi lưu config:

  1. mở lại terminal
  2. đảm bảo biến CURSOR_API_KEY đang tồn tại
  3. chạy OpenCode như bình thường
  4. kiểm tra model hiện tại có phải cursor/composer-2.5 không

Nếu OpenCode có command chọn model, bạn cũng có thể mở danh sách model để xác nhận provider mới đã xuất hiện.

Nếu gặp lỗi, hãy kiểm tra lần lượt:

  • API key có đúng không
  • biến môi trường đã được export chưa
  • JSON có thiếu dấu phẩy hoặc dấu ngoặc không
  • endpoint proxy còn hoạt động không

Vậy ưu điểm của cách này là gì?

Nếu nó chạy ổn, bạn có thể nhận được 3 lợi ích khá hấp dẫn.

1. Giữ được workflow của OpenCode

Bạn vẫn dùng terminal, config, workflow và giao diện quen thuộc của OpenCode.

2. Có thể rẻ và nhanh

Theo bài post, Composer 2.5 được cộng đồng thích vì:

  • khá nhanh
  • chi phí thấp hơn nhiều model coding cao cấp khác

3. Dùng chung với nhiều provider khác

Bạn có thể giữ OpenCode làm nơi làm việc chính, rồi:

  • task đơn giản dùng model rẻ
  • task khó đổi sang model khác
  • khi muốn thử Composer 2.5 thì chỉ cần chuyển model

Nhưng có 4 rủi ro lớn người mới phải hiểu

Đây là phần quan trọng nhất của bài.

1. Đây không phải cách chính thức

Bài Reddit và phần bình luận đều cho thấy đây là một giải pháp không chính thức.

Điều đó có nghĩa là:

  • có thể không được Cursor hỗ trợ
  • có thể có rủi ro liên quan tới ToS
  • có thể bị thay đổi hoặc ngừng hoạt động bất kỳ lúc nào

Nếu bạn đang tìm một giải pháp bền lâu cho production, đây chưa chắc là lựa chọn tốt.


2. Có rủi ro bảo mật vì đi qua proxy bên thứ 3

Đây là cảnh báo lớn nhất.

Khi bạn dùng:

OpenCode -> proxy của người khác -> Cursor

thì API key của bạn đang đi qua server không phải do bạn kiểm soát.

Ngay cả khi project đó có open source repo, vẫn có một sự thật rất quan trọng:

Bạn không thể chắc server đang chạy ngoài đời đúng 100% với code trên GitHub.

Nếu bạn định dùng lâu dài, hướng an toàn hơn là:

  • tự host proxy
  • hoặc tự deploy bản proxy của riêng mình
  • hoặc chỉ dùng để thử nghiệm cá nhân với dữ liệu không nhạy cảm

3. Độ ổn định không đảm bảo

Một proxy cộng đồng có thể:

  • chậm hơn khi nhiều người cùng dùng
  • thay đổi endpoint
  • bị rate limit
  • bị chặn
  • dừng hoạt động đột ngột

Vì vậy nếu hôm nay chạy ngon, không có nghĩa tuần sau vẫn vậy.


4. Trải nghiệm model có thể khác khi ra khỏi Cursor IDE

Có người trong phần bình luận nghi ngờ rằng Composer 2.5 sẽ không mạnh bằng khi chạy trong Cursor harness gốc.

Đây là lo ngại hợp lý, vì chất lượng agent không chỉ nằm ở model mà còn nằm ở:

  • prompt hệ thống
  • tool-use
  • context management
  • cách IDE/harness bọc model lại

Nói dễ hiểu: cùng một model, nhưng ở môi trường khác nhau thì trải nghiệm có thể khác.


Có phải trả $20/tháng rồi còn trả tiền token nữa không?

Theo lời tác giả bài Reddit, gói $20/tháng đã có quota đi kèm và không nhất thiết giống kiểu “vừa thuê bao vừa mua token riêng” như một số API khác.

Tuy nhiên, đây vẫn chỉ là thông tin từ cộng đồng, không phải tài liệu chính thức mà bạn nên xem là cam kết lâu dài.

Cách an toàn nhất là:

  • tự kiểm tra trong tài khoản Cursor
  • đọc kỹ docs hoặc thông báo billing mới nhất
  • theo dõi usage thực tế sau khi cấu hình

Composer 2.5 có thật sự mạnh không?

Trong phần bình luận cũng có tranh luận khá nhiều:

  • có người cho rằng nó chỉ là một biến thể liên quan tới Kimi
  • người khác nói điểm mạnh thật sự nằm ở fine-tune trên dữ liệu coding/chat của Cursor
  • có người đánh giá nó gần với Opus hoặc GPT ở vài tác vụ coding, nhưng rẻ hơn
  • cũng có người cho rằng benchmark từ vendor không nên tin tuyệt đối

Kết luận thực tế là:

  • cộng đồng đánh giá khá tích cực
  • nhưng đây vẫn là đánh giá chủ quan, không phải chân lý tuyệt đối
  • tốt nhất là tự thử trên chính repo và workflow của bạn

Ai nên thử cách này?

Bạn nên thử nếu:

  • thích OpenCode hơn Cursor IDE
  • muốn thử thêm một model coding mới
  • chấp nhận đây là giải pháp thử nghiệm cá nhân
  • không làm việc với dữ liệu quá nhạy cảm
  • sẵn sàng tự debug khi proxy hoặc config có vấn đề

Ai không nên dùng?

Bạn nên tránh nếu:

  • đang làm việc với mã nguồn nội bộ nhạy cảm
  • muốn một giải pháp ổn định dài hạn cho team
  • cần compliance hoặc audit bảo mật nghiêm túc
  • không muốn API key đi qua bên thứ 3
  • cần một setup hoàn toàn chính thức và được vendor hỗ trợ

Kết luận

Nếu nhìn một cách công bằng, đây là một mẹo rất thú vị của cộng đồng:

  • nó mở đường cho việc dùng Composer 2.5 ngay trong OpenCode
  • rất hợp với người thích terminal workflow
  • có thể nhanh, rẻ và tiện

Nhưng đổi lại, bạn phải chấp nhận 3 chữ lớn:

không chính thức, có rủi ro, và chưa chắc bền lâu.

Lời khuyên thực tế của mình là:

  • dùng để thử nghiệm cá nhân: khá đáng thử
  • dùng cho team hoặc production: phải cực kỳ cẩn thận
  • dùng với dữ liệu nhạy cảm: nên tránh, hoặc tự host proxy riêng

Nếu bạn chỉ cần một câu chốt dễ nhớ:

Đây là một cách hack khá hay để mang Composer 2.5 từ Cursor sang OpenCode, nhưng hãy xem nó như một bản thử nghiệm cộng đồng, không phải một cầu nối chính thức để yên tâm dùng lâu dài.

Đọc tiếp

Một vài bài liên quan có thể bạn sẽ thích