OpenTelemetry で Claude Code × Sonnet 5 の時間の使い方を解剖した（オトナの自由研究 #32）
Hiroba による自動要約
OpenTelemetry の traces を使い Claude Code × Sonnet 5 の実行時間を分析したところ、実行時間の 87.2% は API 応答待ちで、ローカル処理は約 3 秒の固定費。effort level を上げても Sonnet 5 はリクエスト回数を増やさず、1 リクエストあたりの長さを最大 2.3 倍に伸ばす戦略を取っていることが判明。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 3778 件あります。
関連する記事
同じタグの記事
データシートPDFのレジスタマップ抽出を Claude Code で自動化
Qiita組み込み開発でデータシートから手作業で転記するレジスタマップ抽出を自動化するツール RegMap Extractor を開発。Claude API と pdfplumber のハイブリッド方式で PDF テーブルを構造化データ化し、CSV/Excel/JSON/Markdown/C ヘッダーで出力。完全自動化ではなく人間レビュー前提の設計により、実機バグリスクを低減。
Claude Code v2.1.239: Bedrock二重課金バグ修正とPython SDK移行コマンド追加
QiitaClaude Code v2.1.239 で、Bedrock プロキシ経由利用時の API 二重課金バグ（Content-Type ヘッダー削除でストリーミング解釈失敗し非ストリーミング再実行）が修正されました。あわせて Python SDK 0.x→1.x 自動移行の /claude-api upgrade コマンドと、データレジデンシー環境での 1.1 倍推論プレミアム反映によるコスト見積もり修正が実装されました。該当環境の利用者は請求額確認と予算設定の見直しが必要です。
Claude Code v2.1.239｜Bedrock で API 課金が 2 倍になっていたバグ修正
QiitaClaude Code v2.1.239 で、プロキシが Content-Type ヘッダを削除する環境下での Bedrock ストリーミング二重課金バグが修正された。ストリーミング失敗時に同じターンを自動で非ストリーミングで再実行していたため、実際の作業量の 2 倍が課金対象になっていた。他に /claude-api upgrade コマンド追加、セッション管理の競合修正、設定ファイル読み込みエラーの改善など既存機能の安定化が実施された。
Claude Opus 5 の effort パラメータは「賢さのツマミ」ではなくなった
ZennOpus 5 で effort を xhigh から medium に下げたら出力品質が上がった。thinking がデフォルト ON になり budget_tokens が廃止され、effort の役割そのものが変わった。effort は品質の下限を決めるのではなく、プロンプト品質を増幅する係数になり、仕様が薄いまま effort を上げると推測が増えて品質が低下する。