- 2026年7月31日から、Individual・Teamsなどのセルフサービス料金プランのUsageページがトークン専用に変わり、Spend指標・Cost列・CSVのドル建てコストがなくなる
- 含まれる使用量を換算したコストが実際の料金プラン価格より大きく見えて混乱を招くためで、使用量の集約構造が異なるEnterpriseプランではドル表示が維持される
- 変更は閲覧時点で適用されるため、過去のリクエストも
chargedCents: 0、usageBasedCosts: "$0.00"として返され、実際に請求されたオンデマンドリクエストでさえリクエスト別コストを確認できない - Teams管理者はDashboardとAdmin APIで一部の支出データを確認できるが、セルフサービス料金プランでは従来のモデル別ドル建て内訳は提供されない
- ユーザーからは、モデルごとにトークン価格が異なるためコスト・効率・予算を比較しにくいとして、含まれる使用量と実際の請求額を分けたドル建てグラフや表示切り替えオプションを求める声が出ている
セルフサービス料金プランから消えたコスト表示
- 2026年7月31日にデプロイされた変更により、IndividualとTeamsを含むセルフサービス料金プランのUsageページがトークン専用に変更
- Spend指標とCost列が削除
- Usage CSVにもドル建てコストは表示されず、残っているCost値はすべてのレコードで
0.0に設定 - 設定でトークン表示とドル表示を切り替えたり、以前の画面に戻したりすることはできない
- 使用量を集約する構造のEnterpriseプランでは、Usage画面でドル金額を引き続き確認できる
トークン基準に変更した理由
- Individualプランでは含まれる使用量が十分に多く、リクエストをAPI価格で換算した金額が実際の料金プランの費用より大きく見える場合があった
- これによる混乱を減らすため、セルフサービス料金プランの使用量レポート基準をドルからトークンへ切り替えた
- Ultraの含まれる使用量はトークン数と
Includedで表示され、その範囲には別途費用は請求されない - 当初は、含まれる量を超えたオンデマンド使用はCost列とCSVにドルで残ると案内していたが、その後、セルフサービス料金プランのUsage画面とCSVはいずれもドル建てコストを提供しないと訂正した
現在利用できるコスト確認ルート
- Dashboard > Spendingには、現在の請求サイクルのOn-Demand Spending合計が表示され、実際の請求額に対応する
- Teams管理者はDashboard > Members > On-Demandでユーザー別のオンデマンド合計を確認できる
- セルフサービスのTeamsおよびIndividualプランでは、従来のUsage画面が提供していたモデル別ドル建て内訳を見ることはできない
- Teams管理者は、サポートされているAdmin APIを通じて、使用イベントの支出データとコストフィールドを受け取れる
- フォーラムユーザーからは、特定ユーザーと期間のコストを直接取得できるエンドポイントと、より簡単な管理画面を求める声が出ている
Usageエンドポイントと過去データ
https://cursor.com/api/dashboard/get-filtered-usage-eventsは、変更前まで次のようなリクエスト別コストフィールドを返していたchargedCentsusageBasedCoststokenUsage.totalCents
- 2026年7月31日から
chargedCentsは0、usageBasedCostsは"$0.00"になり、totalCentsは省略される - コスト削除がデータを読み取る時点で適用されたため、過去の使用イベントにも遡及され、実際に請求されたオンデマンドリクエストもUsageエンドポイントではコストが消える
- これは一時的なレポートエラーではなく、意図的な変更であることが確認された
- 期間別の総請求額は残っているが、既存フィールドで構築した独立したリクエスト別コストレポートは、もはや同じ方法では動作しない
コスト情報が活用されていた方法
- 多くのユーザーはUsageタブを常時開いたり、1日に何度も確認したりして、日次・週次・月次予算を追跡していた
- Teamsユーザーは共有オンデマンド上限内でメンバー別の使用額を確認し、ユーザー・モデル・リクエスト単位でコストを分析してきた
- あるTeamsユーザーは、現在の請求サイクルの合算使用コストが3万ドルで、その大半がAPI価格ベースだと明かした
- リクエスト前後にUsageページを更新して、モデル別のコストと性能を比較することもあった
- Cursor Grok 4.5のリクエスト後、約**$0.32**増加
- Opus 5の使用後、約**$2.56**増加
- 一部のユーザーは、表示された金額を実際の請求額ではなく、サブスクリプション料金によって得た利用価値とコスト削減額を見積もる数値として活用していた
- モデルごとにトークン価格が異なるため、トークン数だけではコストと費用対効果を直接比較しにくい
ユーザーが求める代替案
- デフォルトをTokensのままにしても、従来のドル建てグラフを選択できるトグルまたはドロップダウンを提供してほしいという要望が出ている
- 含まれる使用量の換算価値と実際に請求されるオンデマンド金額をチャートで分離すれば、混乱を減らしつつドル情報も維持できる
- ユーザー別合計だけでは日別・モデル別・リクエスト別分析の代替にはならず、Cost列とリクエスト別APIフィールドの復元を求める声が続いている
- トークンベースの価格体系へ長期的に移行する計画があるなら公開すべきであり、今回の変更によって月間支出の推定とコスト管理が難しくなったという反応が多い
サブエージェント選択に関する別の問題
- デフォルトのサブエージェント設定とは異なるモデルが自動選択される問題もあわせて提起された
exploreはサブエージェントの一種であり、Agentは異なるモデルを使う別種のサブエージェントを実行できる- 関連する挙動は Sub agents triggers even when disabled and uses Opus for no reason で追加確認できる
1件のコメント
Hacker Newsのコメント
特定の作業について、ハーネスとモデルの組み合わせごとのトークン使用量を定期的に測定することを勧める。
同じモデルと環境で同じ作業を行っても、エージェントごとにトークン効率と無駄が大きく異なる。
Ubuntu 26.04 VM 上で GPT 5.6 Sol を使い、複数のハーネスでエージェント作業 10 件を繰り返した結果は次のとおり。
https://x.com/__tosh/status/2083593799872237680
Claude Code が OpenAI モデル向けに最適化されていないのは予想どおりだったが、ハーネスだけでここまで差が出るのは衝撃的だった。
自分で開発中の smol は、最小限のシステムプロンプトとシェルツール 1 つだけを使い、機能ファイルもないシンプルなハーネスだ。
人気のハーネスがコンテキストウィンドウにどれだけ多くの内容を押し込んでいるかを過小評価すべきではない。
sedで処理しているのか、独自ツールを作ったのか、そしてなぜ Pi を使わないのか知りたい。2 つのハーネスのトークン差も興味深い。システムプロンプトに大きな差はなく、むしろ Pi の方が短そうで、ツールが 4 つあるだけでこの差を説明するのは難しく、自分でも試してみたい。
コンテキスト使用量は少なくても反復回数の多い監視ループのような作業では、コストが簡単に 2 倍になり得る。
--disallowed-toolsで不要なツールを削除すべきだが、新しいツールが次々追加されるので終わりのないモグラたたきになる。デフォルトで100 万トークンのコンテキストを使い、自分では制限しない。逆に、smol のキャッシュ読み取りが極端に少ないのは設定の問題かもしれない。
エージェントハーネス比較ツールを探しており、入力・出力だけでなくシステムプロンプト、実行トレース、ツール呼び出しまで見たい。
トークンが少なくても重要なチェックを省いていたなら良い結果ではないし、多いからといって優れているとも限らず、考えすぎていた可能性もある。同じ作業の実行トレース全体を見れば、Codex は多く使い Pi は少なく使う理由を理解するのに役立つ。
2023 年から Cursor を熱心に使って料金も払ってきたが、ここ 6 か月はほとんど開いていない。
最近は Claude Code と Codex でコードを書き、GitHub で読んでレビューし、ローカルで見るときは普通のテキストエディタを使っている。
2026 年の Cursor の価値が何なのか気になる。
また、すべてのモデルをサポートしているので、最初の結果が気に入らないときに別のモデルを試しやすい。
20 ドル帯は競争が激しすぎるので、Cursor のエージェントコーディング用サイドバーより Claude や Codex のプラグインを好む。
ただ、Claude Code と Codex を行き来しながら GitHub でレビューするワークフローは煩雑に見え、Cursor の方がより統合されていて摩擦が少ない。
Cursor の社員として確認したところ、Spending ページで実際の請求額は今も見られる。
古い機能フラグを整理している際に、前日に Usage CSV エクスポート内のドル建てコスト表示を誤って壊してしまったが、現在は修正済み。
そのフラグは一部のセルフサービスユーザーにドル建て使用量グラフも表示していたが、実際には課金されないプラン内利用分までドルで表示して混乱を招いていた。実際の支出だと誤解するユーザーがいたため、グラフを削除した。
管理者だけが見られるという返答なら意味がない。毎日管理者に進捗を聞いたり、セッションごとにモデルの費用対効果を確認してもらったりはできない。
CursorはVisual Studio Codeから簡単に移行できるようにしたことで急速に普及したが、これは諸刃の剣でもある。VS Codeとエージェント拡張に戻るのも簡単だからだ
もともとSublime Textユーザーだったので、VSCodeの基本ショートカットが体に染みついていたのに、Cursorがほぼすべての
CMD組み合わせを横取りするのでうんざりしたいまは高速なコードビューアさえあればよいので、Sublime Textに復帰してもよさそうだ
今後Elonは従業員の給与をトークンで支払い、食料品店もトークンベースの変動価格を表示して、商品を手に取った時点と会計時点で価格が違うようになるのだろう。どうせElonはもうすぐ金は消えると言っていたのだから問題ないはずだ
私は本を読んだり浜辺でじっと座っていたりできず、いつも意味のある場所へ泳いでいなければならないので、次のカナダのWebアプリをバイブコーディングしている最中に夕食のメニューまでCopilotに聞かなければならない
妻を愛しているし、明らかに付加価値もあるが、私のトークンを分けて使おうとすることだけは困る
職場でまさに前日に目撃したが、サービス費用を隠す変更は露骨にユーザーへ敵対的だ
ユーザーには損で会社には得な変更を別のものとして装う方法はない。IDEと、その時点でそこそこ良かったモデル1つを600億ドルで買収したことを正当化しなければならないようだ
ユーザーがAI製品のROIを計算し始めたら、投資額のIを隠せば問題は解決する
厳格な規律と適切なタグ付けを使えば金がどこへ消えているか把握できるが、実際にそうしているところはまれだ
AIを浪費するエンジニアとトークン当たり高い価値を生み出すエンジニアを区別するのを、非常に難しくしようとしているように見える
Cursorはエージェントベースのエンジニアリングに触れる優れた出発点だったが、Claudeの料金競争力は主に大量購入から来ているようだ
本当の防御力はComposer 2.5であり、エージェントとIDEの利用体験はCodexやClaude Desktopに及ばないと思う
経済性ではCursorが最も妥当かもしれないが、価格差が大きくないときはコストより能力が優先される
最近はCodexとClaude Desktopを使い、コード確認が必要なときはZenを使っている。Codexのディクテーションではないリアルタイム音声会話機能は、エージェントのワークフローと組み合わせると他にないものだ
CursorはAnthropic以外のモデルへアクセスするための企業ベンダーだったが、コスト情報が消え、APIリクエストのプロキシも不可能になったことで、価値が大きく下がった
既存プランの条件で更新を強く求めておきながら、すぐに約束を破ったので、経営陣にはCursorの利用を最小限にして更新しないべきだと明確に伝えるつもりだ
特に大企業顧客でないならCursorに知的財産を預けるべきではなく、他のユーザーも信頼しないほうがよい
企業が強欲になっていく典型的な過程だ。当該スレッドは保存してあり、Cursorが閉じるか削除するか気になっている