1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

gooseに繋いだ自前モデル、1Mコンテキストが128kに切り詰められた話

1
Posted at

はじめに

Block社が開発しLinux FoundationのAgentic AI Foundation（AAIF）に寄贈されたオープンソースAIエージェント「goose」は、51,000以上のGitHubスターを持つRust製CLI/デスクトップツールです1。15以上のLLMプロバイダーに対応し、Model Context Protocol（MCP）経由で70以上の拡張機能と連携できる点が特徴です1。

GLM-5.2やMiniMax-M3のような、gooseの標準対応表に載っていない「カスタムモデル」をOpenAI互換プロキシ経由で接続すると、実際のモデルが100万トークンのコンテキストウィンドウを持っていても、gooseは一律で 128,000トークン として扱ってしまう不具合が2026年6月に報告されました2。この記事では、実際に報告された再現手順と、関連する複数のGitHub Issueを時系列で追いながら、根本原因と回避策を整理します。

この記事で学べること

  • gooseの「カスタムモデルは128kにフォールバックする」問題の再現条件と症状
  • なぜ一部は修正済みで一部は未修正なのか（Issue横断で見えた構造）
  • GOOSE_CONTEXT_LIMIT 環境変数と custom_providers JSON設定による回避策

前提環境

  • goose最新版: v1.41.0（2026年7月3日リリース）3
  • 問題が報告されたバージョン: v1.39.0
  • 対象: gooseの標準モデル表に存在しないカスタムモデル（OpenAI互換プロキシ・自己ホスト・OpenRouter経由のモデルなど）

TL;DR

  • gooseは接続先モデル名が内蔵の「カノニカルレジストリ」に一致しない場合、コンテキスト上限を 問答無用で128,000トークンに固定 する24
  • GLM-5.2（実際は1Mトークン）やDevstral-2512（実際は262,144トークン）のような大コンテキストモデルでこの上限に当たると、実容量よりはるかに早い段階で自動圧縮（コンパクション）が発動する25
  • 同種の報告は2025年12月の Issue #6185 から2026年6月の Issue #10058 まで半年以上にわたって出続けたが、現行の最新リリースv1.41.0（2026年7月3日）の3日後にあたる7月6日、根本原因を修正するPR #10165がマージされた6。ただしこの修正はまだ次期v1.42.0待ちで、v1.41.0を使っている限り今も128k固定のまま4
  • 回避策は GOOSE_CONTEXT_LIMIT 環境変数、または custom_providers ディレクトリのJSON設定に context_limit を明記する方法の2つ。ただしDesktop版は環境変数を素直に読まないため注意が必要27

背景・課題

gooseはセッション中のトークン使用量を監視し、モデルのコンテキスト上限に近づくと自動的に会話履歴を要約・圧縮する「Smart Context Management」機能を持っています8。この機能はモデルごとの正確なコンテキスト上限を把握していることが前提になっており、上限の判定を誤ると「まだ余裕があるのに圧縮が走る」「逆に上限を超えてAPIエラーになる」といった問題が起きます。

gooseはOpenAI・Anthropic・Google・Ollama・Azure・Bedrockなど主要プロバイダーのモデルについては内蔵の「カノニカルレジストリ」（既知モデル名とコンテキスト上限の対応表）を持っています。しかし、OpenAI互換のカスタムプロキシ経由で接続するモデルや、レジストリの更新が追いついていない新しいモデルは、この表に載っていません。

実際に報告された症状

2026年6月27日、ユーザーのyingdieyi氏がgoose v1.39.0（Desktop UI）で以下を報告しました2。

再現手順:

  1. opencode_go（OpenAI互換のカスタムプロキシ）経由でGLM-5.2・MiniMax-M3を接続する新規プロバイダーを設定
  2. Desktopで新規セッションを開始し、メッセージを送信
  3. トークン使用量インジケーターにカーソルを合わせる

症状:

  • 「利用可能トークン: 128,000」と表示される（実際のGLM-5.2は1Mトークン対応）
  • 自動圧縮が本来の800k付近ではなく、102k付近という早すぎるタイミングで発動する
  • 実際のコンテキストウィンドウをフル活用できない

