Cursorを自分のコードや社内の仕組みから動かす：Cloud Agents API、SDK、Admin・Analytics・Bugbotの各APIの違いと、キー・制限・最小の例を公式ドキュメントで確かめる

この記事は、実際に使って確かめた記録ではありません。運営者はCursorを入れていますが、使い心地はこの記事には書いていません。この記事は、2026年10月24日にCursorの公式ドキュメントを読んでまとめたものです。コードとcurlの例は、公式ページの例を写したもの、またはそのパスと項目名から僕らが組んだものです。後者は「この記事の整理」と明記し、どちらも実行していません。ベータやAlphaの機能、上限の数字、プランの条件は変わることがあります。契約や法律の助言ではありません。

先に結論

• まず、何をしたいかでAPIを選びます。 「エージェントに作業をさせたい」はCloud Agents APIかSDK。「メンバーや使用量を管理したい」はAdmin API。「導入の効果を見たい」はAnalytics APIとAI Code Tracking API。「PRを見てほしい」はBugbot APIです。
• 手元のプログラムから使うなら、SDKが近道です。 公式は、PythonとTypeScriptのSDKを用意し、手元で動く「local」とCursorの仮想マシンで動く「cloud」を選べると書いています。HTTPで直接呼びたいときは、Cloud Agents APIです。
• 鍵は人に依存させないほうが安全です（僕らの見立てです）。 公式のサービスアカウントのページは、人ではない自動化用のアカウントで、席のライセンスを使わず、使用量はチームのプールから引かれる、と書いています。ただしサービスアカウントはEnterpriseのみです。
• 「上限と課金」を先に読みます。 SDKの実行は、エディタやCloud Agentsと同じ料金と使用量の枠に従います。APIの呼び出し自体の別料金は、読んだ範囲では見つかりませんでした。

前提：用語をそろえる

• API（エーピーアイ）：プログラム同士がやり取りするための窓口です。Cursorでは、https://api.cursor.com に、キーを付けてHTTPで呼びます。
• SDK：APIを自分の言語で使いやすくした部品です。Cursorでは、@cursor/sdk（TypeScript）と cursor-sdk（Python）です。
• エージェント（agent）と実行（run）：Cloud Agents APIでは、エージェントは作業の入れ物（会話と作業場所）で、実行はその中での1回の依頼です。1つのエージェントに、実行を続けて足していけます。
• ローカル（local）とクラウド（cloud）：SDKの2つの動かし方です。ローカルは自分のコンピュータのファイルを読み書きします。クラウドはCursorが用意した隔離された仮想マシンで、リポジトリをクローンして動きます。
• サービスアカウント：人ではないアカウントです。自動化のために、人の個人アカウントと切り離してキーを持たせます。
• スコープ：キーに許す操作の範囲です。admin:*、read:* のように書かれています。

公式のAPIとSDKの一覧

公式の「Cursor APIs Overview」の一覧を、僕らが並べ直しました（2026年10月24日確認）。

「Enterprise向け」の線引きは、ページによって細かさが違います。一覧は、Admin APIを「Enterprise teams」と書きます。一方、Admin APIの個別ページは、ひとつのプラン条件を示さず、支出の上限の設定、一括設定、メンバーの削除に「Enterprise only」と付けています。使えるかどうかは、自分のプランで試すか、公式のページで確かめてください。Origin APIは、一覧の1行しか読んでいません。

公式が書いている大事な線引き。 一覧のページには、Cloud Agents APIとSDKは、単独のモデル推論のAPIやチャット補完のAPIではない、とあります。Autoなどでモデルを選ぶのは、エージェントの実行のときにCursor Routerがやる、とも書かれています。僕らが探した範囲では、Cursorのモデルだけを直接呼ぶ公式のAPIは見つかりませんでした。

キーの作り方と種類

公式の整理を、1つの表にします。

認証の書き方は、公式の例が示すとおりです。

curl https://api.cursor.com/teams/members \
  -u YOUR_API_KEY:

