GitHubで ★35,444 を集めている esengine/DeepSeek-Reasonix は、名前に「DeepSeek」を冠したターミナル向けコーディングエージェントだ。掲げている売り文句は一つ、「Engineered around prefix-cache stability — leave it running.（プレフィックスキャッシュの安定性を軸に設計した。動かしっぱなしにしていい）」である。だがこの手のキャッチコピーは、紹介記事を経るうちに検証されないまま定着する。幸い「接頭辞が安定している」はバイト単位で数えられる主張だ。本記事ではREADMEをいったん脇に置き、OpenAI互換の偽エンドポイントを立てて実際に飛んでいるリクエストを捕捉し、4ターン分を突き合わせた。

ターミナルでreasonix v1.38.1を起動し、続けて2ターン分のリクエストを比較して system prompt・session-context・tools がいずれも不変であることを表示している様子
本記事で実際に録画した検証セッション。reasonix run を1ターン進めた直後に、前後2ターンのリクエストを突き合わせている。既存メッセージは全て byte-identical: True
この記事のポイント — 30秒でわかるReasonix
・DeepSeek公式ではない。所有者 esengine は個人アカウントで、公式Orgの deepseek-ai とは無関係。名前の「DeepSeek」は既定で接続するモデルを指す
・Go製の単一バイナリ。npmで入るのは自分のプラットフォーム向け1本だけで、実測42.5MiB
・看板の主張は実測で成立していた。4ターン回して接頭辞の差分は0バイト
・9ファイル追加とgitブランチ切替の後も、起動時スナップショットはバイト同一のまま
・MIT・★35,444・本記事執筆当日もコミットが入っている活発なプロジェクト

エージェント基盤そのものの全体像や、他フレームワークとの位置づけを先に押さえたい方は、まずAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を参照してほしい。本記事はその中の1本を、実測に絞って掘り下げる。

Reasonixとは何か——DeepSeek公式との関係を先に確定させる

この記事で最初に片付けるべきは、このOSSがDeepSeek公式なのかどうかである。リポジトリ名が DeepSeek-Reasonix で、npmパッケージの説明も「Cache-first DeepSeek coding agent」なので、公式の配布物だと読める。しかし実測した5つの事実は、いずれも逆を指している。

確認項目 実測結果（2026年9月8日） 意味
所有者アカウント種別 esengine は User（個人） 公式Orgではない
deepseek-ai/reasonix 404 公式側に同名リポジトリなし
deepseek-ai/DeepSeek-Reasonix 404 同上
esengine/reasonix 301リダイレクトして現リポジトリへ 後から改名された
READMEの関係表記 提携・非提携の記載が1つもない 明示的な否認も肯定もない

決定的なのは4行目だ。esengine/reasonix にアクセスすると esengine/DeepSeek-Reasonix へ301で転送される。これはGitHubがリポジトリ改名時に張るリダイレクトであり、このプロジェクトは元々ただの reasonix だったことを示す。改名時期も絞り込める。タグごとのREADMEを引くと、v0.9.0（2026年4月26日）までは esengine/reasonix と書かれており、v1.0.0（2026年6月3日）では esengine/DeepSeek-Reasonix に変わっていた。つまり「DeepSeek-」の接頭辞は、1.0リリース前後に後から付いた。

では「DeepSeek」は何を指すのか。答えは接続先のモデルだ。READMEは「DeepSeek ships as a preset（DeepSeekはプリセットとして同梱される）」と書いており、npm版の説明文も初版0.0.1（2026年4月21日）から一貫して「DeepSeek-native」を名乗っている。所有者ではなく、既定で叩く相手の名前である。

なお、これを「紛らわしい命名だ」と断じる材料は見つからなかった。Issueを official / affiliated / trademark で検索したところ、提携関係や商標を問うIssueは0件だった。official を含むIssueは21件あるが、中身はいずれも「official DeepSeek models（DeepSeek公式のモデル）」「official Go SDK」のように接続先のAPIやSDKを指す用法で、むしろプロジェクト側が自分と公式APIを言葉の上で区別していることを裏づけている。事実としては「個人開発・非公式・DeepSeek特化」であり、読者が誤認しないようにだけ書いておけば足りる。

CLI/TUI・デスクトップ・ブラウザ・エディタ（ACP）という4つの入り口が、1つのローカルエンジンに接続する構成図
入り口は4つあるが、叩いているローカルエンジンは1つ。VS Code拡張はCLIを同梱しないため、拡張だけ入れても動かない点に注意

名前が似ているDeepSeek Harnessとの判別表

