月末に使用量の画面を開いて、少し黙ってしまいました。定型的なリネームやログの整形といった、どう考えても軽い作業まで、上位モデルの既定のまま流していたことに気づいたからです。
理由は分かっています。ピッカーを開いてモデルを選び直す数秒が惜しくて、切り替えそのものを省略していました。数秒をけちって、クレジットを余分に払っていたわけです。
8月27日に出た Antigravity CLI v1.1.22 で、/model コマンドに引数が付きました。これを機に、この手癖を作り直すことにしました。
先に結論を書いておきます。/model <name> は一手でモデルを切り替えられますが、同時にそれを既定として保存します。切り替えが楽になった代わりに「戻し忘れ」という新しい注意点が生まれるので、切り替えを「一時的な変更」ではなく「いまからの作業の宣言」と捉え直すのが、私の落とし所でした。
/model に引数が付いて何が変わったか
従来の /model は引数なしで打ってピッカーを開き、そこから選ぶ操作でした。切り替えたモデルを既定にしたければ、さらにもう一手が要りました。
v1.1.22 からは、次のように動きます。
| 入力 | 挙動 |
|---|---|
/model（引数なし） | 従来どおりピッカーが開きます |
/model <name> | 名前・slug・ラベルのいずれかで即座に切り替え、同時に既定として保存します |
| 入力の途中 | 最初に一致した候補の残りがゴーストテキストで表示されます |
| 未知の名前を渡した場合 | エラーで終わらず、有効な候補の一覧が表示されます |
正確なモデル ID を覚えていなくても、数文字打てばゴーストテキストが残りを補ってくれます。切り替えと既定化が2手から1手になった、という種類の改善です。
切り替えは「既定の保存」まで含みます
ここが本題です。/model <name> は切り替えと同時に既定を書き換えるので、「この作業だけ軽いモデルで」と思って切り替えると、次のセッションもそのモデルで始まります。
実害が出やすいのは逆向きです。難しい調査のために上位モデルへ上げ、そのまま戻し忘れる。すると翌日の軽作業も、翌々日の軽作業も、上位モデルで流れ続けます。冒頭に書いた私の失敗は、まさにこの形でした。引数切り替えの導入で、同じ失敗がむしろ起きやすくなる面があります。
対処として「使い終わったら戻す」を徹底しようとしたのですが、これは続きませんでした。戻す操作は作業の終わりに来るため、集中が切れた状態では忘れます。
続いたのは逆の発想でした。作業を始める前に、毎回宣言する。セッションの頭で /model を一度打つ。それだけです。前回何に切り替えたかを思い出す必要がなく、ゴーストテキストのおかげで数文字で確定します。既定がどうなっていようと、いまの作業に合うモデルで始まることが保証されます。
私の二段構えの使い分け
個人開発しているアプリとサイトの保守作業で、モデルの振り分けを最初は細かく設計しようとしました。ただ、判定表を作り込むほど参照しなくなるのが私自身の性分だと分かっていたので、二段だけに畳みました。
手順が固まっている作業は軽いモデルに任せます。ファイルの一括リネーム、設定値の整形、すでに一度解いたことのある種類の修正などです。何をすべきかが決まっていて、出力の形も予想できる作業は、モデルの推論の深さがほとんど結果に影響しません。
設計判断を伴う作業は上位モデルで始めます。原因が絞れていない不具合の調査、複数ファイルにまたがる変更の計画などです。迷ったら上位、迷わないなら軽い方。この程度の粗さでも、切り替えを習慣にできれば消費は目に見えて変わります。
クレジット配分の全体像を整理したい方には、Ultra プランのクレジットを使い切るための配分の考え方が参考になるはずです。
また、切り替えの習慣は「消費が見えていること」で維持されます。私はステータスラインにセッションコストを出すようにしてから、軽作業を上位モデルで流したときの金額が具体的に見えるようになり、宣言の習慣が定着しました。その設定でつまずいた箇所はステータスラインでコストを追えるようにするまでの記録に書いています。
/effort もあわせて宣言すると座りが良い
v1.1.22 では /effort のヒントも改善されました。以前は何を打っても固定の [low|medium|high] が表示されるだけでしたが、実際に入力した文字に応じて補完されるようになっています。
私はモデルと effort を、作業の頭でセットで宣言するようにしています。軽作業なら軽いモデルと低い effort で始め、途中で推論が浅いと感じたら effort だけ上げる。モデルの変更は既定に響きますが、この「まず低く始めて必要なら上げる」の順序なら、上げたことを覚えている確率が高い、というのが実感です。
つまずきやすい3点
最後に、引数切り替えを使い始めてから気づいた注意点を挙げておきます。
1つ目は ID 表記の揺れです。Vertex 経由と Gemini API キー経由でモデルの表記が揺れる環境でも、/model は名前・slug・ラベルのどれでも受け付けます。覚えているどれか一つで打ち始めれば、ゴーストテキストが辿ってくれます。
2つ目は、未知の名前を渡したときの挙動です。失敗のメッセージに見えますが、有効な候補の一覧が併せて表示されるので、そこから拾い直せば済みます。打ち直しの前に一覧を読む方が早いです。
3つ目はバージョン確認です。Gemini API キーで認証している場合、Gemini 3.1 Pro と Gemini 3.5 Flash で reasoning effort の選択が効かない問題があり、これは v1.1.22 で修正されています。effort を変えても挙動が変わらないと感じたら、設定を疑う前に CLI のバージョンを確かめてください。
明日の最初のセッションで、作業を始める前に /model を一度だけ打ってみてください。数文字の宣言が習慣になったころ、使用量の画面を開いたときの気持ちが少し変わっているはずです。私の月末の沈黙が、どなたかの節約になれば幸いです。