Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#59,557 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
61/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend

Hướng nghiên cứu

Đọc packages/core/src/plugin/provider/local.ts và packages/core/src/plugin/provider/vllm.ts để làm theo mẫu phát hiện cục bộ; kiểm tra packages/core/src/plugin/provider.ts để xem cách đăng ký. Triển khai tính năng phát hiện cho endpoint /v1/models có xác thực của Unsloth, sau đó kiểm tra xem các model được trả về có xuất hiện và luôn đồng bộ hay không. Issue cung cấp một máy chủ trực tiếp để xác minh nhưng không nêu tên tệp kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
221k
Fork
29.6k
Merge trung bình
5 giờ 32 phút
Pull request đã merge (30 ngày)
492

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của anomalyco/opencode

Tất cả issue của anomalyco/opencode

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.