もう一つ紛らわしいのが、DeepSeek Harness（dsh） との混同だ。こちらは正真正銘のDeepSeek公式である。名前が似ているだけで中身は別物なので、先に切り分けておく。

  DeepSeek Harness（dsh） Reasonix
開発元 deepseek-ai（DeepSeek公式） esengine（個人アカウント・非公式）
リポジトリ deepseek-ai/deepseek-harness esengine/DeepSeek-Reasonix
実装言語 TypeScript / Node.js Go
配布形態 npm（Nodeランタイム必須） 単一バイナリ（npm・Homebrew・直接DL）
コマンド dsh reasonix
設計の看板 Everything is a Plugin prefix-cache stability
ライセンス MIT MIT

DeepSeek Harness側の実測（起動しない原因やプリセット4種の差分）はDeepSeek Harnessとは｜DeepSeekハーネスの使い方・起動しない原因・プリセット4種を実測にまとめてある。公式の実装を探しているならそちらが目的地で、本記事のReasonixは別系統の選択肢だ。

Reasonixのインストールと配布形態——npmに入っているのは何か

READMEは「CGO_ENABLED=0 の単一バイナリ」を強調している。npm経由で入れて中身を数えた。

npm i -g reasonix                  # 任意のOS
brew install esengine/reasonix/reasonix   # macOS

まずnpmの配布物そのものを見ると、reasonix パッケージの実体は 5,483バイト・3ファイルしかない。bin/reasonix.js（21行）・package.json・README.md だけで、本体コードは1バイトも入っていない。ただしこれは「postinstallで外部からダウンロードしてくる」型ではない。package.json の optionalDependencies に6つのプラットフォーム別パッケージが宣言されており、npmが自分の環境に合う1つだけを解決して入れる仕組みだ。ラッパーは require.resolve() でそれを探して spawnSync するだけの薄い層にすぎない。

実際にmacOS arm64で入れると、インストールされたのは reasonix 本体と @reasonix/cli-darwin-arm64 の2パッケージのみで、他の5プラットフォーム分は落ちてこなかった。バイナリの実測サイズは 44,564,818バイト（42.5MiB）、node_modules 全体でも43MBである。

$ file node_modules/@reasonix/cli-darwin-arm64/bin/reasonix
Mach-O 64-bit executable arm64
$ otool -L node_modules/@reasonix/cli-darwin-arm64/bin/reasonix
	/usr/lib/libSystem.B.dylib
	/usr/lib/libresolv.9.dylib
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
	/System/Library/Frameworks/Security.framework/Versions/A/Security

リンクしているのはmacOS標準のシステムライブラリ4本だけで、サードパーティの動的ライブラリは無い。「単一バイナリ」の主張はそのとおりだった。資格情報を与えずに走らせると、余計なことをせず即座に停止する。

$ reasonix --version
reasonix v1.38.1
$ reasonix run "say hi"
error: provider "deepseek-flash": missing env DEEPSEEK_API_KEY

なおソースからビルドする場合の要件は重い。CLIだけでも Go 1.26以上が必要で、go.mod が toolchain ディレクティブを固定している。デスクトップ版はさらに Node 24以上・pnpm 10・Wails CLI（バージョンは .wails-version で固定）が要る。単に使うだけなら配布バイナリを取るのが正解だ。

看板の「プレフィックスキャッシュ安定性」を4ターン実測する

ここからが本題である。LLMのプレフィックスキャッシュは、リクエストの先頭部分が前回と完全に一致している間だけ効く。1文字でも変われば、そこから後ろは再計算になる。つまり「動かしっぱなしにしていい」と言うなら、ターン間で先頭が変わらないことを実証できるはずだ。

APIキーは使わない。OpenAI互換のダミーサーバーをローカルに立て、飛んできたリクエストのbodyをそのまま保存する方式にした。Reasonix側はプロバイダを1エントリ足すだけで向き先を変えられる。

[[providers]]
name        = "probe"
kind        = "openai"
base_url    = "http://127.0.0.1:8788/v1"
models      = ["probe-model"]
api_key_env = "PROBE_API_KEY"

この状態で reasonix run を1ターン、続けて -c（同一セッションを継続）で3ターン、合計4ターン流した。陽性対照として、まず捕捉できたリクエストが4本あることを確認している——0本なら「差分が無い」と「そもそも測れていない」を区別できないからだ。

実測ハイライト。4ターン間の接頭辞の差分は0バイト、messages本数は3から9へ、配布バイナリは42.5MiB
2026年9月8日・v1.38.1・macOS 14.5 arm64での実測値。捕捉したリクエスト数は4本

捕捉した4本を分解すると、1リクエストは4つの部分でできていた。