この報告に対し、メンテナー側は当初「計画なし（no plans）」のステータスでIssueをクローズしていました2。

なぜ起きるのか — Issue横断で見えた構造

この問題は単発のバグではなく、gooseのコンテキスト上限解決ロジックに関する一連の報告の中に位置づけられます。時系列で並べると、直った層と直っていなかった層が見えてきます。

Issue 報告日 内容 ステータス
#3259 2025-07-06 自己ホストモデルのコンテキスト上限を環境変数で設定したいという要望 —
#6185 2025-12-19 Devstral-2512が実際は262,144トークン対応なのに128Kと表示される —
#7839 2026-03-12 config.yaml・GOOSE_PREDEFINED_MODELS の指定がカノニカルレジストリの200kデフォルトに上書きされてしまう優先順位バグ PR #7888で修正済み
#8835 2026-04-24 プロバイダーAPIが返すコンテキスト長情報が破棄され、ローカル/LiteLLM経由モデルが128kにフォールバックする PR #9303で修正済み（v1.36.0に反映）
#10058 2026-06-27 GLM-5.2・MiniMax-M3がDesktop UIで128kにフォールバック クローズ（当初は計画なし）
#10163 2026-07-01 /model-info エンドポイントが、カノニカルレジストリに未登録のモデルの実効コンテキスト上限を返さない（#10058含む3件の重複報告を統合） PR #10165で修正済み（v1.42.0で反映予定・未リリース）

#7839・#8835はそれぞれ個別のPRで既に修正されています。#7839は「GOOSE_CONTEXT_LIMIT が config.yaml 経由で読めない」「カノニカルレジストリがユーザー定義モデルより優先されてしまう」という優先順位の欠陥をPR #7888で修正9。#8835はLiteLLMプロキシ配下のローカル/カスタムモデルでプロバイダーAPIの応答が破棄される問題をPR #9303で修正し、v1.36.0で既に配布済みです10。

残っていた根っこの層が#10163でした。ここでは#10058を含む3件の重複報告が統合され、「GOOSE_CONTEXT_LIMIT（ユーザー上書き）→ カスタムプロバイダーのモデル別 context_limit → カノニカルレジストリ → ハードコード128,000」という明確な優先順位を確立する修正がPR #10165として2026年7月6日にマージされました6。このPRは次期v1.42.0での配布待ちで、記事執筆時点（2026年7月12日）の最新リリースは7月3日公開のv1.41.0のため、まだ修正は手元に届いていません。つまり今この記事を読んでいる時点でv1.41.0以前を使っているなら、依然として「未知のモデル名は128k」という挙動に遭遇します。

回避策（動くコード）

方法1: 環境変数（CLI向け）

goose公式ドキュメントには、コンテキスト上限関連の環境変数が3種類定義されています7。

# メインモデルのコンテキスト上限を上書き
export GOOSE_CONTEXT_LIMIT=1000000

# Ollamaリクエストの入力プロンプト上限を上書き（未指定ならGOOSE_CONTEXT_LIMITにフォールバック）
export GOOSE_INPUT_LIMIT=1000000

# プランナーモデル専用のコンテキスト上限を上書き
export GOOSE_PLANNER_CONTEXT_LIMIT=1000000

CLIではこれで正しい上限が反映されます。ただし Desktop版はこの環境変数を通常の起動経路では読み込みません。macOSでDesktop版に反映させたい場合は、アプリ起動前に以下でシステム全体の環境変数として登録し、Desktopアプリを再起動する必要があります2。

launchctl setenv GOOSE_CONTEXT_LIMIT 1000000

方法2: custom_providers JSON設定（モデルごとに固定したい場合）

複数モデルを使い分ける場合は、モデルごとに context_limit を明記できるカスタムプロバイダー定義ファイルを使う方が確実です。配置先は以下の通りです11。

  • macOS/Linux: ~/.config/goose/custom_providers/
  • Windows: %APPDATA%\Block\goose\config\custom_providers\ 
{
  "name": "opencode_go",
  "engine": "openai",
  "display_name": "OpenCode GO Proxy",
  "base_url": "https://your-proxy.example.com/v1",
  "models": [
    { "name": "glm-5.2", "context_limit": 1000000 },
    { "name": "minimax-m3", "context_limit": 1000000 }
  ]
}