これはBasic認証で、キーをユーザー名にして、パスワードは空です。公式は、同じ内容を Authorization: Basic {base64_encode('YOUR_API_KEY:')} というヘッダーでも書いています。Cloud Agents APIは、Bearerでも通ります。公式の例は Authorization: Bearer YOUR_API_KEY で、https://api.cursor.com/v1/me を呼ぶ形です。

キーの持ち主。 公式の一覧のページは、キーは組織に結びつき、管理者は全員が見られ、最初に作った人のアカウントの状態に左右されない、と書いています（管理者用のキーのこと。ユーザーのキーについては、このページに同じ記述は見つかりませんでした）。

サービスアカウント（Enterpriseのみ）。 公式のページによると、席のライセンスは使わず、追加の費用もありません。ダッシュボードの Settings → API Keys → Service Accounts で「New Service Account」を押して作り、名前を付けると、APIキーが1回だけ表示されます。後から取り出せません。このキーは、Cloud Agents APIの認証と、CLIの CURSOR_API_KEY に使えます。ただし、リポジトリでの実行は、チームのCursor GitHubアプリで許可されたものに限られ、個人のGitHub連携だけでは足りません。

• 回転（ローテーション）すると、古いキーは直ちに使えなくなります。
• 一時停止は、削除せずにキーを止めます。再開すれば、回転なしで戻ります。
• アーカイブは、すべてのキーを取り消します。記録は監査用に残ります。
• 使用量はチームのプールから引かれ、チームの分析と請求に出ます。管理者は、請求期間ごとの上限を決められます（新しいアカウントの初期値は上限なし）。上限に達すると、「Service account spend limit reached」のエラーで止まります。
• サービスアカウントからの実行は、チームの管理者全員に見えます。

制限：公式の数字（2026年10月24日確認）

上限は、ユーザー、チーム、組織のいずれかの単位で数えられ、書かれていなければ毎分20回が標準です。

超えると 429 が返ります。管理系のAPIでは Retry-After: 60 が付き、本文は "code": "error" と "message": "Rate limit exceeded" の形、と公式は書いています。公式が勧めるのは、429で指数バックオフ（待ち時間を2倍ずつ増やす）、リクエストの分散、キャッシュ、そして控えめな問い合わせです。使用量のエンドポイントは、1時間に1回までにする、と書かれています。OpenAPIの429の定義には、Retry-After、X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset の4つのヘッダーが付く、とあります（各ヘッダーの意味の説明は、読んだ範囲にはありません）。残りの回数を見て間隔を調整する形が組めます（僕らの見立てです）。

キャッシュ。 Analytics（すべて）とAI Code Trackingは、ETagに対応します。返ってきたETagを If-None-Match に付けて送ると、変わっていなければ 304 Not Modified が返り、この304は上限に数えられない、とあります。Cache-Control: public, max-age=900、つまり15分です。

共通のエラー。 400（パラメーターの誤り）、401（キーが無効）、403（権限なし。たとえばEnterprise機能をEnterprise以外で呼んだとき）、404、429、500です。Cloud Agents APIは、エンドポイントごとに 409 agent_busy のような名前つきのコードを返します。OpenAPIの定義では、エラーは error.code と error.message を持つ形で、401だけ別の形になりうる、とあります。

期間の制限。 Analyticsは、日付の範囲が最大30日、と書かれています。同じページのベストプラクティスに「1〜3か月」という表現もあり、公式の中で食い違っています（30日のほうを基準にしてください）。Adminの監査ログと日別の使用量も、範囲は30日までです。

Cloud Agents API（公開ベータ）を、使う順に

ベースのURLは https://api.cursor.com、パスは /v1/... です（セルフホスト用のワーカーのパスだけ /v0/...）。公式は、一般提供の前に変わることがある、と書いています。

概念：エージェントと実行