1リクエストの構造。system prompt、session-context、会話履歴、tools定義の4層で、伸びるのは会話履歴だけ
伸びるのは会話履歴だけで、他の3つは4ターン通してバイト単位で同一だった

結果は明確だった。messages の本数は 3 → 5 → 7 → 9 と1ターンあたり+2（ユーザー発話とアシスタント応答）で純増する一方、既に存在していたメッセージは1つも書き換わらなかった。具体的には次のとおりである。

要素 サイズ 4ターン通しての変化
system prompt 3,326字 バイト単位で同一
session-context 2,365字 バイト単位で同一
tools 定義（13ツール） 18,510バイト バイト単位で同一
会話履歴 3→9件 append-onlyで純増のみ

つまり厳密な追記専用（append-only）になっている。これはプレフィックスキャッシュが効く条件そのものだ。セッションを継続すると、Reasonix自身も cache_state=warm とログに出す。

ただし「リクエストbodyの差分」を見ると誤読する

ここに落とし穴が一つある。生のJSONリクエストbodyどうしで共通のバイト接頭辞を数えると、わずか25.3%しか一致しない。素朴に diff を取った人は「全然安定していないじゃないか」と結論しかねない。

原因はJSONのキー順だ。このクライアントは messages を tools より前に直列化する。そのため会話が1件増えた瞬間、messages 配列の末尾で分岐が起き、その後ろに続く18,510バイトのツール定義は「一致しない領域」として数えられてしまう。実際に分岐点の前後を見ると、片方は ],"tools":[... に進み、もう片方は ,{"role":"assistant"... に進んでいる——内容が変わったのではなく、追記位置がツール定義の手前だっただけである。

プロバイダ側はJSONをパースしてからプロンプトを組み立てるので、この直列化順は実際のキャッシュヒットに影響しない。測るべきは生bodyのバイト列ではなく、パース後の会話接頭辞だ。この記事の判定はすべて後者で行っている。

何がキャッシュ接頭辞から外されているのか

安定している理由は、入れていないものを見ると分かる。session-context と名付けられたブロックの中身を実際にダンプすると、こうなっていた。

・OS種別（darwin/arm64）とシェル
・検出できた開発ツールとそのバージョン（git / go / node / python3 / docker / make / rg）
・見つからなかったツールの一覧（cargo / rustc など）
・ワークスペースの絶対パス
・利用可能なスキルのカタログ
・末尾に Digest: sha256:83f027… という自己申告のハッシュ

含まれていなかったもののほうが重要だ。日時・タイムスタンプの類が一切ない。gitのブランチ名もHEADも無い。ファイル一覧も無い。冒頭には「This host-generated snapshot supersedes every earlier session-context snapshot（このスナップショットは以前のものをすべて置き換える）」と明記されており、追記せず置換する設計であることを自ら宣言している。

これが偶然でないことを確かめるため、意図的に揺さぶってみた。ワークスペースに9ファイルを追加し、gitで新しいブランチに切り替えてから次のターンを流した。もし内部でファイル一覧やブランチ名を拾っていれば、ここで接頭辞が壊れる。

結果、session-context は2,365字のままバイト単位で同一だった。ファイル名にもブランチ名にも一切言及がない。

接頭辞を壊す設計と壊さない設計の比較。現在時刻・ファイル一覧・gitブランチを入れると壊れ、Reasonixはいずれも入れていない
「安定している」の実体は、揮発する情報をプロンプトの先頭に置かないという設計判断だった

この方針は現在も進行中であることが、ブランチ名からも読み取れる。リポジトリには perf/memory-index-out-of-prefix / perf/skill-catalog-out-of-prefix / perf/vcs-out-of-cached-prefix という作業ブランチが並んでおり、メモリ索引・スキルカタログ・バージョン管理情報をキャッシュ接頭辞の外へ追い出す作業が続いている。READMEの宣伝文とは独立した、設計優先度の裏づけと言える。

flowchart TD A["起動時に1回だけ
環境スナップショットを生成"] --> B["system prompt
3,326字・不変"] B --> C["session-context
2,365字・不変"] C --> D{"次のターン"} D -->|"会話を末尾に追記"| E["接頭辞はそのまま
キャッシュが効く"] D -->|"先頭に日時やgit状態を注入"| F["接頭辞が壊れ
再計算になる"] E --> D style E fill:#19c2a8,color:#fff style F fill:#e5534b,color:#fff

なお副作用として、ワークスペースの現在の状態はプロンプトに載っていないという点は理解しておきたい。エージェントはファイル一覧を渡されるのではなく、必要になったら read_file や bash を自分で呼んで取りに行く。同梱ツールは ask / bash / bash_output / complete_step / compress / edit_file / kill_shell / read_file / todo_write / update_goal / use_capability / wait / write_file の13個だった。

もう一つ実測で分かったのは、スキルの探索が他のエージェントと共用のディレクトリを見ていることだ。検証環境では、筆者がClaude Code向けに置いていたスキル群がそのままカタログに現れた。既存のエージェント資産を共有できる一方、意図しないスキルが接頭辞に載る可能性もあるため、reasonix.toml の [skills] で excluded_paths や disabled_skills を使って制御できるようになっている。

Reasonixを導入する前に確認しておきたいこと

実測で確認できた範囲を、判断材料として整理する。

メンテナンス状況は活発だ。本記事の執筆当日（2026年9月8日）にもコミットが入っており、直近リリースは CLI v1.38.1（9月6日）、デスクトップ desktop-v1.38.1（同）、studio-v2.13.0 はプレリリース扱いである。npm版は初版から256バージョンが公開され、直近1週間のダウンロードは3,518件。★35,444・フォーク2,378・MITライセンスで、既定ブランチは main-v2 だ。「★は多いが半年止まっている」型のプロジェクトではない。

一方で注意すべき点もある。

・非公式である。 繰り返しになるが、DeepSeekのサポート窓口や公式SLAは期待できない。寄付先も個人のPayPal／WeChat Payであり、README自身が「寄付は機能の優先度を買うものではない」と明記している
・リリース間隔が非常に短い。 1週間に複数のマイナー更新が入るペースで、バージョンを固定せずに運用すると挙動が動く可能性がある
・既定ブランチが main-v2。 main を前提にした手順やURLは当たらない
・VS Code拡張はCLIを同梱しない。 拡張だけ入れても動かず、先にCLIを入れてローカルの reasonix acp を起動させる構成になっている
・本記事の検証はダミーのエンドポイントに対するものであり、実際のDeepSeek APIでキャッシュヒット率がどれだけ改善するかは測っていない。確認したのは「クライアントが送るリクエストの接頭辞が安定していること」までで、課金額の削減幅は未検証である

最後の点は誤解されやすいので明示しておく。接頭辞が安定していることはキャッシュが効くための必要条件であって、実際の削減率はプロバイダ側のキャッシュ実装・TTL・課金体系に左右される。本記事が示したのは「クライアント側の宿題は果たされている」という事実までだ。

同じくコーディングエージェント系では、SWE-benchスコアを軸に据えたOpenHands完全ガイド：SWE-Bench 77.6%のOSS AIコーディングエージェント徹底解説も比較対象になる。設計の力点がベンチマーク性能か、長時間運用時のコスト安定性かで選択は変わる。

まとめ

Reasonixについて、実測で確定したのは次の点である。

・DeepSeek公式ではない。個人アカウント発で、元の名前は reasonix。「DeepSeek-」は1.0リリース前後に後から付いた接頭辞で、指しているのは接続先のモデルである
・公式の実装を探しているなら、目的地は別物のDeepSeek Harness（dsh）のほうだ
・「単一バイナリ」は事実。npmで入るのは自分の環境向け1本（42.5MiB）だけで、システムライブラリ以外にリンクは無い
・看板の「プレフィックスキャッシュ安定性」は、実測した範囲で成立していた。4ターン回して system prompt・session-context・13ツール定義はバイト単位で不変、会話は純粋な追記のみ
・その実体は「揮発する情報を先頭に置かない」という設計判断だった。日時もgitの状態もファイル一覧も入っておらず、9ファイル追加とブランチ切替の後もスナップショットは変わらなかった
・ただし生のリクエストbodyを差分すると25.3%しか一致しない。messages が tools より前に直列化されるためで、これを根拠に「不安定だ」と判断するのは誤読になる

看板の主張が実測に耐えるOSSは、実のところ多くない。Reasonixは少なくとも、自分が掲げた1点については数えられる形で果たしていた。

参照ソース

・esengine/DeepSeek-Reasonix — GitHub（リポジトリ本体・README・ブランチ一覧。★数・フォーク数・ライセンス・既定ブランチはGitHub REST APIで2026年9月8日に取得）
・reasonix — npm（配布形態・バージョン履歴・ダウンロード数。tarballの構成は npm pack で実測）
・docs/SPEC.md — DeepSeek-Reasonix（reasonix.toml のプロバイダ定義・[environment] ブロックの仕様）
・deepseek-ai/deepseek-harness — GitHub（比較対象であるDeepSeek公式ハーネス）