Skip to content

feat(ai): register unsloth as the universal model gateway provider - #1693

Merged
joelteply merged 1 commit into
canaryfrom
feat/unsloth-gateway-adapter
Jun 20, 2026
Merged

feat(ai): register unsloth as the universal model gateway provider#1693
joelteply merged 1 commit into
canaryfrom
feat/unsloth-gateway-adapter

Conversation

@joelteply

Copy link
Copy Markdown
Contributor

What

unsloth is a local OpenAI-compatible server (like docker-model-runner) that serves local models (llama.cpp) and fans out to cloud providers via the keys configured in unsloth Studio. So continuum reaches every model through one provider with one credential (UNSLOTH_API_KEY) — no new adapter, just a catalog entry + registration on the existing OpenAICompatibleAdapter. Pure compression.

  • model_registry/catalog.rs — add the unsloth provider (base_url http://127.0.0.1:8888/v1, auth: Bearer, api_key_env: UNSLOTH_API_KEY). Dynamic catalog: live model list from /v1/models (empty prefixes, runtime discovery), exactly like the DMR precedent.
  • modules/ai_provider.rs — register the unsloth adapter when UNSLOTH_API_KEY is set (key-gated, same pattern as the cloud providers). Additive priority for now; making the gateway the preferred route is a separate routing-policy change.

Live-validated (the "before it's too late" bit)

tests/unsloth_gateway_live.rs (skip-if-not-configured/unreachable) builds the same adapter the core builds, reads the key from ~/.continuum/config.env, and authenticates + fetches the live /v1/models catalog against a running Studio:

✓ unsloth gateway live: provider_id=unsloth, /v1/models returned 0 model(s)

0 models = none loaded in Studio yet; init succeeding proves real key + real bearer auth + real transport to the running gateway — the wiring unit tests (which mock dispatch) can't reach.

Validation

  • cargo check clean; model_registry unit tests 16/16 (no regression); live test passes against the running unsloth.

Follow-ups

See memory unsloth-universal-model-gateway.

🤖 Generated with Claude Code

unsloth is a local OpenAI-compatible server (like docker-model-runner): it
serves local models (llama.cpp) AND fans out to cloud providers via the keys
the user configures in unsloth Studio. So continuum reaches every model
through ONE provider with ONE credential (UNSLOTH_API_KEY) — no new adapter,
just a catalog entry + registration on the existing OpenAICompatibleAdapter.

- model_registry/catalog.rs: add the `unsloth` provider (base_url
  http://127.0.0.1:8888/v1, auth Bearer, api_key_env UNSLOTH_API_KEY). Dynamic
  catalog — the live model list comes from /v1/models (empty model_prefixes,
  runtime discovery), exactly like the DMR precedent.
- modules/ai_provider.rs: register the unsloth adapter when UNSLOTH_API_KEY is
  configured (key-gated, same pattern as the cloud providers). Additive
  priority for now; making the gateway the *preferred* route is a separate
  routing-policy change.

Live-validated end-to-end against a running unsloth Studio (tests/
unsloth_gateway_live.rs, skip-if-not-configured/unreachable): builds the SAME
adapter the core builds, reads the key from ~/.continuum/config.env,
authenticates + fetches the live /v1/models catalog. Proves real key + real
bearer auth + real transport to the running gateway — the wiring unit tests
(which mock dispatch) can't cover.

  ✓ unsloth gateway live: provider_id=unsloth, /v1/models returned 0 model(s)
  (0 = no model loaded in Studio yet; init succeeding = auth + transport OK)

Part of the unsloth universal-model-gateway direction (#31). Follow-ups: make
it the preferred route + UNSLOTH_BASE_URL runtime override (#20), install
autowire (#33), close the genome loop (#32). See memory
unsloth-universal-model-gateway.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@joelteply
joelteply merged commit 30209b2 into canary Jun 20, 2026
4 checks passed
@joelteply
joelteply deleted the feat/unsloth-gateway-adapter branch June 20, 2026 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant