Fugu、話題ですね。Sakana AI の、複数モデルを束ねるオーケストレーション。ベンチは一部 Mythos/Fable 級らしい。性能は良さそう。ただトークンと時間はかなり食うっぽい。 で、LUCIAN｜AI × Blockchain とかに「これ agmsg でできるんじゃん」みたいに言われたので、やってみた。Claude Code・Codex・Gemini を同じ部屋に集めて、難しめのタスクをやらせてみた。 #agmsg

で、何をやらせたか。お題は agmsg の実際の宿題で「ストレージ層を 1.1.0 で agent type をプラグ化したのと同じノリでプラグ可能にする(sqlite / postgres / 将来の別バックエンドを driver 1個ずつ)。一番綺麗な設計は? 最大のリスクは?」。これを Claude Code が Codex と Gemini に同時に投げた。 面白いのが、2体が別々に考えたのにコア設計がほぼ一致したこと。どっちも「lib/storage.sh をファサードにして、各 driver は storage_* の共通I/Fだけ実装。呼び出し側は SQL も DB パスも触らない。env > config > default(sqlite) で解決、driver はアローリストで自動検出」に着地。最大リスクも揃って「storage_watermark が SQL の WHERE 断片を受け取る設計は漏れる、NoSQL で破綻するから構造化パラメータに直せ」を指摘。 効くのはここから。2体が拾った別のリスクが噛み合う。 Codex は移行の現実：「直 SQL・ロック・watermark・既読更新が各スクリプトに散ってて、置換漏れで backend 間の意味がズレるのが怖い。まず sqlite driver に contract test を固定してから postgres を足せ」。順番の話。 Gemini はもっと細かい地雷：「source でロードすると Bash のグローバル関数を上書きし合う(名前空間汚染)」「ISO8601 のタイムゾーン/精度がズレると watch ループでメッセージを取りこぼす」「postgres 接続が固まると CLI ごとハングするから storage_check は 500ms でタイムアウトしてフォールバック」。 片方だけだと足りない。Codex の「安全な進め方」と Gemini の「踏むと死ぬ地雷」が合わさって、はじめて実装に移せる設計になる。最後に Claude Code が全部1つのプランに畳んだ。

ご存知の通り agmsg はこれを全部ローカルでやる。どのモデルを使うか裏で決めるホスト型と違って、誰を部屋に入れるかは自分で選ぶし、やり取りも全部見える。さっきの会話も丸ごと SQLite に残ってるから、あとから「誰が何て言ったか」を引っ張れる。実はこの Post も、その履歴を引いて書いた。 Fuguはなんかトークン溶けそうだし、Fableはなかなか再解放されないしで、もやもやしてて、まだ #agmsg 試してない方はお気軽にMythos/Fable級（？！バズワードw）を体験してみては？ agmsg（GitHub）:

@lucianlamp コスト的に中華ベンダー織り交ぜるのもよいと思うのです　会社だと難しそうですが

@lucianlamp なるほど、ハーネスはClaude CodeとかCodex、接続先が中華系とかですかね。確かにそれだと安くなりそうだし多分動きますね。agmsgはハーネスベースなので。そのうち試してみたい

@lucianlamp qwen をalibaba経由は安定してて良い感じです

@lucianlamp 今めちゃくちゃagmsg気になってます。claudeの時にmcp組んでやってましたが、opus4.8品質が落ちたのと止まりすぎて今codexに逃げてます。 claudeはopus4.8が指揮してるのでしょうか？

@lucianlamp ここでは Opus4.8が立ち上がってますが、どのモデルでも構いません！ぜひお試しを ^^

@lucianlamp ありがとうございます。 mcpでも結構品質が良くなったので、試してみます‼︎ Fable難民の救済となれば最高です‼︎

@lucianlamp よほどの儲かるところ以外はオープンルーターのFusionになりそうですね。ともにAPI。

@lucianlamp これ私も全く同じもの組んで使ってた。コード触り初めて1ヶ月くらいだけどベンチマークテスト使って最適化したら速度も精度も上がった。工夫次第でかなり色々性能上がって面白いねほぼ満点取るよ。