Anthropic の release notes を眺めていたら、June 2, 2026 のアップデートで二つ気になる変更が入っていた。
一つ目は advisor tool に max_tokens パラメータが追加されたこと。二つ目は stop_reason が refusal で何も出力されなかったリクエストについて、課金されなくなったこと。どちらも地味に見えて、コスト面でかなりえぐい影響がある。
自分が今触ってるプロジェクトは、advisor モデルを使って入力のバリデーションと意図推定を同時にやらせる構成になっている。レスポンスは short answer で十分で、正直 200 トークンあれば足りる。
なのに今まで advisor が全力でダラダラ出力してきて、latency が余分に伸びてた。ユーザーの操作に対してリアルタイムで応答させてる部分だったので、これがかなりストレスだった。
アップデートで tools[].max_tokens を advisor のツール定義にセットすれば出力上限を切れるようになった。さっそく手元の定義を直した。
これだけで advisor 側の出力トークンが 200 で打ち切られる。体感だが、レスポンスが明らかに早くなった。自分のユースケースでは full-length のアドバイスを受け取る必要がないケースが多いので、max_tokens を小さく絞ることでコストも削れる。ドキュメントの「Capping advisor output」に詳細が書いてあるので、advisor を使ってる人はとりあえず一度見てほしい。
もう一方の変更、「stop_reason: refusal で何も出力されなかったときは課金しない」というやつ。
これ、今まで何度かハマってたやつだ。本番の入力バリデーションをある程度 Claude 側に任せてる構成だと、ユーザーが変なリクエストを投げてきて refusal になっても普通に課金されていた。
とくに問題だったのは、ストレステスト中に意図的に弾かれるリクエストを大量に投げる場面だ。refusal 率が高いワークロードでは、トークンをほぼ生成していないのに課金される状況がずっと気持ち悪かった。先月のテスト期間中、refusal が全体のリクエストの 15% 程度を占めてた月があって、その分をまるまる無駄に払ってた計算になる。
これが撤廃されたのはシンプルにありがたい。refusal の検出と処理については「Streaming refusals」のページに載っているので合わせてチェックしたい。stop_details フィールドも公式ドキュメント化されていて、category が cyber / bio / null で返ってくる。これを使ってアプリ側で refusal の種別ごとにルーティングできるようになった。今まで refusal をひとまとめに扱ってたログの分類が細かくなりそうで、デバッグが楽になる予感がする。
今回の release notes には Opus 4.8 関連の変更も大量に入っていた。自分が気になったのは以下の点。
prompt caching の閾値が下がったのは個人的にかなり嬉しい。今まで短めのシステムプロンプトだとキャッシュが効かなくて悔しい思いをしていた。1,024 トークンなら手元のプロンプトのほとんどがキャッシュに乗るはずだ。
あと temperature / top_p / top_k をデフォルト以外の値にすると 400 エラーになる仕様は 4.7 から引き継がれている。これ最初にハマったときは何が起きてるか全然わからなくて 30 分溶かした。migration guide を先に読んでおくことを強くすすめる。
自分は今週末、advisor の max_tokens を本番に入れてコスト変化を計測するつもりだ。数字が出たらチームの Slack に貼る。
一つ目は advisor tool に max_tokens パラメータが追加されたこと。二つ目は stop_reason が refusal で何も出力されなかったリクエストについて、課金されなくなったこと。どちらも地味に見えて、コスト面でかなりえぐい影響がある。
advisor tool の max_tokens、ここが刺さる
自分が今触ってるプロジェクトは、advisor モデルを使って入力のバリデーションと意図推定を同時にやらせる構成になっている。レスポンスは short answer で十分で、正直 200 トークンあれば足りる。
なのに今まで advisor が全力でダラダラ出力してきて、latency が余分に伸びてた。ユーザーの操作に対してリアルタイムで応答させてる部分だったので、これがかなりストレスだった。
アップデートで tools[].max_tokens を advisor のツール定義にセットすれば出力上限を切れるようになった。さっそく手元の定義を直した。
# 変更前は max_tokens を指定していなかった
# 変更後の tools 定義イメージ
curl https://api.anthropic.com/v1/messages \
-H 'x-api-key: $ANTHROPIC_API_KEY' \
-H 'anthropic-version: 2023-06-01' \
-d '{
"model": "claude-opus-4-8",
"tools": [
{
"type": "advisor",
"max_tokens": 200
}
]
}'これだけで advisor 側の出力トークンが 200 で打ち切られる。体感だが、レスポンスが明らかに早くなった。自分のユースケースでは full-length のアドバイスを受け取る必要がないケースが多いので、max_tokens を小さく絞ることでコストも削れる。ドキュメントの「Capping advisor output」に詳細が書いてあるので、advisor を使ってる人はとりあえず一度見てほしい。
refusal 課金撤廃は地味に神改善
もう一方の変更、「stop_reason: refusal で何も出力されなかったときは課金しない」というやつ。
これ、今まで何度かハマってたやつだ。本番の入力バリデーションをある程度 Claude 側に任せてる構成だと、ユーザーが変なリクエストを投げてきて refusal になっても普通に課金されていた。
とくに問題だったのは、ストレステスト中に意図的に弾かれるリクエストを大量に投げる場面だ。refusal 率が高いワークロードでは、トークンをほぼ生成していないのに課金される状況がずっと気持ち悪かった。先月のテスト期間中、refusal が全体のリクエストの 15% 程度を占めてた月があって、その分をまるまる無駄に払ってた計算になる。
これが撤廃されたのはシンプルにありがたい。refusal の検出と処理については「Streaming refusals」のページに載っているので合わせてチェックしたい。stop_details フィールドも公式ドキュメント化されていて、category が cyber / bio / null で返ってくる。これを使ってアプリ側で refusal の種別ごとにルーティングできるようになった。今まで refusal をひとまとめに扱ってたログの分類が細かくなりそうで、デバッグが楽になる予感がする。
Opus 4.8 まわりの変更もついでに整理しておく
今回の release notes には Opus 4.8 関連の変更も大量に入っていた。自分が気になったのは以下の点。
- context window がデフォルト 1M トークン (Claude API / Amazon Bedrock / Vertex AI)
- prompt caching の最小キャッシュ可能長が 1,024 トークンに短縮 (4.7 より低い)
- adaptive thinking で必要な turn だけ reasoning が走るようになった
- mid-conversation system messages が Opus 4.8 で使えるようになった
prompt caching の閾値が下がったのは個人的にかなり嬉しい。今まで短めのシステムプロンプトだとキャッシュが効かなくて悔しい思いをしていた。1,024 トークンなら手元のプロンプトのほとんどがキャッシュに乗るはずだ。
あと temperature / top_p / top_k をデフォルト以外の値にすると 400 エラーになる仕様は 4.7 から引き継がれている。これ最初にハマったときは何が起きてるか全然わからなくて 30 分溶かした。migration guide を先に読んでおくことを強くすすめる。
自分は今週末、advisor の max_tokens を本番に入れてコスト変化を計測するつもりだ。数字が出たらチームの Slack に貼る。