Asana、履歴の扱いを変えてbrowser agentのコストを76分の1に

Asanaは4つのモデルでbrowser agentを試し、最大のコスト要因が推論そのものではないと突き止めた。agentが過去の履歴を書き換えるたびに、自らcacheの再利用を壊していた。

安定した履歴で1回のコストは0.47ドルまで下がった

従来のagentは処理の途中でスクリーンショットを削除し、古いテキストを切り詰めていた。その変更によってpromptの共通prefixが崩れ、入力の大部分が再び通常料金で計算された。

Asanaは増え続ける履歴もcache対象にし、上限を120,000文字から480,000文字へ広げ、スクリーンショットをまとめて削除した。最良の構成ではGPT-6.1 Solが入力の89％をcacheから読み、1回平均0.47ドルになった。匿名化されたModel Bの旧本番構成と比べ、コストは76分の1、時間は5分の1だった。

モデル交換より計測と履歴設計が効いた

調査では6種類の履歴方針と2つの上限を組み合わせ、各条件を3回実行した。合計144回に加えて12回の追試を行い、各agentが192個の事実を回収できるか確認した。

開発チームへの示唆は明確だ。agentのコストはアプリケーション層でも決まる。安定したprefix、モデルに合う履歴上限、cache readsの計測は、追加のfine-tuningや小型モデルへの変更なしでも運用費を変えられる。

76倍という数字には最適化とモデル変更が含まれる

76倍の比較は、Model Bの旧本番構成と最適化後のGPT-6.1 Solを比べたものだ。Solだけで条件をそろえると、新しいcache policyによる削減は1.97ドルから0.47ドルへの4分の1だった。著者も、各条件3回から4回の実行で分かるのは大きな傾向であり、小さな差ではないと注意している。

履歴を広げても上限は消えない。agentが迷走したりcacheが外れたりすれば、請求額は再び増える。steps、tokens、1回当たりの費用には制限が必要だ。

長く変化の多いタスクで再現できるかが次の焦点になる

Asanaによると、変更はStackAIのbrowser navigationへ導入済みだ。今後は480,000文字を超えるタスク、内容が変わるページ、4分を大きく超える処理で同じ効果が出るかが重要になる。

チームは完了タスク当たりの費用、cache readsの割合、steps、結果の品質を一緒に追うべきだ。その4点で、書籍カタログ以外でも最適化が通用するか判断できる。

Lilithの判定

Asanaが見つけた36ドルの請求書の原因は、agentが自分のノートを書き直し続けていたことだった。最も高価なモデル問題は、アプリ側でDeleteを押していることがある。