Buda vs Crush：端末設定とチームの成果物、誰が責任を持つか
Charm の Crush は端末のコーディング Agent です。現行 README は、コンテキストを保ったモデル切り替え、プロジェクトのセッション、LSP、MCP を明記しています。代替を選ぶとき、これらの能力がないと決めつける比較は役に立ちません。
Buda との違いは、リポジトリから営業やサポートに仕事が移ったとき、環境、資料、成果の責任をどう分けるかです。コードの品質ランキングではなく、運用の担当者を選ぶ判断です。
設定の自由は運用責任を伴う
Crush は多くのプロバイダーと互換 API、ローカルモデルの設定を扱います。LSP がコード情報を加え、MCP は stdio、HTTP、SSE でツールを拡張します。既存の道具を組み合わせたい開発者には、この自由が利点です。
現行の crushrc は shell ベースで、プロジェクトと全体の設定を分けます。README は設定を信頼されたコードとして扱うよう警告します。未知のリポジトリで起動する前に設定、秘密情報の展開、許可ツールを確認してください。個人の成功した設定は、そのままチームの安全基準にはなりません。
共有 backend の連続性を正しく評価する
共有 backend では作業ディレクトリでクライアントをまとめ、セッション、メッセージ、権限キュー、LSP、MCP 状態を共有します。新しい起動は既定で新セッションになり、過去のセッションは選択できます。コンテキストがないという批判は不正確です。
誰が backend を運用し、誰が接続でき、誰が設定を決めるかを試験します。最初のクライアントが yolo や debug のプロセス設定を固定するという説明もあります。ディレクトリ単位の共有が組織の役割に合うかが検討点です。
成果物がリポジトリを離れる場面を見る
承認済み変更から顧客説明、サポート手順、研修資料を作るとします。同じ diff を参照しても、資料と受け入れ担当者は違います。開発者が全部生成できることと、全部の資料を運用すべきことは別です。
Buda は Agent ごとに持続するクラウド環境を提供し、ファイル、端末、ブラウザー、Git を見せます。業務担当が自分の資料とレビューを保持できます。ただし Crush との組み込み連携を証明するものではありません。承認済み diff、制約、出典、次の検査条件を明示して渡します。
環境維持とレビューを別々に測る
端末ではプロバイダー、モデル、LSP、MCP 認証、設定確認、権限挙動を記録し、小さなコード変更の diff とテストを調べます。管理型環境では資料の保持、作業の継続、実行の可視性、担当者が成果の根拠を探せるかを試します。
token 単価だけでは費用を比較できません。モデル利用、契約、環境運用、設定、人の修正を分けます。固定の安さや機能の同等性をこの比較から断定しないでください。
設定が強みなら端末を残す
成熟した開発環境を、画面を統一するためだけに置き換える必要はありません。コードは既存環境で、反復する業務成果物は別のワークスペースで試せます。見栄えのために権限を広げないことが重要です。
Buda の試験では承認済み変更を渡し、出典つき顧客説明、未確定事項、レビュー条件を出力させます。繰り返すなら Buda AI の Marketplace で適した Skill を検索・インストールします。互換性の宣言ではなく、担当者が受け入れられる成果で判断します。
よくある質問
MCP とモデル切り替えはありますか？
はい。README が MCP 方式とコンテキストを保つ切り替えを説明しています。
作業を共有できますか？
共有 backend がディレクトリ単位で状態をまとめます。アクセスと運用を検証してください。
Crush 設定を自動インポートできますか？
参照資料はその互換性を証明していません。成果と指示を明示的に渡してください。
最初に何を試しますか？
コード環境の維持と、業務成果の受け渡しのどちらが課題かを決め、対応する工程を試します。