あなたは安価なモデルを選び、モデルカードで計算した。しかし、届いた請求書はあなたの計算とはまったく異なっていた。
その差は、ほとんどの場合、モデルではなく「ハーネス」に起因する。ハーネスは、モデルが呼び出される回数、呼び出しごとに会話のどの部分が再生されるか、ツールスキーマの大きさ、そして失敗したテスト実行が3回リトライされるか12回リトライされるかを決定する。同じモデル、同じタスク、異なるハーネスで、トークン数は劇的に異なる。
2026年8月13日、DeepSeekは自社のエージェントハーネスをオープンソース化し、議論はすぐに激化した。一方は、モデルを構築するラボから2週間前にリリースされたリポジトリ。もう一方は、GitHubで最もスターが多いコーディングエージェントであるOpenCode。どちらもMITライセンス。どちらも、あなたが指定した任意のモデルで動作する。
そこで、今回は正直な比較を行う。雰囲気でもスター数でもない。各ハーネスが実際にあなたのトークン使用量に何をもたらすか、そしてそれをあなた自身のリポジトリで約15分で測定する方法を紹介する。
重要なポイント
- DeepSeek Harness は、DeepSeek AI によるプラグイン優先のエージェントランタイム。MITライセンス、TypeScriptで記述、現在も開発者プレビュー。モデル、ツール、セッション、ストレージ、サンドボックス、ループ、さらにはエージェントループ自体も、すべて交換可能なプラグイン。
- OpenCode は、Go言語で書かれたターミナルネイティブのコーディングエージェント。約198kのGitHubスター、成熟したTUI、LSPサポート、大規模なプロバイダーカタログを備える。今日の安全なデフォルト選択肢。
- ハーネスの選択は、ほとんどの人が予想する以上にトークン使用量を変動させる。 DeepSeek V4 Flash での30のワークフローベンチマークでは、テストされたハーネスはタスクあたり平均約192,000から1,400,000トークンの範囲に及んだ。
- DeepSeek Harness はそのベンチマークに含まれていない。 ベンチマーク公開の2日後にリリースされたため、現時点でHarnessのベンチマーク数値を引用している人は、推測しているに過ぎない。
- どちらもモデルに依存しないため、 両方を1つのOpenAI互換エンドポイントに向けて、真の同一条件比較を実行できる。それがあなたのコードベースにとって唯一重要な数値である。

