AIにコードを書かせている人へ。正体不明の宇宙うさぎが、100万トークンの作業机を無料で開放しています。
名前は Space Bunny Alpha。
OpenRouterのモデルページでは、入力・出力ともに無料。2026年9月23日に公開され、100万トークンのコンテキスト、画像・動画入力、推論の強さの調整に対応するモデルとして紹介されています。
そして、そのページには終了予定も出ています。
Going away October 5, 2026.
かわいい名前の新モデルをブックマークして、週末に触ろうと思っていたら、そのまま消えるかもしれません。
本記事は2026年10月2日時点の公開情報に基づきます。10月5日の終了表示はOpenRouter上のものです。他サービスの終了時刻や、その後の正式公開を意味しません。本記事ではモデルの推論性能を実測していません。
Space Bunny Alphaの長いコンテキストと期間限定プレビューを表現したAI生成イラスト。公式キャラクターや実験結果ではありません。
結論から言うと
Space Bunny Alphaを試すなら、公開してよいコードで、普段のAIが手を焼く変更を一つ渡すのが面白いです。
単発の質問で「賢そう」と感じるより、呼び出し元、実装、テスト、仕様の食い違いを同時に読ませる。修正案を出させて、こちらのテストで確かめる。
大きな作業机を渡したとき、変更のつながりを最後まで追えるか。
これが、今回おすすめする試し方です。
提供元の正体は、OpenRouterの掲載情報では匿名の第三者です。「次のMiniMaxなのか」「実はClaudeなのか」という推測を、この記事で確定情報に変えることはできません。まず触れるべきなのは、現在公開されているインターフェースです。
このうさぎ、チャット欄だけに閉じ込めるには惜しい
Space Bunny Alphaの公開仕様には、function calling用の tools と tool_choice が含まれます。画像と動画を入力し、返すのはテキスト。response_format によるJSON出力にも対応しますが、JSON Schemaの強制はありません。
ここから考えられる使い方は、文章の生成だけではありません。
たとえばUIの修正。スクリーンショットだけを見せると、モデルは見た目を説明できます。関連するコンポーネントも見せれば、見た目と実装を対応づける課題になります。さらにテスト結果を返せば、最初の提案を修正する課題になります。
これは実測結果ではなく、公開インターフェースから組み立てた検証案です。ただ、何を試せばよいかは、かなり具体的になります。
| 渡すもの | 確かめたいこと |
|---|---|
| 公開可能なUIのスクリーンショットと関連コード | 画面の問題を、実際の変更箇所に結びつけられるか |
| 呼び出し元・実装・既存テスト | 一つの修正で別の利用箇所を壊さないか |
| 失敗したテストのログ | 自分の仮説を修正して、次の差分を出せるか |
「この画面をいい感じにして」から一段進んで、画面、コード、検証結果を往復させる。
宇宙うさぎに頼みたいのは、かわいい返事より、ここです。
エージェントになる瞬間は、ツールの結果が戻ったとき
ただし、tools 対応という文字を見て、モデル自体がローカルのファイルを編集すると考えると、仕組みを取り違えます。
OpenRouterのツール呼び出しの説明では、モデルは使いたい関数と引数を返し、クライアント側が実行し、その結果をモデルに渡します。
コード修正の流れに置き換えると、こうです。
利用者: この失敗するテストを直して
↓
モデル: 関連ファイルを読むツールを要求
↓
クライアント: ファイルを読み、結果を返す
↓
モデル: 修正を提案し、テスト実行を要求
↓
クライアント: 許可された操作を実行し、結果を返す
↓
モデル: 結果を踏まえて続行、または完了
この図は説明用です。Space Bunny Alphaでこの課題を実行した記録ではありません。
注目したいのは、最後の往復です。
一発で正解を書く力だけなら、最初の生成で評価できます。しかし開発では、テストが落ちたり、想定と違うファイルが見つかったりします。そこで新しい情報を受け取り、手順を変えられるかが効いてきます。
クライアント側では、ツールを許可されたものに絞り、引数を検証し、実行結果を対応する tool_call_id とともに返す必要があります。モデルが要求したという理由だけで、任意のコマンドを実行する設計にはしません。
モデルを選ぶときは、最初の回答に加えて、失敗した後の二手目を見てください。
100万トークンを使うなら、まずファイルの境界を渡す
長いコンテキストを試すために、最初からリポジトリを全部貼る必要はありません。
私なら、次のような入力から始めます。以下は検証用のプロンプト案です。
目的:
既存の公開APIを維持しながら、以下の失敗を修正してください。
入力:
- 仕様
- 呼び出し元
- 実装
- 既存テスト
- 失敗ログ
各ファイルは「FILE: 相対パス」で区切ります。
最初に、関係するファイルと修正方針を示してください。
次に、変更が必要な箇所だけの差分を出してください。
入力にない関数やファイルが必要なら、存在を断定せず要求してください。
テストを実行していない場合は、実行済みと書かないでください。
ここで効くのは、容量に加えて入力の整理です。
たとえば同じ関数名が複数のファイルにある場合、ファイルの境界がなければ、どの実装を修正したのか分かりづらくなります。仕様と失敗ログが混ざっていれば、期待される動作と実際の動作も混ざります。
最初は関連ファイルだけで試す。次に別の呼び出し元を追加する。そこで提案がどう変わるかを見る。
この手順なら、長い入力を渡したことで拾えた依存関係が、差分として見えます。逆に関係のない変更が増えたなら、それも観察できます。
大きなコンテキストを、巨大な貼り付け欄で終わらせない。変更の範囲を広げても整合性を保てるか、段階的に試すわけです。
接続先は二つ。モデルIDを混ぜない
OpenRouter経由のIDは stealth/space-bunny-alpha です。公式QuickstartのHTTP形式に沿うと、最小の呼び出しは次のようになります。
以下は未実行の接続例です。OpenRouterのAPIキーを環境変数に設定し、利用時の提供状況・制限を確認してから実行してください。
curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "stealth/space-bunny-alpha",
"messages": [
{
"role": "user",
"content": "Pythonで空のリストを既定引数にした関数が、呼び出すたびに状態を共有する理由と修正例を説明してください。"
}
],
"max_tokens": 4096
}'
接続を確認したら、この質問を先ほどの公開可能なコード課題に差し替えます。最初の呼び出しは疎通確認。評価はそこからです。
OpenCodeを使っているなら、Zenの公式一覧に Space Bunny Free が掲載されています。Zen APIのIDは space-bunny-free。OpenCodeの設定で使う形式は opencode/space-bunny-free です。
| 経路 | モデルID |
|---|---|
| OpenRouter API | stealth/space-bunny-alpha |
| OpenCode Zen API | space-bunny-free |
| OpenCodeのモデル設定 | opencode/space-bunny-free |
OpenRouterのIDをそのままZen APIへ送るような混同は避けます。既に使っているクライアントの経路に合わせて選んでください。
推論の強さを上げると、回答の予算も使う
Space Bunny Alphaには推論の強さを調整するインターフェースがあります。そこで気になるのが、「とりあえず最大にすればよいのか」です。
OpenRouterのReasoning Tokensの説明では、多くのプロバイダーで推論トークンと利用者に見える回答が同じ max_tokens の予算を使います。推論だけで予算を使い切ると、回答本文が空のまま finish_reason: "length" になることがあります。
したがって、本文が空なら、まずHTTPエラーか、打ち切りかを分けます。finish_reason と usage を確認してから、出力上限や推論設定を調整します。この説明はOpenRouterの一般的な仕様であり、Space Bunny Alphaで空回答を再現したという報告ではありません。
調整例は次の形です。
{
"reasoning": {"effort": "medium"},
"max_tokens": 8192
}
これも未実行の例です。対応するeffort値は、利用時のモデルメタデータで確認してください。
比較するなら、同じ課題と同じ入力で設定を変えます。単純な説明問題に深い推論を付けるより、複数ファイルの修正で追加の思考が役立ったかを見るほうが、開発での使い分けにつながります。
同じうさぎでも、データの扱いは経路で違う
コードを渡す前に、一つだけ具体的な違いを押さえておきます。
OpenRouterの掲載説明は、プロンプトと回答を提供元が保持する可能性があり、学習には使わないとしています。一方、OpenCode ZenのData retentionの説明では、Space Bunny Freeの提供元はゼロ保持で、モデル学習に使わないとしています。
同じ愛称でも、経路ごとの説明を確認する必要があります。
OpenRouterのStealth利用条件も、匿名モデルの提供が期間限定であることや、提供元へ入力が渡ることを明記しています。
試す対象を公開可能なコードにするのは、このためです。長いコンテキストに渡すファイルを選ぶ段階で、秘密情報や顧客データを含めないようにします。
10月5日までに残すなら、うさぎの回答より検証できる差分
期間限定モデルを試して、チャット履歴だけが残る。それだと、次のモデルとの比較が難しくなります。
今回なら、次の四つを一緒に保存しておくと使い回せます。
- 入力したファイルと課題。
- 利用経路、モデルID、推論設定、実行日。
- 提案された差分と、自分で実行したテスト結果。
- 失敗ログを返した後に、何が修正されたか。
終了後に別のモデルへ同じ課題を渡せば、Space Bunny Alphaが拾えた依存関係、見落とした条件、必要だった修正が比較できます。
「すごかった」という感想に、再利用できる中身が生まれます。
無料期間に手に入れたいのは、自分の開発で任せられる仕事の具体例です。
宇宙うさぎが何者なのかは気になります。でも今、公開可能なコードで確かめられることはあります。
いつものモデルが迷う変更を一つ。失敗したテストも一つ。
その二手目まで見てから、「このうさぎ、使える」と言いたいところです。
試した方は、正体予想に加えて、どんな変更を任せて、どのテストまで通ったかも教えてください。その情報なら、次に触る人が課題を選べます。
参考資料
OpenRouter — Space Bunny Alpha
https://openrouter.ai/stealth/space-bunny-alpha
OpenRouter — Quickstart
https://openrouter.ai/docs/quickstart
OpenRouter — Client Tools / Tool Calling
https://openrouter.ai/docs/guides/features/tool-calling
OpenRouter — Reasoning Tokens
https://openrouter.ai/docs/guides/best-practices/reasoning-tokens
OpenRouter — Stealth Program End User License Agreement
https://openrouter.ai/terms/stealth
OpenCode — Zen
https://opencode.ai/docs/zen/