エージェントのIDは bc-<uuid> の形で、実行のIDは、公式の例では run-<uuid> の形です。エージェントには状態が3つあり、ACTIVE（実行が動いている、または始まる直前）、IDLE（追加の依頼を受けられる。回復できる失敗もここに戻る）、ARCHIVED（アーカイブ済み、または期限切れ。新しい実行は受けられないが、アーカイブは戻せる）です。実行の状態は別で、CREATING、RUNNING、FINISHED、ERROR、CANCELLED、EXPIRED です。1つのエージェントで同時に動かせる実行は1つで、動いているところに足すと 409 agent_busy になります。

主なエンドポイント

このほか、環境（/v1/environments）、シークレット、ワーカーとプール、実行ごとの使用量（GET /v1/agents/{id}/usage。早期アクセスで、有効でないと 403 feature_unavailable）があります。一覧のURLは公式のllms.txtで確かめられます。

エージェントを作る：POST /v1/agents

作成のリクエストの主な項目です（公式の表の整理）。

公式の例は次のとおりです。長いので、MCPの設定の部分を省いた短縮版です。

curl --request POST \
  --url https://api.cursor.com/v1/agents \
  -u YOUR_API_KEY: \
  --header 'Content-Type: application/json' \
  --data '{
    "prompt": {
      "text": "Add a README with setup instructions"
    },
    "model": {
      "id": "composer-2",
      "params": [
        { "id": "fast", "value": "true" }
      ]
    },
    "repos": [
      {
        "url": "https://github.com/your-org/your-repo",
        "startingRef": "main"
      }
    ],
    "autoCreatePR": true
  }'

応答には、agent（id、name、status、latestRunId など）と run（id、agentId、status が CREATING など）が入ります。モデル名は、SDKのページ（後述）に、Composer 2は退役しており、composer-2 や composer-2-fast を渡したリクエストはComposer 2.5へ振り替えられる、という記述があるので、最初に GET /v1/models で現在の値を確かめてください。

実行の状態を見る、流れを読む、止める

次は、上のパスから僕らが組んだ形です（公式のページにcurlの全文は見つからず、動作確認もしていません）。

# 実行の状態（IDは作成の応答のもの）
curl -u YOUR_API_KEY: \
  https://api.cursor.com/v1/agents/AGENT_ID/runs/RUN_ID

# 実行の流れ（SSE）
curl -N -u YOUR_API_KEY: \
  -H 'Accept: text/event-stream' \
  https://api.cursor.com/v1/agents/AGENT_ID/runs/RUN_ID/stream

# 取り消す（元に戻せない）
curl -X POST -u YOUR_API_KEY: \
  https://api.cursor.com/v1/agents/AGENT_ID/runs/RUN_ID/cancel

流れ（ストリーム）のイベントは、status、assistant（文章の差分）、thinking、tool_call、heartbeat、result、error、done などです。interaction_update は、より細かいSDK形式のイベントで、公式は、これと簡略版を両方処理しないよう書いています。切れたら、最後に受け取ったイベントのIDを Last-Event-ID に付けて再接続します。保持期間は応答のヘッダー X-Cursor-Stream-Retention-Seconds で分かります。期限切れで410が返ったら、再接続を繰り返さず、実行の取得に切り替えます。

Webhook（状態の変化を受け取る）

公式のWebhookのページによると、イベントは今のところ statusChange だけで、エージェントが ERROR か FINISHED になったときに、POSTで届きます。ヘッダーは X-Webhook-Signature（sha256=<hex>）、X-Webhook-ID（配信ごとのID）、X-Webhook-Event、User-Agent: Cursor-Agent-Webhook/1.0 です。本文のJSONには event、timestamp、id、status、source、target、summary が入ります。

署名の確かめ方は、秘密の値で、解析する前の生の本文をHMAC-SHA256にかけ、sha256= を付けて、ヘッダーと比べる、です。公式は、署名の検証、2xxをすぐ返す、本番ではHTTPS、生の本文を保存しておく、を勧めています。失敗したときは再送されることがあります。次は僕らの整理で、公式の説明にあるアルゴリズムを書いただけの形です。