日光の当たる机の上に並べられた2台のノートパソコン。2つの異なるエージェントハーネスを通じて同じコーディングタスクを実行している
DeepSeek Harness と OpenCode を公平に比較する唯一の方法:1つのモデル、1つのタスク、2つのターミナル。
なぜDeepSeek Harness vs OpenCodeが今月の議論になったのか
DeepSeekのフレーミングはスローガンだ:エージェント = モデル + ハーネス。モデルは思考し、ハーネスはファイルを読み、ターミナルを実行し、ツールを呼び出す。2年間、誰もが前半を最適化し、後半を配管として扱ってきた。
その配管は高くついた。
Composioは、8つの異なるエージェントハーネスを通じて30の複雑なマルチアプリワークフローを実行。すべて同じDeepSeek V4 Flashモデルを駆動し、タスクあたり900秒の上限、240回の実行でバイナリプログラム評価を行った(Composio、2026年8月)。モデルはどこも同じ。結果は拮抗していなかった。
| ハーネス | 合格率 | 中央時間 | タスクあたりの平均トークン数 |
|---|---|---|---|
| Pi Agent | 66.7% | 132.2s | 559,000 |
| Prime Agent | 62.5% | 242.1s | 1,400,000 |
| OMP | 56.7% | 272.4s | 742,000 |
| Claude Code | 53.3% | 122.7s | 742,000 |
| Codex | 53.3% | 245.0s | 678,000 |
| DeepAgents | 53.3% | 187.1s | 665,000 |
| Hermes Agent | 50.0% | 175.5s | 192,000 |
| OpenCode | 46.7% | 129.7s | 692,000 |
トークンの列をもう一度見てほしい。最も節約的なハーネスは、最も無駄の多いハーネスの約7分の1のトークンしか使用していない。同じモデル、同じタスクで。ベンチマーク自身の結論は、ハーネスは「それが実行するモデルと同じくらい重要になり得る」というものだった。
ここで、ほとんどの記事が省略する部分。DeepSeek Harness はその表に含まれていない。 ベンチマークは8月11日に公開され、Harnessは8月13日にリリースされた。現時点でDeepSeek Harnessの信頼できる直接比較トークン数は存在せず、今月誰かが数値を示したとしても、自分自身で狭いタスクで実行したか、捏造したかのどちらかだ。表が提供するのは、OpenCodeの確かなソース付きベースラインだ:タスクあたり692,000トークン、合格率46.7%、中央時間129.7秒。
それがあなたが打ち負かそうとしている数値であり、この記事の残りの部分は、それを正直にテストする方法である。
DeepSeek Harness vs OpenCode:同じモデル、1つのエンドポイント、2つのランタイム
何かを実行する前に、各ツールの実用的な概要を示す。
| DeepSeek Harness (dsh) | OpenCode | |
|---|---|---|
| 提供元 | DeepSeek AI | Anomaly(元SST) |
| リリース日 | 2026年8月13日 | 2025年後半 |
| GitHubスター数 | ~143k | ~198k |
| ライセンス | MIT | MIT |
| 言語 | TypeScript | Go |
| インターフェース | 127.0.0.1:3080 上のWeb UI | ターミナルTUI |
| ステータス | 開発者プレビュー、互換性を破る変更が予想される | 成熟、広く展開済み |
| アーキテクチャ | すべてがプラグイン:モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI | 固定コア、2つの内蔵エージェント(build, plan)、MCPおよびLSP拡張 |
| 設定 | $DSH_HOME/settings.yaml | opencode.json |
| トークン会計 | 内蔵トークンメーター:コンテキスト圧力と内訳予測、および折り畳みによる圧縮付き | セッションごとのトークンとコスト追跡、TUI内での内訳は最小限 |
| 最適な用途 | エージェントループ自体を書き換えたいチーム | 今日すぐに使えるコーディングエージェントを求めるチーム |
重要な行はアーキテクチャの行だ。OpenCodeはよく構築されたエージェントを提供し、エッジを拡張できる。DeepSeek Harnessは骨組みを提供し、背骨(エージェントループ自体を含む)を交換できる。エージェントループもプラグインである。これは本当に珍しく、それがまだプレビュー版である理由でもある。
どちらもモデルに依存しない。これこそが公平なテストを可能にする唯一の理由だ。両方を1つのモデルを提供する1つのOpenAI互換エンドポイントに向ければ、測定されるすべての差異はハーネスに起因するものとなる。
このチュートリアルでは、Atlas CloudからDeepSeek V4 Flashを提供する。これは、アダプターコードなしで両方のハーネスが受け入れ可能なプレーンなOpenAI互換エンドポイントを公開しており、同じキーが両方の実行で使用できるためだ。deepseek-v4-flash-0731のリスト価格は、入力100万トークンあたり0.14ドル、出力100万トークンあたり0.28ドル、コンテキストウィンドウ1,048,576トークン、最大出力393,216トークン(2026年8月時点)。このテストには、任意のOpenAI互換プロバイダーで問題ない。重要なのは、両方のハーネスが同じプロバイダーにヒットしなければならないことだ。
モデルを選ぶ前に知っておくべきこと:OpenCodeは自身の集計使用データを公開しており、DeepSeekモデルはそれを通じて233兆トークンを移動しており、V4 Flashがその85.5%、V4 Proが残りの14.5%を占めている(OpenCode、2026年8月)。Flashがエコシステムが実際に実行しているものだ。
ステップ1:DeepSeek Harness と OpenCode を同じモデルに向ける
1つのAPIキーと1つのベースURLを取得し、両方のツールにまったく同じペアを指定する。Atlas Cloudコンソールでキーを作成し、一度エクスポートする:
bash1export ATLAS_API_KEY="your-api-key" 2
いずれかのハーネスを接続する前に、エンドポイントと正確なモデルIDを1回の呼び出しで確認する。これがテキストを返さなければ、後続の処理は一切機能しない:
bash1curl https://api.atlascloud.ai/v1/chat/completions \ 2 -H "Authorization: Bearer $ATLAS_API_KEY" \ 3 -H "Content-Type: application/json" \ 4 -d '{ 5 "model": "deepseek-ai/deepseek-v4-flash-0731", 6 "messages": [{"role": "user", "content": "Reply with the single word: ready"}] 7 }' 8
モデルがエージェントに渡される前に、エンドポイントを通じて実際のタスクに一度回答するのを見ることは有用だ。そうすれば、失敗した実行がハーネスによるものであり、ルートによるものではないと分かる:

記事のタスクプロンプトをapi.atlascloud.aiに投稿し、隣にDeepSeek V4 Flash 0731が返した実際の回答と呼び出しが報告したトークン使用量を示している
deepseek-ai/deepseek-v4-flash-0731 への実際の呼び出し1回。両方のハーネスが使用するのと同じモデルID:入力148トークン、出力6,879トークン(うち5,731トークンは推論)。これが、ハーネスが単一のツールスキーマを追加する前のフロアである。
次に各サイドを設定する。DeepSeek Harnessは $DSH_HOME/settings.yaml を読み取り、カスタムのOpenAI互換プロバイダーは llm-pi-ai プラグインの下に設定する(DeepSeek Harness ドキュメント、2026年8月):
yaml1llm-pi-ai: 2 providers: 3 atlas: 4 apiKeyEnv: ATLAS_API_KEY 5 api: openai-completions 6 baseURL: https://api.atlascloud.ai/v1 7 models: 8 - id: deepseek-ai/deepseek-v4-flash-0731 9
api フィールドは openai-completions、openai-responses、または anthropic-messages を受け入れる。ここでは openai-completions を使用する。YAMLを手動で編集したくない場合は、Web UIのSettings -> Models -> Add a custom providerから、同じブロックを書き込み、キーを $DSH_HOME/.credentials.yaml に保存する。
OpenCodeはプロジェクトルートまたはグローバル設定ディレクトリの opencode.json を読み取る(OpenCode ドキュメント、2026年8月):
json1{ 2 "$schema": "https://opencode.ai/config.json", 3 "provider": { 4 "atlas": { 5 "npm": "@ai-sdk/openai-compatible", 6 "name": "Atlas Cloud", 7 "options": { 8 "baseURL": "https://api.atlascloud.ai/v1", 9 "apiKey": "{env:ATLAS_API_KEY}" 10 }, 11 "models": { 12 "deepseek-ai/deepseek-v4-flash-0731": { 13 "name": "DeepSeek V4 Flash 0731", 14 "limit": { "context": 1048576, "output": 393216 } 15 } 16 } 17 } 18 }, 19 "model": "atlas/deepseek-ai/deepseek-v4-flash-0731" 20} 21
@ai-sdk/openai ではなく @ai-sdk/openai-compatible を使用する。このエンドポイントは /v1/chat/completions を提供するためである。limit 値を実際のコンテキストと出力数に設定する。OpenCodeはこれらを使用して要約のタイミングを決定するため、誤った制限はトークン比較を大きく歪める。
ステップ2:DeepSeek Harness でベンチマークタスクを実行する
複数のツール呼び出しを必要とするほど大きく、客観的に評価できるほど小さいタスクを1つ選ぶ。マルチファイル、かつ実際にパスしなければならないテストスイートを含む。両方の実行で同じリポジトリ状態を使用するため、事前にコミットまたはスタッシュする。
これが正確なタスクプロンプトである。両方のハーネスにそのまま貼り付ける:
text1このリポジトリ内で、src/server.js の Express アプリにトークンバケットレート制限ミドルウェアを追加してください。 2各IPを1分間に60リクエストに制限します。拒否時には、HTTP 429 と JSON ボディ {"error":"rate_limited","retryAfter":<seconds>} を返します。 3ミドルウェアをすべての /api/* ルートに接続します。test/rate-limit.test.js にユニットテストを追加し、以下の3つのケースをカバーします:制限未満のリクエストは許可される、制限を超えたリクエストは429でブロックされる、ウィンドウ期限切れ後にカウンターがリセットされる。 4テストスイートを実行し、パスするまで失敗を修正してください。src/ および test/ 以外のファイルは変更しないでください。 5
プロジェクトディレクトリからHarnessを起動する:
bash1cd /path/to/your/repo 2npx @deepseek-ai/dsh web 3
これにより http://127.0.0.1:3080 でWeb UIが提供される。atlas プロバイダーと deepseek-ai/deepseek-v4-flash-0731 モデルを選択し、タスクを貼り付けて、完了するまで実行する。介入せず、明確化の質問にヒントで答えない。一方のハーネスに与えた助けが他方に与えられなければ、比較は無効になる。
完了したら、Trajectory ビューを開く。それがセッションレコードであり、トークン数が存在する場所である。
ステップ3:OpenCode で実行を繰り返し、公平な DeepSeek Harness vs OpenCode テストを行う
リポジトリをまったく同じ開始状態にリセットする。このステップは、ほとんどの非公式な比較が静かに失敗する場所である。2番目のハーネスは、最初のハーネスがすでに半分修正したリポジトリで開始するためだ。
bash1git checkout -- . && git clean -fd 2
次に、同じモデルに対してOpenCodeを実行する:
bash1opencode --model atlas/deepseek-ai/deepseek-v4-flash-0731 2
ステップ2と同じタスクプロンプトを貼り付ける。デフォルトの build エージェントを使用する。これが完全なファイルおよびシェルアクセス権を持つものだからだ。繰り返すが、ヒントは与えず、軌道修正もせず、同じハンズオフ処理を行う。
完了させ、両方の実行をPRをレビューするのと同じ方法で検証する:
bash1npm test 2
スイートが赤のままの実行は、要約がどれほど自信に満ちていても、合格ではない。Composioの方法論と同様に、バイナリで評価する。半分だけ動作するレートリミッターは不合格である。
ステップ4:DeepSeek Harness vs OpenCode のトークン使用量を読み取る
次に数値を収集する。両方のハーネスが使用量を追跡するが、それらを非常に異なる方法で表面化する。これが両者の間の日常的な最大の違いである。
DeepSeek Harness はデフォルトでマウントされたトークンメーターを出荷する。これは3つのセッション予測を直接読み取れるように公開する:tokenUsage(実行中の合計)、contextPressure(ウィンドウにどれだけ近いか)、contextBreakdown(トークンが実際にどこに行ったか)。最後のものが最も有用であり、請求書がシステムプロンプト、ツールスキーマ、ファイル読み取り、会話再生のいずれによるものかを教えてくれる。メーターは、実際のトークナイザーではなく、約4文字あたり1トークンの固定ヒューリスティックを使用するため、強い推定値として扱い、請求書としては扱わない。
Harnessはまた、完全なコンテキストを異なる方法で処理する。切り捨てる代わりに、その圧縮エンジンが折り畳む:モデル可視の表面を要約で置き換え、完全なログは永続化レイヤーに残る。プロンプトからトークンが失われ、レコードから履歴が失われるわけではない。
OpenCode はセッションごとのトークンとコストを追跡し、作業中にステータス行に表示する。TUI内の内訳は意図的に最小限であり、そのためOpenCodeのセッションデータベースを直接読み取り、ツール別およびキャッシュヒット率別に使用量を分解する外部アナライザーの小さなエコシステムが存在する。ツールごとの帰属が必要な場合は、何かをインストールすることになる。
比較自体については、どちらのツールのカウンターも最終的な判断として信頼してはならない。プロバイダー側の数字を使用する。それがあなたが実際に支払っているものだからだ:
| 比較するもの | 取得場所 |
|---|---|
| 総入力トークン | プロバイダーの使用量ダッシュボード、APIキー別 |
| 総出力トークン | プロバイダーの使用量ダッシュボード、APIキー別 |
| モデル呼び出し回数 | Harness Trajectoryビュー / OpenCode セッションログ |
| ウォールクロック時間 | ストップウォッチ、開始から最後のファイル書き込みまで |
| 合格または不合格 | npm test の終了コード |
最もクリーンな方法は、harness-test と opencode-test という名前の2つの別々のAPIキーを作成し、それぞれを正確に1回の実行に使用することだ。そうすれば、プロバイダー自身の使用量ページが、ゼロの推定誤差で議論の余地のない並列比較を提供する。このトリックは2分で完了し、どちらのカウンターが正しいかについてのすべての不一致の原因を取り除く。
DeepSeek ハーネスのトークン使用量:実際に請求書を動かすもの
実際の数値を入手したら、これらが触れる価値のあるレバーである。これらは両方のハーネスに適用され、どちらを選んだかよりもはるかに重要である。
会話の再生は、通常、最大の項目である。 エージェントは各ステップで成長する会話を再送信する。40ステップのタスクは40のプロンプトではなく、40のますます長くなるプロンプトの合計に近いコストがかかる。これが、同一の作業でベンチマークの範囲が192,000から1,400,000トークンに及んだ理由である。積極的に要約するハーネスは、その範囲の下限に位置する。
キャッシュヒットは、利用可能な最も安価な最適化である。 DeepSeek V4 Flashのキャッシュヒット価格は、100万トークンあたり約0.0028ドルで、ミスの0.14ドルに対して約98%安い。キャッシュは、リクエストプレフィックスがバイト単位で同一である場合にのみ機能する。これがまさに、DeepSeek Harnessが厳格な {{variable}} 補間(フェイルラウンドセマンティクス付き)を強制し、安定したリクエストヘッダーを維持する理由である。呼び出し間でシステムプロンプトをシャッフルするハーネスは、すべてのヒットを静かにミスに変える。
ツールスキーマは、すべての呼び出しに同梱される。 20のMCPサーバーが接続されているということは、タスクがそれらに触れるかどうかに関係なく、20セットのスキーマがプロンプトに常に存在することを意味する。ベンチマークの前に、このタスクに不要なものを切断せよ。そうしなければ、ハーネスではなくMCP設定を測定していることになる。
過大なツール結果はコンテキストを汚染する。 3,000行のファイルの cat や、冗長なテストランナーによる完全なスタックトレースのダンプは、残りの実行中、会話内に残り続ける。Harnessには、オプションの結果トリミングコンパニオンがあり、要約前に過大なツール結果を書き換える。これを有効にする価値がある。
リトライは、呼び出しを数えるまで見えない。 失敗したテストを3回リトライするハーネスは、3倍のコストがかかる。総トークン数だけでなく、呼び出し回数列も比較せよ。そうしなければ、リトライループを高価なモデルと誤診することになる。
コストに関しては、トークン数がわかれば算術は単純である。DeepSeek V4 FlashのAtlas Cloudレートでは、692,000トークンのタスク(入力に重み付け)は、低単位のセント台に収まる。これがこのカテゴリ全体に関する良いニュースである:モデルは十分に安価であり、ハーネスの無駄は予算上の緊急事態ではなく効率の問題である。チームが一日中、毎日実行する場合にのみ、それは本当の数字になる。2番目のモデルに対して同じテストを実行し、モデル効果とハーネス効果を分離したい場合は、完全なモデルカタログを参照されたい。
どのトークン数よりもあなたの決定を形作るべき1つの注意点:DeepSeek Harnessは明示的に開発者プレビューであり、そのREADME自体が大文字で互換性を破る変更があることを警告している。これはベンチマークするには良いが、今月チームで標準化するにはリスクが伴う。OpenCodeは退屈な選択であり、それが本番リポジトリに対して実行されている場合、退屈は機能である。
よくある質問
DeepSeek Harness は OpenCode より優れているか?
まだ、ほとんどの人にとってはそうではない。OpenCodeは成熟しており、ターミナルネイティブで、約198kのスターと大規模なプロバイダーカタログを持ち、今日から使える。DeepSeek Harnessは2週間前にリリースされ、開発者プレビューであり、互換性を破る変更について警告している。Harnessはアーキテクチャ的により興味深い。エージェントループを含むすべてのコンポーネントが交換可能なプラグインだからだ。エージェント内部を書き換えたいなら、Harnessはそのために構築されている。今週中にコードを出荷したいなら、OpenCode。
DeepSeek Harness は DeepSeek モデルでのみ動作するか?
いいえ。モデルに依存しない。DeepSeek、Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex向けのカタログプロバイダーが出荷されており、openai-completions、openai-responses、または anthropic-messages を話すカスタムプロバイダーを、$DSH_HOME/settings.yaml にブロックを追加することで追加できる。ステップ1の設定は、アダプターコードなしでサードパーティのOpenAI互換エンドポイントを指している。
DeepSeek ハーネスのトークン使用量を確認するには?
デフォルトでマウントされている内蔵トークンメーターを使用する。これは tokenUsage、contextPressure、contextBreakdown の予測を公開し、Trajectory ビューで表示できる。これは、実際のトークナイザーを実行するのではなく、約4文字あたり1トークンの固定ヒューリスティックで推定することに注意。請求の正確性を期すには、代わりにプロバイダーの使用量ダッシュボードを読み取る。理想的には、実行ごとに専用のAPIキーを使用する。コミュニティプラグイン(トークン使用量ダッシュボードなど)は、その上に永続的なセッションごとのレコードを追加する。
どちらのハーネスがより少ないトークンを使用するか、DeepSeek Harness か OpenCode?
まだ公開された直接比較はない。DeepSeek V4 Flashでの8つのハーネスのベンチマークは、OpenCodeを平均タスクあたり692,000トークンと測定したが、これはDeepSeek Harnessのリリースの2日前に実行されたため、Harnessは含まれていない。そのベンチマークからHarnessの数値を引用している人は、存在しないものを引用していることになる。ステップ2からステップ4のテストを自分のリポジトリで実行せよ。トークン使用量は、コードベースのサイズ、MCP設定、タスクの形状に大きく依存するためだ。
DeepSeek Harness と OpenCode を同じAPIキーで実行できるか?
はい、カジュアルなテストでは問題ない。クリーンな測定のためには、ハーネスごとに別々のキーを使用せよ。そうすれば、プロバイダーの使用量ダッシュボードが自動的にすべてのトークンを正しい実行に帰属させ、2つの異なる内部推定器を1つの請求書と照合する必要がなくなる。
エージェントとハーネスの違いは何か?
DeepSeek自身のフレーミングは、エージェント = モデル + ハーネス である。モデルは推論を行う。ハーネスは、それを現実に接続するすべてのもの:ファイルの読み書き、シェルコマンドの実行、ツールの呼び出し、セッションの管理、承認の処理、次に何が起こるかを決定するループの駆動。同じモデルと異なるハーネスは、測定可能な異なるエージェントを生み出す。これがこの比較の全体のポイントである。