context_limit はモデル単位で指定するため、レジストリの更新を待たずに正確な上限をgooseに伝えられます。

著者視点の発見ポイント

最初に#10058単体だけを読んだときは「メンテナーが no plans でクローズした、放置されたバグ報告」に見えました。しかし関連Issueをマージ日・PR番号まで遡って並べ直すと、実態はもっと動きのある話でした。#7839（優先順位バグ）はPR #7888で、#8835（プロバイダーAPI破棄）はPR #9303でそれぞれ既に個別修正済みで、最後に残っていた「レジストリ未登録モデルは128k固定」という核の挙動も、調べている最中の2026年7月6日にPR #10165としてマージされていました。つまりこの記事を書き始めた時点では「まだ直っていない」と見えたものが、裏取りを進める過程で「直った、ただしまだリリースされていない」に変わったことになります。GitHub Issueのクローズ状態は「直ったかどうか」の答えにはならず、紐づくPRのマージ日と、それが実際にどのリリースタグに含まれているか（あるいはまだ含まれていないか）まで確認して初めて「今このバージョンでどう動くか」が分かる、という当たり前だが見落としがちな点を再確認しました。

まとめ

  • gooseはv1.41.0（2026年7月3日リリース・記事執筆時点の最新版）まで、カノニカルレジストリに存在しないモデル名を128,000トークンとしてフォールバック扱いする
  • GLM-5.2（1M）やDevstral-2512（262,144）のような大コンテキストモデルでは、実容量よりはるかに早く自動圧縮が発動してしまう
  • 関連する4件のIssue（#7839・#8835・#10058・#10163）のうち3件（#7839・#8835・#10163）は既に個別PRで修正済み。最後の核心部分（#10163）もPR #10165で2026年7月6日にマージされたが、次期v1.42.0待ちでまだリリースされていない
  • 回避策は GOOSE_CONTEXT_LIMIT 環境変数（CLI向け）または custom_providers JSON設定の context_limit フィールド（モデル別に固定したい場合）
  • Desktop版は環境変数を素直に読まないため、macOSでは launchctl setenv が必要になる点に注意

v1.42.0がリリースされれば本記事の回避策は不要になる可能性がありますが、それまでカスタムモデルやセルフホストモデルをgooseに繋ぐ場合は、トークン使用量インジケーターの表示を鵜呑みにせず、接続直後に一度 custom_providers 設定で context_limit を明示しておくのが安全です。

参考リンク

  1. GitHub - block/goose — スター数・機能概要の引用元 ↩ ↩2

  2. Context limit defaults to 128k for custom models (GLM-5.2, MiniMax-M3, etc.) · Issue #10058 — 再現手順・症状・クローズステータスの引用元 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Releases · block/goose — v1.41.0リリース日の引用元 ↩

  4. /model-info does not return the effective context limit for models without a canonical registry entry · Issue #10163 — エンドポイントの挙動・PR #10165での修正・v1.42.0待ちである旨の引用元 ↩ ↩2

  5. Devstral models show incorrect context length (128K instead of 262K) · Issue #6185 — Devstralの実コンテキスト長の引用元 ↩

  6. PR #10165: fix context limit resolution — マージ日（2026-07-06）・優先順位ロジック・v1.42.0対象である旨の引用元 ↩ ↩2

  7. Environment Variables | goose docs — GOOSE_CONTEXT_LIMIT 等の公式ドキュメント ↩ ↩2

  8. Smart Context Management | goose docs — 自動圧縮機能の説明の引用元 ↩

  9. Context limit resolution ignores GOOSE_PREDEFINED_MODELS and config.yaml · Issue #7839 — 優先順位バグとPR #7888での修正の引用元 ↩

  10. PR #9303: Fix LiteLLM Context Limit for Custom Models — マージ日（2026-05-22）・v1.36.0反映の引用元 ↩

  11. Configure LLM Provider | goose docs — custom_providers の配置先・JSON形式の引用元 ↩

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?