Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

feat(core): discover Unsloth Studio models (local runtime — like Ollama, LM Studio, vLLM)

オープン 初心者向け
  • 何か問題がありますか？
#59,557 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
61/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
backend

調査の方向性

packages/core/src/plugin/provider/local.ts と packages/core/src/plugin/provider/vllm.ts を読んでローカル検出のパターンを確認し、登録について packages/core/src/plugin/provider.ts を調べてください。Unsloth の認証付き /v1/models エンドポイントの検出を実装し、返されたモデルが表示され、同期された状態を保つことを確認してください。Issue では検証用のライブサーバーが提供されていますが、テストファイルは指定されていません。

索引モデルが issue の本文から書いたものです。

説明

Summary

Unsloth Studio is a local model runtime that exposes an OpenAI-compatible API on localhost (default port 8888, backed by llama-server). Its model inventory is per-machine and changes at runtime — it's whatever the user has downloaded/loaded in the app. That puts it in the same class as Ollama, LM Studio and vLLM, which opencode serves with in-repo runtime discovery plugins built on createLocalProviderPlugin (packages/core/src/plugin/provider/local.ts).

Request: add packages/core/src/plugin/provider/unsloth.ts following the same pattern, so discovered Unsloth models appear (and stay in sync) without hand-encoding every model in opencode.json.

Why the models.dev routing doesn't cover this

I understand new providers are normally added to models.dev rather than this repo. But a static catalog structurally cannot represent a runtime-local inventory:

  • vllm and ollama (local) have no models.dev entry at all — they exist purely as discovery plugins (#43022, #43021).
  • lmstudio has a catalog entry, but with 3 placeholder models; the real functionality comes from its discovery plugin (#42607).
  • Catalog entries work for vendor-defined model sets (that's why ollama-cloud is cataloged). Unsloth Studio's model set is machine-defined, like the three runtimes above.

The precedent is well established: three separate discovery feature PRs plus a dedicated refactor to share the machinery (#53438).

Relation to #46975

#46975 asked for a "native provider" (the /connect flow entry) and was closed pointing at models.dev — a fair answer to that ask. This request is different: runtime model discovery, which no catalog entry can provide. Nobody has asked for that part yet, hence this issue.

API surface (verified live against a running Unsloth Studio)

GET /v1/models requires Authorization: Bearer sk-unsloth-… and returns an OpenAI-style list with a few extra fields:

{
  "object": "list",
  "data": [
    {
      "id": "unsloth/LFM2.5-24B-A2B-GGUF",
      "object": "model",
      "created": 1793091398,
      "owned_by": "unsloth-studio",
      "loaded": false,
      "quant": "UD-IQ3_XXS",
      "display_name": "LFM2.5-24B-A2B-GGUF",
      "status": { "value": "unloaded" }
    }
  ]
}
  • owned_by is always "unsloth-studio", so filtering like vLLM's plugin does is trivial.
  • display_name + quant map naturally to the model display name (e.g. LFM2.5-24B-A2B (UD-IQ3_XXS)).
  • loaded distinguishes in-memory vs. downloaded models (could be surfaced or used for ordering).
  • GET /v1/models/{id} returns the same shape — no context-length metadata, so discovery can't populate limit.context (same gap tracked in #40908; tool/vision capabilities are also not reported, so conservative defaults like vLLM's plugin would apply, overridable via config).
  • Unlike Ollama/LM Studio, auth is mandatory — but createLocalProviderPlugin already folds apiKey from config settings ({env:}/{file:} substitution included), which is exactly what unsloth start opencode already writes today. Default origin would be http://127.0.0.1:8888 (Unsloth's own opencode integration docs standardize on 8888; the API docs say "typically 8000 or 8888").
  • The default stripPathSuffix: /\/v1$/ already handles the documented base URL form http://localhost:8888/v1.
Concrete pain today

Custom-provider users must hand-maintain every model in opencode.json. Right now my local Unsloth server lists 9 models while my config encodes 8 — I downloaded ggml-org/Kev-9B-GGUF after writing the config, and it silently doesn't exist for opencode until I edit JSON by hand. With discovery it would just appear, same as it does for Ollama.

Worth noting Unsloth actively maintains an opencode integration (unsloth start opencode, dedicated docs page) — they're an invested partner here, and I'd be glad to loop them in.

Happy to contribute

I have a live server to test against and would send a PR following the vllm.ts template (one ~40-line plugin file + registration in packages/core/src/plugin/provider.ts), reusing the existing factory so no new framework code paths are added. Related open work in this area: #54011. If maintainers would rather see this land via a models.dev entry plus custom-provider config, I'd still argue the discovery plugin is the piece that makes local Unsloth usable without manual JSON — but happy to follow whatever direction you prefer.

主要言語
TypeScript
スター
221k
フォーク
29.6k
平均マージ
5時間 32分
マージ済み PR（30日）
492

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

anomalyco/opencode のほかの issue

anomalyco/opencode の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。