import hmac, hashlib

def verify(secret: str, raw_body: bytes, header: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret.encode(), raw_body, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, header)

未確認の点が3つあります。Webhooksのページには、Webhook URLをエージェントの作成のときにどの項目名で渡すかが書かれていません。Cloud Agents APIのエンドポイントのページには、Webhookは「近日公開」で、旧v0のAPIは今も対応している、とあり、v1の作成リクエストにはWebhook URLの項目が見当たりません。Webhooksのページがどちらの版の話かは、書かれていません。タイムアウトの秒数も、ページにはありません。使う前に、公式の最新の表示を確かめてください。

シークレットと環境

シークレットは、チーム、個人、環境の3つの範囲で扱えます。応答に値は含まれず、名前と種類だけです。同じ名前が複数の範囲にあるときの優先は、エージェントの起動時に渡した envVars、環境、個人、チームの順です。値は1〜4,096バイト、各範囲に最大1,000個です。変更は、あとから起動するエージェントにだけ届き、動いているものは元の値のままです。公式は、「読み出しは書き込みに遅れることがある」と書いています。

SDK：TypeScriptとPython

比較表

公式の最小の例（TypeScript）は、ローカルで動かし、イベントを流す形です。

import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2.5" },
  local: { cwd: process.cwd() },
});

const run = await agent.send("Summarize what this repository does");

for await (const event of run.stream()) {
  console.log(event);
}

Pythonの最小の例です（公式のまま。crsr_key は置き換え用の文字列です）。

import os

from cursor_sdk import Agent, LocalAgentOptions

with Agent.create(
    model="composer-2.5",
    api_key="crsr_key",
    local=LocalAgentOptions(cwd=os.getcwd()),
) as agent:
    print(agent.send("Summarize what this repository does").text())

クラウドで動かすときは、cloud: { repos: [{ url: "https://github.com/your-org/your-repo" }] } を渡す形です（公式の断片）。Agent.resume("bc-abc123", ...) で、IDから再び接続できます。実行は await run.cancel()、モデルの一覧は await Cursor.models.list()、成果物は agent.listArtifacts() と agent.downloadArtifact(path) です。

認証の読まれ方と、ローカルの注意

認証は、明示した apiKey、環境変数 CURSOR_API_KEY、保存されたログインの順に読まれます。Cursor.auth.login() はブラウザのログインで、ユーザーのAPIキー（既定で90日）を ~/.cursor/sdk/auth.json に保存します。

ローカルで動かすときは、前のガイド（07）に書いたとおり、道具の呼び出しは承認なしで動くのが既定です。今回読み直したSDKのページでは、次のように書かれていました。

• local.sandboxOptions.enabled の既定は false です。有効にすると、書き込みは作業フォルダ、一時フォルダ、許可したパスに限られ、外向きの通信は初期状態で拒否されます。ただし、読み取りは作業場所に限られません。
• local.autoReview: true で、道具の呼び出しを分類器に通せます。止められた呼び出しは拒否され、人には回りません。
• local.settingSources を指定しないと、ローカルのエージェントは、コードで渡したMCPサーバーだけを読み込みます。ディスク上の設定の層（プロジェクトの .cursor/ とユーザーの ~/.cursor/）は、指定したときだけ読まれます。
• フックは、ファイルでの設定だけです（コードでのコールバックはありません）。

1回きりの呼び出しと、道具を絞る

スクリプトから1回だけ聞きたいときは、Agent.prompt() が手軽です。公式は、エージェントを作り、1つの依頼を送り、実行の終わりを待ち、後始末までする1回きりの便利関数、と説明しています。公式の例は次のとおりです。

const result = await Agent.prompt("What does the auth middleware do?", {
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2.5" },
  local: { cwd: process.cwd() },
});

