DeepSeek V4.x Flash を複数 provider（OpenCode Go / NVIDIA Build / DeepInfra）経由で動かすときの失敗型・切り分け・運用の正本。DSML tool-call drift の検出と salvage、quota 層の確認、provider 選定に使う。「DeepSeek が応答しない」「tool call が空」「429 が続く」といった症状で使う。ユーザーが /deepseek-ops と入力したら使う。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
OpenCode Go / NVIDIA Build / DeepInfra に跨る DeepSeek V4.x 系の実測知識。調査期間は 2026-09-27〜29。
| provider | modelId | 観測された事象 | 用途の結論 |
|---|---|---|---|
OpenCode Go（zen/go） | deepseek-v4.1-flash | DSML drift は低率（完走実績あり）。唯一の壁は subscription quota | 本番本命。quota 節で枠管理 |
| NVIDIA Build | deepseek-ai/deepseek-v4.1-flash | DSML drift 高率 + effort=max で 30-45min/stage、45min timeout SIGTERM あり | 検証専用。本番・billing・publish に使わない |
| DeepInfra | deepseek-ai/DeepSeek-V4-Flash | V4 ≠ V4.1（版違い）。endpoint 生存のみ確認、pipeline 負荷は未実測 | ユーザー明示指示があるときだけ使う。勝手に回さない |
注意: 同名 v4.1-flash でも provider が違えば serving stack（chat template / tool-call parser / sampling / 量子化有無）が違う。provider を跨いだ観測を同一モデルの実績として混同しない。
signature（gateway event / diagnostics で判別）:
finishReason:"error"、assistant text が空 or "\n\n<｜DSML｜ calls>\n" のような markup 残滓toolCallContentObserved:true なのに正規 tool call 0件RESULT_NOT_SUBMITTED / ASSISTANT_EMPTY / OUTPUT_SCHEMA_INVALID（空 write_output submit）に化ける機構: モデルは tool-call 意図を DSML 特殊トークン列として生成するが、serving 層の parser が tool_calls[] へ翻訳し損ねて生 markup が content に漏れる。モデル refusal ではなく adapter 層の翻訳失敗。量子化劣化ではなく構造破壊（二値的）。
確率的: 同一 wire・同一入力でも通ることがある（attempt 3 で成功の実例）。単発成否を wire 品質の証拠にしない。
drift 率を上げる変数（実測）:
article-v2-markdown.v1 / editorial-json 等が system/tool 応答/task に見える）→ 非表示化で有意に改善効かないもの: wire の極小化だけでは消えない（99B task でも 0/3）。除去不能な endpoint 確率事象として扱う。
対処:
<|DSML|invoke name="write_output">…</|DSML|invoke> を parse して同じ tool handler に replay すれば成果物を救出できる（共通の salvage 処理）。切れた invoke は絶対に replay しない月額ドル枠を3層で制限: 5時間=20% / 週=50% / 月=100%。binding 層が1つでも100%なら全 request 429。
429 {"type":"GoUsageLimitError","message":"Go usage limit exceeded"}（body に reset 情報なし）実測プロファイル（pi-sdk-nvidia・effort=max・plan-synthesis 級の大セッション、2026-09-30）:
providerError: "Stream ended without finish_reason" で早期終了し得る（~30分）生存性の正しい測り方（重要）:
/proc/<pid>/io の read_bytes はブロック層（ディスク）のみ — socket 受信は数えない。stream を見るなら rchar（全 read() syscall バイト）の deltawchan=do_epoll_wait は node のイベントループ待ちで、生存/死亡を区別しないworker の停滞検出は worker-core.ts の stream-idle watchdog が担う（PI_SDK_STREAM_IDLE_TIMEOUT_MS 既定10分、rchar delta ≤ 2KB/poll で停滞判定、STREAM_STALLED retryable で早期 fail + salvage 試行）。閾値は健全 pause ~5分 < 10分 < 真の死（無限）の谷間に設定 — 5分 pause は NVIDIA の正常挙動なので誤検しないよう短くしすぎない。
cap 超過の解除は effort で行う（2026-09-30 実測）: 同一要求・同一 model で plan-synthesis は effort=max が18連敗（SIGTERM×16+途中死×2）だったのに対し effort=high は 13.8分で完走。統合系の大 stage では reasoning 量が支配変数 — timeout 延長ではなく PI_SDK_NVIDIA_THINKING_LEVEL で pin 全体（pin・session・resolved）を一貫して下げて計測する。再現手順: scripts/editorial/nv-probe-plan-synthesis.ts --level high。
キーなし probe: プロバイダーの chat completion endpoint が 401/0.4s を返せば endpoint 健全、401 でなければ接続層の障害。429 しか返さない場合は quota。finishReason:"error" に加えて、redact 済みの provider error に HTTP 詳細を記録すると原因を切り分けられる。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
ある AI エージェントから別の AI CLI（devin / codex / claude / cursor-agent / opencode / gemini / grok）を非対話で呼び出すときの実行規則。print モードの 選び方、認証・権限・cwd の罠、出力フォーマット、ACP 起動の注意をまとめる。 「codex に投げて」「devin を CLI から呼んで」「別エージェントに委譲」 といった依頼で使う。ユーザーが /agent-cli と入力したら使う。
明示されたCodex・CursorのSkill運用移行を、指定設計と既存点検に基づき適用する。通常の実装依頼では起動しない。
明示されたリポジトリのSkill・Agent・呼出し・生成配布を点検または移行する。通常の実装・レビュー・調査では起動しない。
プロジェクトのデザインシステムを SSOT として作成・監査・更新する。トークン、デザインシステムに関わるアクセシビリティ、Typography、Motion、aesthetic direction の作業に使う。デザインシステムに紐づかない単発UI実装や個別デザインレビューには使わない。ユーザーが /ai-design-system と入力したら使う。
デザインシステムの作成・監査・保守、デザイントークンやUIの一貫性・個性・アクセシビリティの改善に使う。
AIに日記を書かせるスキル。会話を振り返り、AI視点の自由な日記風テキストを生成して保存する。「日記書いて」「AI日記」「日記風に振り返って」「感想を日記にして」「diary」「write a diary」といった日記・感想の依頼に使う。作業改善の振り返りは /retro、知見の記録や要約は /ai-ltm を使う。ユーザーが /ai-diary と入力したら必ずこのスキルを使う。