Codex モバイルから、ECLIPSE02 VM を“社員エージェント”として見えるところまで持っていった。 今回はかなり面白い分岐だった。 ✅ ECLIPSE02-AQUA が Codex モバイル上に表示 ✅ ECLIPSE02 プロジェクトも表示 ✅ App Server thread がモバイル側に同期 ✅ LiteLLM guardrail 経由で Z.ai GLM を接続 ✅ VM内で pwd、ファイル作成、cat 読み戻しまで成功 特に面白かったのは、最初に成功していた SSH 経由の codex exec は、モバイルのタスク一覧には出ないこと。 つまり、 「VMでCodexが動いた」 だけでは、Codexモバイル上のタスクになったとは言えない。 モバイルに出すには、Codex App Server / Remote Control 側の thread として保存面に乗せる必要があった。 今回の切り分けはこんな感じ。 🟡 既存Z.ai adapter テキスト応答はできたが、tool実行とファイル作成は不足。 🔴 Z.ai直結 Codex 0.135 が Responses wire を要求し、Z.ai coding endpoint の responses 経路とは合わず失敗。 🔴 LiteLLMのみ Responses変換はできるが、Codexが投げる namespace / web_search / image_generation などのtool schemaをZ.ai側が拒否。 🟢 LiteLLM function tool filter Codexのtoolをfunction toolだけに絞ると、Z.ai GLM経由でVM内コマンド実行まで通った。 🧪 証拠としては、App Server threadからVM内にmarkerファイルを作成し、読み戻しまで確認。 VM02_APP_SERVER_LITELLM_THREAD_OK_2 ここまで来ると、「別VMにCodexを置いて、スマホから社員エージェントとして指示する」構成がかなり現実味を帯びてくる。 📌 まとめ Z. aiがCodexに使えない、という話ではなかった。 問題はモデル性能ではなく、Codex 0.135のResponses前提と、Z. ai Chat Completions側のtool schema差。 LiteLLMでResponses変換し、guardrailでtoolをfunctionに絞れば、最小実用のVM社員エージェント経路は作れる。 次は、 🔧 LiteLLM guardrailの常駐化 🔧 Codex App daemonのprovider固定 📱 モバイルUIから新規taskを作って同じmarkerで再検証 ここまで固めれば、Eclipse VM群をCodexモバイルから呼び出す“常駐社員エージェント”運用に進めそう。

Recently, we purchased one of each Anthropic/OpenAI subscription plan and randomly ran long horizon coding tasks until we exhausted the weekly limit. It's widely believed that a $200/month plan maxes out at ~$2000/month worth of tokens (assuming API pricing). However, we found that the subscriptions are actually far more generous. (2/4)