承認のない場所で動かすなら、モデルに渡す道具を先に絞れます。公式によると、tools は許可する組み込み道具の一覧で、未指定なら、そのモデルの標準の道具がそろいます。tools: [] なら道具なしで、文章を返すだけです。disallowedTools は、挙げた道具だけを外し、あとから増えた道具は残します。どちらもローカルのエージェント専用で、保存されないため、Agent.resume() でもう一度渡します。両方あるときは、外す指定が勝ちます。"mcp" を外すとカスタムの道具も消え、"task" を外すとサブエージェントが使えません。知らない名前は ConfigurationError になります。読むだけにする公式の例は次のとおりです。

const reader = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2.5" },
  tools: ["read", "grep", "glob", "ls"],
  local: { cwd: process.cwd() },
});

クラウドで動かして自動でPRを作るときは、cloud.openAsCursorGithubApp に注意します。公式の表では、「APIキーの持ち主ではなく、Cursor GitHub AppとしてPRを開く」設定で、既定はサービスアカウントのキーなら true、ユーザーのキーなら false です。同じ自動化でも、キーの種類でPRの作成者の見え方が変わりえます。

SDKのエラーの種類

実際に回すと最初に当たるのがエラーです。公式によると、SDKのエラーはすべて CursorSdkError を継承し、isRetryable、code、status、endpoint、requestId などを持ちます。

このほか、通信の一時的な失敗の NetworkError や、AgentNotFoundError などがあります。

課金と使用量

公式は、SDKの実行は、エディタやCloud Agentsと同じ料金、使用量の枠、Privacy Modeの規則に従う、と書いています。チームの使用量の画面に、SDKのタグ付きで出ます。サービスアカウントのキーはチームに、ユーザーのキーはその人のプランに請求されます。agent.getUsage() は、請求された分の使用量と費用をセント単位で返します。chargedCents は、プランに含まれる分、自分のモデルキーの分、クレジット付与の分では0になります。ローカルの使用量の取得は、アカウントごとに段階的に有効になり、まだのときは 403 feature_unavailable です。

更新履歴から、注意しておきたい点

SDKの更新履歴（見出しの表示に日付はありません。取得のしかたで内容が違い、HTML版は1.0.35が最新、md版は1.0.40が最新でした）から、使う人に関係する3つを挙げます。

• 1.0.38： zod がpeer dependency（自分で入れる依存）になり、3.25以上か4.x系が必要です。
• 1.0.27： 複数のフォルダを渡す local.dirs が登場し、cwd は主になる1つのディレクトリだけを指す形になりました（旧来の cwd の配列形式の置き換え）。ブラウザのログインも、この版で入りました。
• 1.0.24： TypeScriptとPythonが、同じ版番号でいっしょに出るようになりました。

SDK Bridge

他の言語（Go、Rust、Java、C#など）から使うための、小さなローカルサーバーです。sdk.v1 という契約（Connect/protobuf）で、TypeScript SDKと同じ機能を出します。公式は、アプリの開発者には @cursor/sdk か cursor-sdk を勧め、Bridgeは、SDKを作る人やプラットフォームのチーム向けと書いています。別の言語のアダプターは、Cursorの公式SDKではなく、バージョン、サポート、セキュリティの確認は作った人の責任です。ブリッジは、既定で 127.0.0.1 だけで待ち受けます。公式は、sdk.v1 の契約とブリッジのバイナリはCursorが公開し、サポートする、とも書いています。ただし、リポジトリ側の詳しいドキュメント（起動のオプション、ハンドシェイクの形式など）は、読んでいません。

管理者向けのAPI：管理、分析、レビュー

Admin API

ベースは同じ https://api.cursor.com、認証はBasicです。公式のページから、主なエンドポイントを選びました。

