ターミナルで fx と打つとJSONが色付きで開く、あのCLIを思い浮かべた人はいったん忘れてください。
今回の fx はVercel Labsが出したコーディングエージェントで、名前がぶつかっているだけの完全な別物です。
バイナリ7.8MiB、書かれている言語がZig、公式サイトに載っているコールドスタートが10マイクロ秒。
この3行を見た時点で気になって仕方なくなったので、リポジトリと公式サイトを端から読みました。
バイナリ1個で動くコーディングエージェント 中身はZigで7.8MiB
READMEの名乗りが Tiny, open, embeddable, native coding agent です。
リポジトリは vercel-labs/fx、ライセンスはApache-2.0。
で、作成日を見て二度見しました。
2026年8月11日です。
9日前に生まれたリポジトリが、8月20日時点で1,054スター、102フォーク、オープンなissueが41件。
Hacker Newsでも8月18日に153ポイント、コメント78件まで伸びていました。
こちらはその日のスナップショットなので、今はもっと動いているはずです。
サイズの表記には食い違いがあって、GitHubのREADMEが7.8MiB、公式サイト側は6.39MiBと書いています。
公式サイトのバージョンが v0.0.4 なので、たぶんどこかのビルドの差です。
どちらにしても1桁MiB台の実行ファイルが1個あるだけで、Node.jsもPythonも要りません。
ここがまず効きます。
node_modules を作らないコーディングエージェントは、置ける場所が一気に増えるんですよ。
コールドスタート10マイクロ秒はどこに効いてくるのか
公式サイトが出している数字が、コールドスタート10マイクロ秒とメモリのベースライン1桁MiBです。
念のため書いておくと、これはプロセスが立ち上がるまでの話で、モデルの返事が10マイクロ秒で返ってくるわけではありません。
じゃあ何が変わるのか。
常駐させない使い方が現実的になります。
CIのステップ、gitのフック、使い捨てのコンテナ。
呼ぶ、答えを受け取る、消える。
軽量なコーディングエージェントの仕組みがいちばん活きるのが、この回し方です。
公式サイトの言い方だと、即座のインストールと、リソースが厳しい環境への組み込みを狙った設計。
エージェントを「開いて使うアプリ」ではなく「呼び出す部品」として置きにきているわけです。
fx ask をパイプに挟めるのがUnix likeの中身
リポジトリの説明文が Unix like coding agent の一言だけなんですが、この看板には実体があります。
1回だけ聞いて終わるモードがこれです。
fx ask "explain the changes in this repository"そしてREADMEにこう書いてあります。
プロンプトのテキストはstderrに出すので、JSONのstdoutはパースできる状態を保ち、quietのstdoutは空のままになる、と。
僕はここでちょっと声が出ました。
読み飛ばしそうな1行ですけど、| の途中にエージェントを置けるかどうかはここで決まります。
対話用の文言がstdoutに1文字でも混ざると、後ろの jq が死ぬので。
出力先を分けてあるから、そのままファイルにも落とせます。
fx ask "explain the changes in this repository" > review.md対話モードのUIも同じ思想で、公式サイトいわく重量級のTUIではなくシェル寄りの見た目と操作感。
スクロール履歴を既定で残して、出力は最小限に抑える方針です。
画面を全部乗っ取った挙句、終了したら何も残っていないタイプのUIに疲れている人は、この時点でかなり好きだと思います。
インストールは1行、そこからモデルに繋ぐまで
公式サイトの fx.sh が配っているスクリプトを叩くだけです。
curl -fsSL https://fx.sh/setup.sh | bashcurl の結果をそのまま bash に流す形なので、気になる人は一度落として中身を読んでから実行してください。
Vercel Labsのfxを使い始めるまでに叩くコマンドを並べます。
fx loginfx setupfxfx ask "..."fx sessionsfx session resume lastfx acpfx status fx doctorセッションを個別に指定したいときは fx session resume --id です。
モデルとプロバイダは非依存で、ローカルモデルでもゲートウェイ経由でもプロバイダのAPI直でも構わない、と公式サイトには書かれています。
ソースから組みたい人は zig build -Doptimize=ReleaseSafe を叩けば ./zig-out/bin/fx が出てきます。
既定のパーミッションがautoなのは先に知っておきたい
READMEを読んでいていちばん手が止まったのが、パーミッションの既定値です。
fxは auto パーミッションモードで起動する、と書かれています。
日常的で内容が分かっている開発操作はそのまま走り、判断がつかない危険な操作にだけ自動レビューが1回入る、という設計です。
つまり毎回Y/Nが出てくる前提で走らせると、想像と違う挙動になります。
さらにJSONリクエストとquietリクエストは既定で非対話。
--prompt-permissions を足すと、標準入力がTTYのときだけ従来のY/N確認が戻ってきます。
ルールを固定したいときは対話中のコマンドが用意されていて、/permissions remember で許可か拒否をツール単位で覚えさせ、/permissions でルールIDの一覧、/permissions revoke で剥がせます。
診断が要るときは /trace でログ込みのMarkdownが出ます。
CIに組み込む前に、ここだけは読んでおいた方がいいです。
自動で走るから速いわけで、速さと危うさは同じ設計から出ています。
本命はWASMで自分のアプリに埋め込めるところ
名乗りに入っている embeddable が何を指しているのか、READMEの該当箇所ではっきりしました。
createFxAgent() でエージェントのコアを fx-core.wasm としてJavaScriptのホストに埋め込めます。
createFxTerminal() なら対話ターミナルごと fx-term.wasm で埋め込めます。
自分のWebアプリの中に、エージェントの中身を丸ごと置けるということです。
ここまで来ると、CLIツールを紹介されているというより部品を渡されている感覚に近いです。
拡張の考え方も揃っていて、公式サイトの表現ではコアは小さいまま、skillsとpluginsとMCPで足していくUnix的な拡張哲学。
独立したタスクを投げるsubagentsもあります。
コアを太らせずに周辺で伸ばす方針が、最初から通っています。
今のfxはClaude Codeの置き換えにはならない
正直に書くと、今日から本業のメインを乗り換える道具ではないです。
バージョンが v0.0.4 で、公式サイトにも実験的であること、頻繁に変更を入れることが明記されています。
9日前に生まれてissueが41件開いている状態なので、それはそうという話でもあります。
刺さる場所はかなりはっきりしていて、こういう用途です。
- CIやgitフックのように、1回呼んですぐ終わらせたい場所
- コンテナやエッジのように、容量とメモリの上限が厳しい場所
- 自分のプロダクトにエージェント機能そのものを埋め込みたい場合
逆に、大規模なリファクタを任せて長時間並走させる用途なら、今のところ使い慣れたエージェントのままで問題ないと思います。
軽さのために何を削ったのかを分かった上で選ぶ道具です。
触ってみるなら、まず setup.sh の中身を読むところからどうぞ。

💬 コメント
ログイン か 会員登録 するとコメントできます