Seedance 2.5 が提供開始 — Atlas Cloud で先行リリース

DeepSeek Harness 対 Hermes:どちらがより多くのトークンを消費するか?

DeepSeek Harness vs Hermes:トークンを多く消費するのはどちら?

あなたは昨日Hermesでタスクを実行しました。今日はdshで同じように感じたタスクを実行しました。同じモデル、同じAPIキー、同じラップトップ。それでも使用量の数字は異なっていました。

あなたの目は正常です。何かが一晩で値上げされたわけではありません。

ほとんどすべてのDeepSeek Harness vs Hermesの比較が見逃しているものがあります。それは、ハーネスはモデルを包むシェルであり、そのシェルが1ステップあたりに送信するコンテキストの量、アドバタイズするツールの数、リトライの頻度、そして呼び出しのたびに会話全体を再送信するかどうかを決定するということです。シェルを変えれば、請求額が変わります。

そこで、モデル変数を固定して測定しました。2つのハーネス、1つのエンドポイント、1つのdeepseek-ai/deepseek-v4-pro、1つのプロンプト、1つのマシン、1つの午後。同じタスク、両方とも完了しましたが、一方はもう一方より8.4倍多くのプロンプトトークンを移動しました。

主なポイント

  • 同じモデル、同じタスク、両方とも合格:dshは121秒、Hermesは780秒
  • Hermesは1,111,573のプロンプトトークンを移動したのに対し、dshは132,600。これは1つのタスクで8.4倍。
  • どちらのエージェントも何かをする前に、システムプロンプトだけでトークンがかかる:dshは「OK」と答えるだけで10,898トークン、Hermesは13,892トークン。
  • dshはdefaultContextWindowを上書きしない限り、コンテキストを262,144に静かに制限し、V4のウィンドウの75%を捨てる。
  • コーディングにはdshを、メモリ、cron、チャットサーフェスにはHermesを選ぶ。または両方を実行する。

分割されたエンジニアリングワークショップ。左側にベアエンジンブロックが鋼製のテストハーネスリグに固定され、右側に真鍮のファイリングオートマトンがあり、両方に1本の銅製燃料ラインが供給されている

1本の燃料ライン、2つのテストリグ。それが実験のすべて。openai/gpt-image-2で生成。

DeepSeek Harness vs Hermes、同じモデル、同じタスク

両方のハーネスにこれを、一言一句そのまま与えました:パドル、5列のブロック、ライブスコアカウンター、Pキーで一時停止、さらに3つの物理不変条件をアサートしてPASSまたはFAILを表示するインラインのセルフテストを備えた、単一ファイルのBreakoutクローンを作成してください。それをヘッドレスで実行し、3つすべてがPASSと表示されるまで修正してください。

ライブラリなし。CDNなし。ビルドステップなし。

両方とも実際にやり遂げました。実際のブラウザでレンダリングされた2つのファイルがこちらです。

2つのBreakoutビルドが再生されているアニメーションのサイドバイサイド:左がDeepSeek Harness (dsh)、右がHermes Agent。両方とも同一のDeepSeek V4 Proプロンプトから自動再生

2つのビルドをサイドバイサイドで再録し、自動再生に任せて、それぞれが実際に動作する様子を確認できます。左:dsh、ゲームは自動開始。右:Hermes、ゲームは一時停止状態で起動し、その後実行。同じ単一ファイルプロンプト、同じDeepSeek V4 Pro、2つのハーネス。

では、これを実際に決定する数値を見てみましょう。

実行ウォールクロックツール呼び出しプロンプトトークン(新規+キャッシュ)出力トークンV4 Proでのコスト
dsh、ラウンド1121.2s814,840 + 117,760 = 132,6005,231$0.24
Hermes、ラウンド1780s3549,685 + 1,061,888 = 1,111,57319,317$1.93
dsh、ラウンド2未完了11(打ち切り前)44,291 + 132,6082,463未完了
Hermes、ラウンド2未完了未実行未完了未完了未完了

2026-08-21にdeepseek-ai/deepseek-v4-pro、1台のマシン、実行ごとに空の作業ディレクトリで測定。トークン数は機械読み取り:dshはセッションログから、Hermesは--usage-fileのJSONから。2つのツール数は同じ方法で取得されていないことに注意:dshの8はログからカウント(6と主張)、Hermesの35は自身のレポート(使用ファイルには38回のAPI呼び出しと記録)。コストの計算方法は最後のセクションで説明。