公式の削除の例は、POST /teams/remove-member に {"email": "..."} を送る形です。実行すると、その人がチームから外れます。まずは GET で読むところから試すのが安全です（僕らの見立てです）。Organization API（/organizations/*、Enterpriseのみ）は、複数のチームをまとめる組織用で、チーム用とキーが別です。組織のキーは、スコープが1つだけです。チームの所属の同期（POST /organizations/team-memberships/sync）は、teamIds で指定したものだけに置き換え、載っていないチームからは外れる、と公式が警告しています。

Analytics API（Enterprise）

GET /analytics/team/... で、チーム全体の日ごとの指標が取れます。公式の一覧では、agent-edits、tabs、dau、models、mcp、commands、skills、leaderboard、bugbot-reviews などがあります。/analytics/by-user/{metric} は、メールアドレスをキーにしたユーザー別です。共通の項目は、startDate と endDate（初期値は7日前と今日、YYYY-MM-DD を推奨、UTCの日）、users です。page と pageSize は、ユーザー別、リーダーボード、Bugbot系など一部のエンドポイントにあります。7d や 30d のような短縮も使えます。会話の洞察は、チームの設定で無効なときに 401 が返ります。公式の例は次のとおりです。

curl -X GET "https://api.cursor.com/analytics/team/agent-edits" \
  -u YOUR_API_KEY:

データの反映の遅れが何分なのかは、ページには見つかりませんでした。

AI Code Tracking API（Enterprise、Alpha）

コミット単位で、TAB（受け入れた補完）、COMPOSER（Agentの編集の受け入れ）、AIでない行に、行数を割り振ります。公式の例は次のとおりです。

curl -X GET "https://api.cursor.com/analytics/ai-code/commits?startDate=7d&endDate=now&page=1&pageSize=100" \
  -u YOUR_API_KEY:

公式が書いている限界は、はっきりしています。計測するのは、ワークスペースの最上位にあるGitリポジトリだけで、複数のルートのワークスペースは対象外です。コミットのハッシュは固有でも永続でもなく、amendしたコミットが2回出ることがあります。Privacy Modeでは、fileName などが省かれることがあります。ページは「Alpha」で、応答の形が変わりうる、と書いています。CSVのエンドポイントは、大量の取り出し向けで、10,000件ずつ流れます。

Bugbot API（Enterprise）

POST https://api.cursor.com/bugbot/review に、prUrl（GitHubのPRかGitLabのMRのURL、必須）と、任意の dryRun を送ります。応答は、outcome、message、request_id、dry_run を持つJSONで、レビューは非同期に動きます。dryRun: true は、分析と保存だけして、Git側には何も投稿しませんが、請求は通常のレビューと同じです。キーは admin:* が要り、結果は GET /analytics/team/bugbot-reviews（read:*）で取ります。公式の例のキーの行を、僕らが組み直した形です。

curl --request POST \
  --url https://api.cursor.com/bugbot/review \
  -u YOUR_API_KEY: \
  --header 'Content-Type: application/json' \
  --data '{"prUrl": "https://github.com/your-org/your-repo/pull/42"}'

Bugbotが無効なリポジトリでは、400 が返り、理由が付きます（公式の例は「Bugbot is disabled for this repository」）。

選び方の表（ここからは僕らの整理です）

最初の10分でやること（僕らの整理です）

1. 使うAPIを、上の表から1つに決めます。Enterpriseの条件があるものは、自分のプランを先に確かめます。
2. キーを作る場所を決めます。個人の試しなら、ダッシュボードの API Keys でユーザーのキーを作ります。チームの自動化なら、サービスアカウント（Enterprise）を検討します。キーは1回しか表示されないので、すぐ秘密の置き場所に入れます。
3. 環境変数 CURSOR_API_KEY に入れ、読むだけのAPIで確かめます。たとえば、GET /v1/me や GET /v1/models、管理者なら GET /teams/members です。
4. エージェントを動かす前に、使用量の画面と、支出の上限（Cloud Agentsは最初に求められる、と前のガイド（07）に書きました）を確かめます。
5. テスト用のリポジトリで、autoCreatePR を使い、workOnCurrentBranch は初期値のfalseのまま、POST /v1/agents を1回だけ試します。結果は、GET /v1/agents/{id}/runs/{runId} で見ます。
6. SDKのlocalを試すときは、先に local.sandboxOptions.enabled と autoReview の意味を読み、テスト用のフォルダだけで動かします。
7. 動いたら、キーを、鍵の置き場所（CIのSecretsなど）に移し、ログに出ていないかを確かめます。

気をつけること

• キーは1回しか見られません。 Admin系の管理者キーも、サービスアカウントのキーも、表示は1回だけです。失くしたら回転です。回転は、古いキーが直ちに使えなくなるので、使っている連携が止まります。
• Enterpriseの線。 403が出たら、プランの条件をまず疑ってください（対象は上の表のとおりです）。
• ベータ、Preview、Alphaの表示。 Cloud Agents APIはベータ、その envVars もベータ（無効だと黙って無視されます）。Adminの一括の支出上限とモデルのアクセスはPreview。AI Code TrackingはAlpha。Origin APIはEarly Beta。公式は、形や挙動が変わりうると書いています。
• 取り消せない操作。 DELETE /v1/agents/{id}（完全な削除）、実行の取り消し、メンバーの削除、グループの削除、チームの所属の同期は、元に戻せないか、戻しにくいと書かれています。
• 承認のない場所で動く。 Cloud Agentsは、端末のコマンドを承認なしで動かします（前のガイド07と02）。ローカルのSDKも、サンドボックスの設定が既定では無効（false）です。読み込ませる内容に仕込まれた指示（プロンプトインジェクション）の危険は、APIから呼んでも変わりません。
• 費用。 SDKの実行は、エディタやCloud Agentsと同じ料金と枠です。getUsage() の費用は、反映に時間がかかることがあります。Bugbotのdry-runも請求されます。使用量の取得APIは、1時間に1回ほどにとどめるよう書かれています。
• 公式の中の食い違い。 Analyticsの範囲は「最大30日」と「1〜3か月」が両方あります。サービスアカウントのページの例のパスが POST /agents と読めましたが、Cloud Agents APIのページのパスは /v1/agents です（/v1 の有無は、僕らは確かめきれていません）。例は、/v1/agents のほうで確かめてください。モデル名は、Composer 2が2.5に振り替えられる、と書かれています。例のコードは、そのまま写さず、現在の値で確かめてください。
• 読めていないもの。 Origin APIの本体、SDKのページの中ほど（Agent.prompt の完全な例、エラーの章の全文）と末尾、Cloud Agents APIの末尾（ワーカーとプールの詳細）、Organization APIの応答の細部、SDK Bridgeの詳しいドキュメント、GitHub側の仕様は読んでいません。更新履歴は、見出しの表示に日付がありませんでした。
• 公式は日々更新されています。名前、上限、プランの条件は変わります。この記事は、セキュリティや契約の助言ではありません。

出典

• Cursor APIs Overview（Cursor Docs、Cursor、確認日2026-10-24）
• Cloud Agents API Endpoints（Cursor Docs、Cursor、確認日2026-10-24）
• Cloud Agents API OpenAPI定義（Cursor Docs、Cursor、確認日2026-10-24）
• Cloud Agents API Webhooks（Cursor Docs、Cursor、確認日2026-10-24）
• Admin API（Cursor Docs、Cursor、確認日2026-10-24）
• Organization API（Cursor Docs、Cursor、確認日2026-10-24）
• Analytics API（Cursor Docs、Cursor、確認日2026-10-24）
• AI Code Tracking API（Cursor Docs、Cursor、確認日2026-10-24）
• Bugbot（Cursor Docs、Cursor、確認日2026-10-24）
• Service Accounts（Cursor Docs、Cursor、確認日2026-10-24）
• TypeScript SDK（Cursor Docs、Cursor、確認日2026-10-24）
• Python SDK（Cursor Docs、Cursor、確認日2026-10-24）
• SDK Bridge（Cursor Docs、Cursor、確認日2026-10-24）
• SDK Release notes（Cursor Docs、Cursor、確認日2026-10-24）
• SDK Release notes（md版、Cursor Docs、Cursor、確認日2026-10-24）