なぜ2つの空行があるのか?ラウンド2は実行されませんでした。その理由がこの記事の最高のデータポイントです。Hermesのラウンド1だけで113万トークンがアカウントを通り、dshのラウンド2の途中でエンドポイントが次のように応答しました:

plaintext
1dsh: QUOTA: 429: {"code":"member_spend_limit_exceeded",
2"message":"Member day spend limit reached (set by your team admin);
3resets at 2026-08-22T00:00:00Z.","type":"insufficient_quota"}

1つのエージェント、1つのBreakoutゲーム、1日の予算上限。私はそれらのセルを推測で埋めるつもりはありません。

もう1つ注目すべき詳細。dshは最終回答で「使用したツール呼び出し:6」と報告しました。自身のセッションログには8と記録されています。エージェントは自身の消費について信頼できない語り手であり、まさにこのテストが要約ではなくログを読む理由です。

ほとんどのDeepSeek Harness vs Hermesの比較が壊れている理由

最初に結論:このキーワードでランク付けされているほぼすべてのページは間違った変数を測定しており、その設定の1行で見分けられます。

モデルであって、シェルではない。それらのテストが測定したもの

上位の結果を読んでみてください。パターンは繰り返されます:dshをDeepSeekモデルで実行し、HermesをHermesがすでに指していたもので実行し、その差全体をハーネスのせいにする。

それはハーネスの比較ではありません。ハーネスの形をしたラベルを着たモデル比較です。

dshがV4 Proで、Hermesが別のものを使っている場合、測定するデルタはほとんどが2つのモデルの差であり、シェルの寄与は回復不能なほど埋もれています。そこでこのテストは、退屈だが必要なことを行います:両方のハーネスが同じベースURL、同じモデルID、同じキーを指すようにします。

ハーネスの選択自体が数値を動かす

シェル単体で高コストであることの証拠が欲しいですか?それぞれに何もしないように頼んでみてください。

両方に同じ些細なプロンプトを送信しました:Reply with exactly the word: OK。ツール不要、ファイル不要、思考不要。

ハーネス「OK」と言うためのプロンプトトークン出力トークンウォールクロック
DeepSeek Harness (dsh)10,89825.6s
Hermes Agent13,892 (+1,024 キャッシュ)178.5s

同じモデル。同じ質問。実際の作業が始まる前に2,994トークンの差。その差こそがハーネスです:システムプロンプト、ツールスキーマ、ルールファイル。Hermesはより多くの表面積を搭載しているため、より多くのトークンを送信します。

では、それを38回の呼び出しを行うエージェントループで考えてみてください。すべての呼び出しでこれまでの会話全体を再送信します。キャッシュ読み取りはdshのプロンプトトークンの88.8%、Hermesの95.5%を占めていました。その再読み取りが請求額です。

1つのエンドポイント、2つのハーネス:DeepSeek V4のセットアップ

シェルを比較するには、モデル側を完全に固定する必要があります。同じモデル名だけでなく、同じエンドポイント、同じレート制限、午前3時でも午後3時でも同じ価格。

最後のものは、聞こえ以上に重要です。プロバイダーがピーク時とオフピーク時のレートを課金する場合、「Hermesのラウンド1を09:00に」と「dshのラウンド2を11:00に」は比較可能な実行ではなくなり、デルタのうちどれだけがハーネスで、どれだけが時計によるものか、決して解きほぐせません。

そこで、両方のハーネスはAtlas Cloud上の1つの定額制OpenAI互換エンドポイントを指しています:https://api.atlascloud.ai/v1。1日中同じ価格、ピークウィンドウなし、ハーネスごとに別々のキューなし、両方に1つのキー。

テストでの役割モデルIDコンテキスト / 最大出力100万トークンあたりの価格(入力 / 出力)
両方のハーネスのメインエンジンdeepseek-ai/deepseek-v4-pro1,048,576 / 393,216$1.68 / $3.38
低価格帯、「アーム」の役割deepseek-ai/deepseek-v4-flash1,048,576 / 393,216$0.14 / $0.28
長時間実行cron作業deepseek-ai/deepseek-v3.2163,840 / 163,840$0.26 / $0.38

価格は2026-08-21のモデルページから読み取り。現在DeepSeekファミリーに割引バッジはないため、ここには来週期限切れになるプロモ料金はありません。

見逃しやすい小さなこと:/v1/modelsdeepseek-v4-prodeepseek-v4-flashfp4として報告しますが、deepseek-v4-pro-0813fp8として返します。高精度の重みが必要ですか?日付付きIDを固定してください。

よし。構築しましょう。

DeepSeek Harness vs Hermesテストを自分で実行する

プレビュー:7つのステップ、2つの設定ファイル、1つのプロンプト。そして、私のものを信頼する代わりに、その表の独自バージョンが手に入ります。機能する証明:上記のすべての数値は、ストックMacBook、Node v24.15.0、dsh 0.1.0-rc.7、Hermes v0.20.4で、まさにこれらの手順から得られました。

始めましょう。

ステップ1:固定されたエンドポイントを取得する

両方のハーネスは関数呼び出しに大きく依存しているため、何かをインストールする前に、エンドポイントがツールを提供していることを確認します:

plaintext
1curl -s https://api.atlascloud.ai/v1/models \
2  -H "Authorization: Bearer $ATLAS_API_KEY" \
3  | jq '.data[] | select(.id|test("v4-pro$")) | {id, context_length, max_output_length, supported_features}'

その呼び出しからの実際の出力:

plaintext
1{
2  "id": "deepseek-ai/deepseek-v4-pro",
3  "context_length": 1048576,
4  "max_output_length": 393216,
5  "supported_features": ["json_mode", "tools", "structured_outputs"]
6}

このリストのtoolsが確認すべきものです。ツールがないとエージェントループは機能せず、両方のハーネスが混乱した方法で失敗し、その理由を伝えません。

DeepSeek V4 Proモデルページからキーを取得し、以下のすべてのコマンドの前にexport ATLAS_API_KEY=...を実行します。

Hermes側の1つの落とし穴:レスポンスは配列を{"code":200,"msg":"succeed","data":[...]}としてラップします。Hermesはセットアップ中に/v1/modelsをプローブし、これを問題なく解析しますが、独自のツールを作成する場合は、ベアリストを期待しないでください。

ステップ2:両方のエージェントをインストールする

plaintext
1# DeepSeek Harness
2npm install @deepseek-ai/dsh
3
4# Hermes Agent
5curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

時間を費やした3つのインストールノート:

  • dshにはNode ^22.19.0 || >=24.0.0が必要です。23.xはサポートしていません。ほとんどのチュートリアルは「Node 20+」と言っていますが、それは単に間違っています。
  • そのnpmインストールは453パッケージを取得し、8分かかりました。小さな依存関係ではありません。
  • Hermesはuvを介して独自のPython 3.11を持ち込むため、システムのPythonは関係ありません(私のは3.9です)。インストーラーがPyPIの不具合でダウンロード途中で停止した場合は、スクリプト全体を再実行するのではなく、依存関係の同期を再実行してください。

ステップ3:DeepSeek Harnessをエンドポイントに向ける

これを$DSH_HOME/settings.yaml(デフォルトは~/.dsh)に書き込みます:

plaintext
1llm-pi-ai:
2  providers:
3    atlas:
4      displayName: Atlas Cloud
5      apiKeyEnv: ATLAS_API_KEY
6      api: openai-completions
7      baseURL: https://api.atlascloud.ai/v1
8      defaultContextWindow: 1048576
9      defaultMaxTokens: 65536
10      compat:
11        thinkingFormat: deepseek
12      models:
13        - id: deepseek-ai/deepseek-v4-pro
14          name: DeepSeek V4 Pro
15          reasoningEfforts:
16            off:
17            high: high
18        - id: deepseek-ai/deepseek-v4-flash
19          name: DeepSeek V4 Flash
20          reasoningEfforts:
21            off:
22            high: high
23agent-default-model:
24  provider: atlas
25  model: deepseek-ai/deepseek-v4-pro

その中の3行にはそれぞれ一文の価値があります。なぜなら、どれかを間違えると請求額が変わるからです:

  1. compat.thinkingFormat: deepseekは誰も書かない行です。 dshはエンドポイントURLから思考ダイアレクトを推測します。独自のアダプターREADMEは率直に述べています:プライベートゲートウェイのURLは何も語らないため、認識されないエンドポイントは「それがOpenAI自身であるかのように」アドレス指定されます。DeepSeekダイアレクトのゲートウェイには、OpenAIダイアレクトで話しかけられます。このキーはapi: openai-completionsの下にのみ存在します。
  2. defaultContextWindowを上書きします。 ルートレベルのフォールバックは262,144コンテキスト、32,768最大トークンです。V4モデルをそれらに触れずに手動で宣言すると、1,048,576ウィンドウの75%を静かに捨てることになります。
  3. agent-default-modelprovidermodelを2つの別々のキーとして取ります。 1つの文字列としてmodel: atlas/deepseek-ai/deepseek-v4-proと書くのは妥当に見えますが、何も機能しません。MISSING_CREDENTIAL: no API key for provider route "deepseek-official"が表示され、存在しないキーの問題を探し回ることになります。

apiKeyEnvは資格情報への参照であり、秘密そのものではないことに注意。このファイルにはキーは入りません。

ステップ4:Hermesを同じエンドポイントに向ける

ウィザードルートはhermes model、次に「カスタムエンドポイント」を選択します。スクリプト可能なルートは5つのコマンドです:

plaintext
1hermes config set model.provider custom
2hermes config set model.default deepseek-ai/deepseek-v4-pro
3hermes config set model.base_url https://api.atlascloud.ai/v1
4hermes config set model.api_key "$ATLAS_API_KEY"
5hermes config set model.context_length 1048576

これにより~/.hermes/config.yamlが書き込まれます:

plaintext
1model:
2  provider: custom
3  default: deepseek-ai/deepseek-v4-pro
4  base_url: https://api.atlascloud.ai/v1
5  api_key: apikey-...
6  context_length: 1048576

provider: customはここではエイリアスではなく、ファーストクラスのプロバイダーであり、ベースURLは/v1で終わる必要があります。なぜならHermesは自身で/chat/completionsを追加するからです(Hermes Agentドキュメント、Configuring Models、2026)。

そのapi_key行をスキップしないでください。ドキュメントではキーはOPENAI_API_KEYにフォールバックするとされていますが、私の実行ではその変数をエクスポートするだけでは不十分でした。Hermesは使用可能な認証なしでリクエストを送信し、AtlasはHTTP 401: {"code":401,"msg":"unauthorized"}と応答しました。model.api_keyを明示的に設定することで、次の試行で8.5秒で修正されました。

ステップ5:両方でラウンド1を実行する

まずHermesのスキルディレクトリ(~/.hermes/skills)をクリアします。既存のスキルがあるとラウンド1が不公平になり、ラウンド2でスキルが作成され再利用されるのを監視したいところです。

次に、両方のハーネスにこれをバイト単位で与えます:

plaintext
1Create a single self-contained file game.html: a Breakout clone with paddle, 5 rows of bricks,
2a live score counter, and a P key that pauses. No external libraries, no CDN, no build step.
3Then append an inline <script id="selftest"> block that asserts three physics invariants
4(ball reflects on paddle hit, score increments exactly once per brick, ball never leaves the canvas)
5and prints PASS/FAIL to the console. Run it headlessly, fix anything that fails, and stop only
6when all three asserts print PASS. Report the number of tool calls you used.

設定:ハーネスごとに新しい空のディレクトリ、推論はオン、最大出力は少なくとも32,768、マシンでは他に何も実行していないのでウォールクロックの数値に意味があります。

plaintext
1# dsh、ワンショット永続セッション
2DSH_HOME=~/.dsh dsh --profile headless "$(cat prompt-r1.txt)"
3
4# Hermes、ワンショット、機械可読な使用量レポート付き
5hermes -z "$(cat prompt-r1.txt)" --yolo --usage-file hermes-r1-usage.json

ここで2つのことに驚くでしょう。

まず、hermes -zは完了するまでまったく何も表示しません。バナーも、スピナーも、ツールプレビューもありません。私のは13分間静かに座って、ハングしたように見えましたが、実際には38回のAPI呼び出しを処理していました。安心が必要なら、psで子シェルを確認してください。

次に、Hermesは作業ディレクトリを無視し、game.html$HOMEに書き出しました。ファイルを起動した場所に置きたい場合は、--no-restore-cwdまたは--in DIRを渡してください。私はそれで1ラウンド失いました。

一方、dshは121秒で完了し、そのWeb UIは同じセッションを読み戻します:

DeepSeek Harness Web UI、完了したBreakoutセッション、3つのPASSアサート、9ステップ、133K入力トークン(DeepSeek V4 Pro使用)

dsh Web UI (127.0.0.1:3080)。ステータスバーに注目:9ステップ、キャッシュヒット89%、入力133Kトークン、モデルセレクターがステップ3の設定からDeepSeek V4 Proを読み取っている。

Hermes側の--usage-fileは本当に便利で、ドキュメント化が不十分です:入力トークン、出力トークン、キャッシュ読み取り、推論トークン、api_calls、推定コストをJSONに書き込み、実行が失敗してもそのファイルを書き込みます。

dshには同等のフラグはありませんが、必要もありません。追記専用のセッションログがすべてを保持しますが、1つの罠があります。$DSH_HOME/sessions/<encoded-cwd>/session-<uuid>/session.jsonl.zstdのログはマルチフレームのzstdストリームで、フラッシュごとに1フレームです。zlib.zstdDecompressSync(buf)は最初のフレームのみを返すため、150KBのログが数百バイトにデコードされ、空に見えます。自分でマジックバイトで分割します:

plaintext
1const MAGIC = [0x28, 0xb5, 0x2f, 0xfd], offs = [];
2for (let i = 0; i < buf.length - 4; i++)
3  if (MAGIC.every((m, j) => buf[i + j] === m)) offs.push(i);
4const text = offs
5  .map((o, k) => zlib.zstdDecompressSync(buf.subarray(o, offs[k + 1] ?? buf.length)).toString())
6  .join('');

使用量はassistant/chunkイベントにあり、data.chunk.type === 'usage'です。これは予想より1レベル深い場所にあります(data.chunk.usage.inputTokens)。ツール呼び出しはassistant/messageコンテンツブロックのtool-callタイプから取得します。そしてrequest/header.data.header.configは、実際にワイヤー上に送信されたモデルとmaxTokensを示しており、これによりステップ3の設定が有効になったことを証明でき、期待するだけではありません。

ステップ6:ラウンド2、変更リクエスト

同じディレクトリ、game.htmlはラウンド1からすでに存在しています。両方に変更を依頼します:

plaintext
1Add a falling power-up: when a brick in the top row breaks, drop a token that widens the paddle
2for 10 seconds. Keep all three selftest asserts passing and add a fourth assert for the power-up
3timer. Same file, no libraries.

これが2つの設計を分けるラウンドです。Hermesは複雑なタスクの後にスキルを書き、3層のメモリを保持するため、ラウンド2はラウンド1のスキルが報われるかどうかの場です。dshには長期的なメモリはまったくありませんが、追記専用のセッションログがあり、最初から再開する代わりに途中からフォークして再生できます。

これを始める前に、予算について正直になりましょう。私のラウンド2は、1日の支出上限に達して11回のツール呼び出しで終了しました。そのため、上の表には2つの空行があり、2つの捏造された行ではありません。Hermes自身のダッシュボードがその理由を示しています:

Hermes Agentダッシュボードのセッションページ。Breakout実行がdeepseek-v4-pro上で76メッセージであることをリスト表示

Hermes v0.20.4が自身のセッションを読み戻している。完了したBreakout実行は76メッセージ、すべてAtlasエンドポイント経由のdeepseek-v4-pro。

ステップ7:請求書を読む

実行ごとに2つの数値。ハーネス自身のログから。エージェントの要約からは決して取得しません:

plaintext
1# Hermes
2jq '{input_tokens, output_tokens, cache_read_tokens, api_calls}' hermes-r1-usage.json
3
4# dsh:デコードしたセッションログを集計
5node dsh-stats.js "$DSH_HOME/sessions/<encoded-cwd>"

次に、プロバイダーの使用量ページと照合します。ハーネスのログとプロバイダーが一致しない場合は、プロバイダーを信頼します:それがあなたが支払う数字です。

参考までに、dsh自身のステータスバーは私のログパーサーと四捨五入の範囲内で一致しました(133K入力トークン、89%キャッシュヒット vs 私の計算値132,600および88.8%)。ツールは正直です。エージェントの英語の要約はそうではありません。

DeepSeek Harness vs Hermesを超えて:両方を脳と腕として実行する

ここに「どちらを選ぶか」の議論で誰も提供しない答えがあります:選ぶ必要はありません。

2つのプロジェクトは正反対の方向で失敗するため、非常に優秀なチームメイトになります。

機能DeepSeek Harness (dsh)Hermes Agent
コーディング実行強力、これが設計目標同じタスクを6.4倍の時間で完了
長期記憶なし3層、エージェント管理
自己改善するスキルなしはい、agentskills.io互換
セッションログのフォーク/再生はい、追記専用JSONLセッション検索、LLM要約機能
組み込みcronいいえはい、自然言語スケジュール
チャットサーフェスいいえTelegram、Discord、Slack、WhatsApp、Signal
インターフェースWeb UI、TUI、ヘッドレスTUI、CLI、ダッシュボード、ゲートウェイ
ランタイムNode 22.19+/24+Python 3.11(バンドル)
成熟度0.1 開発者プレビュー、互換性を破る変更あり2026年2月リリース、v0.20.4
ライセンス / スター数MIT、176.5kMIT、233.6k

スター数は2026-08-21に両方のリポジトリから読み取り(deepseek-ai/deepseek-harness 176.5kスター、19.2kフォーク、NousResearch/hermes-agent 233.6kスター、46.8kフォーク)。合計だけでなく軌道を見てください:dshは2026-08-17に確認したとき144,361スターだったので、4日間で約32,000追加されました。

3つの組み合わせ方:

  • 脳と腕。 HermesをV4 Pro上でメモリ、スケジュール、Telegramスレッドを保持。実際のコーディングはdshを低価格帯で委任。1つのキーで両方をカバーするため、2つの課金関係を管理する必要はありません。
  • ループには低価格帯、判断には高価格帯。 定期的なcron作業はdeepseek-v3.2またはDeepSeek V4 Flashで実行し、難しい判断はProにエスカレーション。
  • 両方をヘッドレスで。 dsh --profile headlessとHermes -zはどちらもプロンプトを受け取り、1つの答えを出力するため、TUIなしでシェルスクリプトやCIステップに組み込めます。

正直な弱点についての公正な警告。なぜなら、長所だけをリストした比較は広告だからです。dshは0.1の開発者プレビューであり、自身のUIでそう述べています:バージョン間で互換性が壊れ、メモリがなく、ネイティブのメッセージングチャネルがなく、自身のツール呼び出しを過小報告します。Hermesは広い差でより成熟したプロジェクトですが、トークンあたりの重さは8倍で、dshが2分で完了したタスクで13分間沈黙し、出力ファイルを間違ったディレクトリに書き出しました。

DeepSeek Harness vs Hermesのタスクあたりの実際のコスト

では、仮定を明らかにした上での計算です。

AtlasはV4 Proの入力レートを1つ公開しています(100万トークンあたり$1.68)。モデルページには別のキャッシュヒットレートはありません。したがって、すべてのプロンプトトークンを完全な入力レートで価格設定します(キャッシュ読み取りも含む)。これは控えめな上限であり、推測を測定値として偽装したものではありません。

計算例、dshラウンド1:

  • プロンプト:14,840新規 + 117,760キャッシュ = 132,600トークン。$1.68/100万で**$0.2228**。
  • 出力:5,231トークン。$3.38/100万で**$0.0177**。
  • 合計:タスクあたり**$0.2404**。

同じ方法でHermesラウンド1:1,111,573プロンプトトークンは$1.8674、さらに19,317出力トークンが$0.0653、合計**$1.9327**。Hermes自身の--usage-fileはその実行で$0.2817と推定しており、これはキャッシュ入力レートを100万トークンあたり約$0.125と仮定していることを意味します。プロバイダーが実際にキャッシュ読み取りをそれほど大幅に割引する場合、以下の両方の数値が一緒に下がり、それらの比率はほとんど変わりません。

シナリオV4 ProでのタスクあたりコストV4 Flashでのタスクあたりコスト20タスク/日、30日間(Pro)
dshラウンド1$0.24$0.02$144.27
Hermesラウンド1$1.93$0.16$1,159.64
ラウンド2、どちらのハーネスでも未完了未完了未完了

この表から2つのことが飛び出します。

ハーネスの選択は8倍の価値があります。同じモデル、同じタスク、同じ結果で、一方のシェルはもう一方の8倍のコストがかかります。これは後で最適化して削減できるような四捨五入の差ではありません。

モデル層はその上に12倍の価値があります。だからこそ、脳と腕の分割はギミックではありません:dsh on Flashはタスクあたり2セント、Hermes on Proは同一のBreakoutゲームでほぼ2ドルです。

そして、何よりも安価な最適化は、依然としてステップ3のものです。デフォルトの262,144のままにされたdshルートは、同じジョブを収めるためにより多くのステップでより多くの圧縮作業を行い、そのすべてに対して支払いが発生します。

それがDeepSeek Harness vs Hermesに対する本当の答えです:より安いモデルを探しに行く前に、自分自身のシェルを測定してください。

DeepSeek Harness vs Hermes FAQ

Hermes AgentとDeepSeek Harnessは同じモデルとAPIキーを使用できますか?

はい、そしてそれがそれらを比較する唯一の正直な方法です。どちらもOpenAI互換のエンドポイントと通信します。dshはapi: openai-completionsbaseURLを持つllm-pi-aiプロバイダールートが必要です。Hermesはprovider: custom/v1で終わるbase_urlが必要です。1つのキー、両方のハーネス、両方の価格帯。完全な設定はステップ3と4にあります。

DeepSeek HarnessはコーディングにおいてHermesより優れていますか?

このテストでは、明らかにそうです:121秒対780秒、8回のツール呼び出し対35回、トークン消費は8分の1で、両方とも3つのセルフテストすべてに合格しました。しかし「コーディングに優れている」は「より優れている」という意味ではありません。必要なものが、毎朝Telegramに報告し、先週学んだことを覚えているスケジュールされたジョブである場合、dshにはそのような機能はなく、Hermesにはすべてあります。

DeepSeek HarnessとHermesは無料でオープンソースですか?

両方ともMITライセンスで、無料でダウンロードできます。支払うのはトークンであり、上の表が示すように、それは四捨五入の誤差ではありません。dshは明示的に0.1の開発者プレビューであり、自身のUIで互換性を破る変更について警告しているため、本番環境に近づける場合はバージョンを固定することをお勧めします。

なぜ同じタスクが一方のハーネスでより高くつくのですか?

おおよそ大きさの順に4つの理由:

  • 会話の再読み取り。 キャッシュされたプロンプトトークンはdshの合計の88.8%、Hermesの95.5%を占めました。余分なステップごとに、それ以前のすべてが再送信されます。
  • システムプロンプトとツールスキーマ。 上記で測定:作業が始まる前に10,898対13,892トークン。
  • ステップ数。 8回のツール呼び出しと9ステップ対35回のツール呼び出し(38回のAPI呼び出し)。
  • 制限されたウィンドウ。 dshが262,144にフォールバックし、1,048,576ではなくなるため、長いタスクで余分な圧縮作業が強制されます。

DeepSeek HarnessとHermesを同時に実行できますか?

はい。APIキー以外は何も共有しません:異なるランタイム、異なる設定ディレクトリ、異なるセッションストア、異なるポート(デフォルトで3080と9119)。一般的なパターンは、Hermesを高価格帯の常時稼働の脳として、dshを低価格帯のコーディングアームとして使用することです。

DeepSeek HarnessはDeepSeek自身のAPIでしか動作しませんか?

いいえ、そしてこれが最も一般的な誤解です。OpenAI互換のゲートウェイはすべて、api: openai-completionsbaseURLを介して動作します。ただし、compat.thinkingFormat: deepseekを忘れないでください。dshはURLから思考ダイアレクトを推測するため、サードパーティのゲートウェイURLは何も伝えません。

最新モデル

ひとつのAPIで、あらゆるメディアAIを。

すべてのモデルを探索