Lmstudio Cli

Name: Lmstudio Cli
Author: akillness

akillness/oh-my-skills

202 installs
40 repo stars
Updated August 4, 2026
akillness/oh-my-skills

Operate local models through LM Studio CLI—load checkpoints, run completions, and wire offline inference into agent or scripting workflows on developer machines.

About

Documents LM Studio command-line usage for local LLM development: install tooling, load models, invoke completions, configure endpoints, and embed offline inference into agent prototypes and terminal-driven AI workflows.

LM Studio CLI install and model load commands
Local completion and chat invocation patterns
Environment and endpoint configuration for agents
Offline inference for privacy-sensitive prototypes
Scriptable hooks for batch evaluation runs

Lmstudio Cli by the numbers

202 all-time installs (skills.sh)
Ranked #202 of 550 CLI & Terminal skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/akillness/oh-my-skills --skill lmstudio-cli

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/akillness/oh-my-skills/lmstudio-cli.svg)](https://skillselion.com/skills/akillness/oh-my-skills/lmstudio-cli)

Installs	202
repo stars	★ 40
Last updated	August 4, 2026
Repository	akillness/oh-my-skills ↗

What it does

Operate local models through LM Studio CLI—load checkpoints, run completions, and wire offline inference into agent or scripting workflows on developer machines.

Files

SKILL.mdMarkdownGitHub ↗

LM Studio CLI

Use this skill when the real job is operating LM Studio itself: confirming whether lms exists, checking whether a local or remote LM Studio server is actually running, discovering exact model IDs, deciding whether the OpenAI-compatible endpoints are enough, and wiring a downstream tool to the correct base URL and model identifier.

Do not use this as a generic local-LLM comparison skill. Route broad provider comparison or platform selection to research/survey work. Route downstream-tool-specific scanning or appsec operation to that tool's skill (for example strix) once LM Studio itself is verified.

When to use this skill

A user mentions LM Studio, lms, or an LM Studio server directly
You need to verify whether LM Studio is running locally or on another authorized host
You need the exact model IDs returned by /v1/models before wiring another tool
You need to choose between LM Studio's OpenAI-compatible endpoints and its native REST API
You need to load, inspect, or confirm models before an agent or CLI can use them
A downstream tool works with OpenAI-compatible endpoints, but the user needs LM Studio-specific setup help
A remote/headless LM Studio workflow is failing and you need a deterministic verification path

Instructions

Step 1: Identify the operating mode

Classify the request before touching commands:

1. Local native CLI mode — the machine should have LM Studio installed and lms available 2. Remote HTTP mode — you only need to test or consume an authorized LM Studio endpoint 3. LM Studio-native management mode — the user needs model loading / listing / unload behavior that goes beyond generic OpenAI-compatible calls 4. Downstream wiring mode — the user already has LM Studio running and needs to point another tool at it

Use the smallest mode that answers the request.

Step 2: Check whether local `lms` exists

If local CLI operation is expected, verify it first:

command -v lms
lms --help

If lms is missing, do not hallucinate local CLI output. Continue with remote HTTP verification only if the host/endpoint is explicitly authorized.

Step 3: Verify server status or endpoint reachability

For local native checks:

lms server status
lms server status --json --quiet

For a remote or client-style smoke test:

curl -fsS http://HOST:PORT/v1/models

Optional minimal response test:

curl -fsS http://HOST:PORT/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_ID",
    "messages": [{"role": "user", "content": "reply with exactly OK"}],
    "temperature": 0,
    "max_tokens": 8
  }'

If you want a reusable parser instead of copy-pasting curl, use python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1.

Step 4: Discover exact model identifiers

Do not guess model names.

Use one of these:

lms ls
lms ls --llm
lms ps --json
curl -fsS http://HOST:PORT/v1/models

If the user needs the exact loaded instance or runtime state, prefer lms ps or the native REST API over a generic downstream client view.

Step 5: Escalate to LM Studio-native management only when needed

Use the native REST API or LM Studio-native commands when OpenAI compatibility is not enough:

curl -fsS http://HOST:PORT/api/v1/models
curl -fsS http://HOST:PORT/api/v1/models/load \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_KEY",
    "context_length": 262144,
    "echo_load_config": true
  }'

And locally:

lms load MODEL_KEY --identifier my-model
lms ps --json

Use this path for context-length, load-state, or instance-specific questions. Do not treat every integration problem as a native-management problem if /v1/models and /v1/chat/completions already answer the user's need.

Step 6: Wire downstream tools carefully

For tools that expect an OpenAI-compatible server, pass the exact model ID and base URL:

export LLM_API_BASE="http://HOST:PORT/v1"
export STRIX_LLM="openai/MODEL_ID"

Some OpenAI-compatible clients still insist on an API key field even when LM Studio itself does not need a real provider key. When that happens, set the client-required dummy key only in the downstream tool's config, not as a claim about LM Studio authentication.

Step 7: Report the operating facts, not guesses

A good final report should include:

whether lms was present locally
whether the server was verified locally, remotely, or both
exact base URL tested
exact model IDs discovered
whether the user needed OpenAI-compatible calls only or LM Studio-native management
the final env/config snippet or command needed by the downstream tool

Examples

Example 1: Local machine with LM Studio installed

User asks: "Is lms installed and what model is loaded?"

Recommended flow:

command -v lms
lms server status --json --quiet
lms ps --json

Example 2: Remote LM Studio host for another tool

User asks: "Point Strix at my LM Studio box."

Recommended flow:

curl -fsS http://HOST:PORT/v1/models
python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1
export STRIX_LLM="openai/MODEL_ID"
export LLM_API_BASE="http://HOST:PORT/v1"

Example 3: Need more than OpenAI-compatible smoke tests

User asks: "Load the model with a bigger context length and tell me the effective settings."

Recommended flow:

curl -fsS http://HOST:PORT/api/v1/models
curl -fsS http://HOST:PORT/api/v1/models/load \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_KEY","context_length":262144,"echo_load_config":true}'

Example 4: Headless failure triage

User asks: "lms server start broke on my Linux VM. What should I check first?"

Recommended flow:

verify lms --help
run lms server status --json --quiet
rerun with verbose logging if needed
separate local daemon/server failure from downstream OpenAI-client failure before editing configs

Best practices

1. Separate local CLI availability from remote HTTP reachability; they are related but not the same fact. 2. Use the exact model IDs returned by LM Studio instead of shortening names by hand. 3. Prefer the OpenAI-compatible endpoints for downstream-tool wiring, and the native REST/CLI surfaces for model-management questions. 4. When a downstream client insists on an API key field, describe it as a client compatibility quirk rather than an LM Studio requirement. 5. Treat remote private-network hosts as sensitive; only probe endpoints the user has authorized. 6. Escalate to load-state or context-length guidance only when the simpler /v1/models path is not enough. 7. Keep the boundary clear: lmstudio-cli verifies and configures LM Studio itself; downstream-tool skills own what happens after the endpoint is working.

References

references/cli-and-server-basics.md
references/endpoints-and-escalation.md
references/downstream-tool-wiring.md
scripts/check_lmstudio_endpoint.py
LM Studio CLI docs
LM Studio OpenAI compatibility docs
LM Studio REST API docs

{
  "skill_name": "lmstudio-cli",
  "evals": [
    {
      "id": 1,
      "prompt": "My teammate says our LM Studio box is up. Verify the endpoint and tell me which exact model ID to use before I point another OpenAI-compatible client at it.",
      "expected_output": "The skill chooses endpoint verification, checks `/v1/models`, reports exact model IDs, and avoids guessing names.",
      "assertions": [
        "Uses endpoint verification before downstream-tool configuration",
        "Requires exact model IDs from LM Studio instead of guessed aliases",
        "Keeps the job scoped to LM Studio verification rather than generic provider comparison"
      ]
    },
    {
      "id": 2,
      "prompt": "I installed LM Studio locally. Can you check whether `lms` exists and whether the local server is running in a machine-readable way?",
      "expected_output": "The skill checks `command -v lms`, uses `lms --help`, and reaches for `lms server status --json --quiet`.",
      "assertions": [
        "Verifies CLI existence before assuming local control",
        "Uses `lms server status --json --quiet` for machine-readable local status",
        "Separates local CLI availability from remote HTTP mode"
      ]
    },
    {
      "id": 3,
      "prompt": "The OpenAI-compatible endpoint works, but I need to load the model with a larger context length and confirm the effective config. What path should I use?",
      "expected_output": "The skill routes from the OpenAI-compatible smoke-test path to LM Studio-native REST or CLI model-management guidance.",
      "assertions": [
        "Escalates to native REST or `lms load` for model-management questions",
        "Explains why `/v1/models` alone is insufficient for context-length / load-state work",
        "Preserves the boundary between compatibility wiring and native management"
      ]
    }
  ]
}

CLI and Server Basics for LM Studio

What upstream documents clearly

lms ships with LM Studio itself; if LM Studio is installed, start with lms --help.
The CLI docs expose separate command families for local models, server control, daemon control, LM Link, runtime management, and publishing.
lms server status is the first deterministic check for local server state, and --json --quiet gives machine-readable output.

Primary sources:

https://lmstudio.ai/docs/cli
https://lmstudio.ai/docs/cli/serve/server-status

Minimal verification ladder

1. command -v lms 2. lms --help 3. lms server status --json --quiet 4. lms ps --json or lms ls --llm

If step 1 fails, stop pretending you have local CLI control and switch to remote endpoint verification only when the host is authorized.

Why this matters

A lot of user confusion comes from mixing three separate questions:

is the LM Studio app/CLI installed here?
is the local server running?
does another machine expose an endpoint I can call?

The skill should force those apart instead of treating them as one opaque "LM Studio is broken" problem.

Useful commands

command -v lms
lms --help
lms server status
lms server status --json --quiet
lms ls --llm
lms ps --json

Failure notes from upstream issue traffic

The upstream issue tracker still shows friction around server-mode onboarding and headless startup, so first-pass troubleshooting should stay boring and deterministic rather than jumping straight to downstream-client config:

server-mode setup can feel overwhelming for new users — https://github.com/lmstudio-ai/lms/issues/196
headless Linux startup can fail in ways that look like stale local state — https://github.com/lmstudio-ai/lms/issues/210

Downstream Tool Wiring

Core handoff pattern

For downstream tools that already speak OpenAI-style APIs, the handoff usually boils down to:

1. verify the LM Studio endpoint, 2. capture the exact model ID, 3. set the downstream tool's base URL to LM Studio, 4. pass the model under the tool's provider namespace or model-format expectation.

The skill should not skip step 2. Guessing model IDs is one of the fastest ways to turn an LM Studio problem into a fake downstream-tool problem.

Safe handoff example

curl -fsS http://HOST:PORT/v1/models
python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1

Then configure the downstream tool with the exact model ID:

export LLM_API_BASE="http://HOST:PORT/v1"
export STRIX_LLM="openai/MODEL_ID"

Client-compatibility quirks

LM Studio itself does not require a real provider API key for local inference, but some OpenAI-compatible clients still expect an API key field to exist.

Guidance:

call this a client compatibility requirement, not an LM Studio authentication requirement
put the placeholder only in the downstream tool's config if needed
avoid rewriting unrelated global provider config unless the user asked for that scope

Boundary rule

lmstudio-cli owns: endpoint verification, model discovery, native-vs-compatible routing, and final LM Studio connection facts
downstream-tool skills own: their own scan modes, CI wrappers, output interpretation, or tool-specific operational behavior once LM Studio is confirmed working

Comparison note

It is normal for users to compare LM Studio against Ollama, LocalAI, or llama.cpp server while debugging local inference. That comparison can help orientation, but it should not dilute this skill into a generic local-LLM chooser. Keep the skill anchored on LM Studio-specific operator work.

Endpoints and Escalation

Two surfaces to keep separate

1. OpenAI-compatible endpoints

Use this when the goal is client compatibility.

Documented upstream endpoints include:

GET /v1/models
POST /v1/responses
POST /v1/chat/completions
POST /v1/embeddings
POST /v1/completions

Primary source: https://lmstudio.ai/docs/developer/openai-compat

This path is best when you only need to:

verify a base URL
list model IDs
send a small chat smoke test
point an existing OpenAI client at LM Studio

2. Native LM Studio REST API

Use this when the goal is LM Studio-specific model management.

Primary source: https://lmstudio.ai/docs/developer/rest

This path is best when you need to:

inspect LM Studio-managed models directly
load or unload a model
reason about context length or effective load config
understand behavior that a generic OpenAI client will not expose

Escalation rule

Start with the OpenAI-compatible path unless the user explicitly needs model-management details.

Escalate to native REST/CLI when:

model loading is the real task
context length is the blocker
a loaded instance / identifier matters
the downstream client works, but the wrong model or load config is active

Example commands

# Compatibility path
curl -fsS http://HOST:PORT/v1/models
curl -fsS http://HOST:PORT/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_ID","messages":[{"role":"user","content":"reply with exactly OK"}],"temperature":0,"max_tokens":8}'

# Native management path
curl -fsS http://HOST:PORT/api/v1/models
curl -fsS http://HOST:PORT/api/v1/models/load \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_KEY","context_length":262144,"echo_load_config":true}'

Why the distinction matters

Upstream issue traffic shows that context-length and load-guardrail questions remain active pain points, especially in headless or remote setups:

max-context flag request — https://github.com/lmstudio-ai/lms/issues/118
missing CLI/REST equivalent for GUI "Load anyway" — https://github.com/lmstudio-ai/lms/issues/499

#!/usr/bin/env python3
"""Lightweight LM Studio endpoint checker.

Uses stdlib only. Verifies a base URL that points at LM Studio's OpenAI-compatible
surface (usually http://HOST:PORT/v1), lists model IDs, and optionally runs a
small chat/completions smoke test.
"""

from __future__ import annotations

import argparse
import json
import ssl
import sys
import urllib.error
import urllib.parse
import urllib.request
from typing import Any


DEFAULT_HEADERS = {
    "User-Agent": "Mozilla/5.0",
    "Accept": "application/json",
}


class CheckError(RuntimeError):
    pass


ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE


def request_json(url: str, method: str = "GET", payload: dict[str, Any] | None = None) -> Any:
    data = None
    headers = dict(DEFAULT_HEADERS)
    if payload is not None:
        data = json.dumps(payload).encode("utf-8")
        headers["Content-Type"] = "application/json"
    req = urllib.request.Request(url, data=data, headers=headers, method=method)
    try:
        with urllib.request.urlopen(req, timeout=20, context=ctx) as resp:
            return json.loads(resp.read().decode("utf-8", "ignore"))
    except urllib.error.HTTPError as exc:  # pragma: no cover - simple CLI helper
        body = exc.read().decode("utf-8", "ignore")
        raise CheckError(f"HTTP {exc.code} for {url}: {body[:300]}") from exc
    except urllib.error.URLError as exc:  # pragma: no cover - simple CLI helper
        raise CheckError(f"Connection error for {url}: {exc}") from exc
    except json.JSONDecodeError as exc:  # pragma: no cover - simple CLI helper
        raise CheckError(f"Non-JSON response from {url}: {exc}") from exc


def normalize_base_url(raw: str) -> str:
    raw = raw.rstrip("/")
    if raw.endswith("/v1"):
        return raw
    return raw + "/v1"


def pick_model_id(models_payload: Any) -> str | None:
    if not isinstance(models_payload, dict):
        return None
    data = models_payload.get("data")
    if not isinstance(data, list):
        return None
    for item in data:
        if isinstance(item, dict) and isinstance(item.get("id"), str):
            return item["id"]
    return None


def main() -> int:
    parser = argparse.ArgumentParser(description="Check an LM Studio OpenAI-compatible endpoint")
    parser.add_argument("--base-url", required=True, help="Base URL, usually http://HOST:PORT/v1 or http://HOST:PORT")
    parser.add_argument("--smoke-test", action="store_true", help="Also send a tiny chat completion using the first discovered model")
    args = parser.parse_args()

    base_url = normalize_base_url(args.base_url)
    models_url = base_url + "/models"
    models_payload = request_json(models_url)
    model_id = pick_model_id(models_payload)

    result: dict[str, Any] = {
        "base_url": base_url,
        "models_url": models_url,
        "model_count": len(models_payload.get("data", [])) if isinstance(models_payload, dict) else None,
        "model_ids": [item.get("id") for item in models_payload.get("data", []) if isinstance(item, dict)] if isinstance(models_payload, dict) else [],
    }

    if args.smoke_test:
        if not model_id:
            raise CheckError("No model IDs returned from /v1/models; cannot run smoke test")
        payload = {
            "model": model_id,
            "messages": [{"role": "user", "content": "reply with exactly OK"}],
            "temperature": 0,
            "max_tokens": 8,
        }
        chat_payload = request_json(base_url + "/chat/completions", method="POST", payload=payload)
        result["smoke_test_model"] = model_id
        result["smoke_test_response"] = chat_payload

    print(json.dumps(result, indent=2))
    return 0


if __name__ == "__main__":
    try:
        raise SystemExit(main())
    except CheckError as exc:
        print(json.dumps({"error": str(exc)}), file=sys.stderr)
        raise SystemExit(1)

N:lmstudio-cli
D:Operate LM Studio's lms CLI and local or remote LM Studio servers for model discovery, server status checks, model loading, endpoint smoke tests, and downstream OpenAI-compatible wiring. Use when the user mentions LM Studio, lms, a local model server, /v1/models, a remote LM Studio host, or connecting another tool to LM Studio.
G:lmstudio lm-studio lms local-llm openai-compatible model-server inference local-inference endpoint-validation strix

S[7]{n,action,details}:
  1,Identify the operating mode,Choose between local native CLI mode remote HTTP mode LM Studio-native management mode and downstream wiring mode before issuing commands.
  2,Check whether local lms exists,bash command -v lms && lms --help If lms is missing switch to remote HTTP verification instead of inventing local CLI output.
  3,Verify server status or endpoint reachability,bash lms server status --json --quiet or curl -fsS http://HOST:PORT/v1/models Optional helper: python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1
  4,Discover exact model identifiers,bash lms ls --llm lms ps --json or curl -fsS http://HOST:PORT/v1/models Do not guess model IDs.
  5,Escalate to native management only when needed,bash curl -fsS http://HOST:PORT/api/v1/models and curl -fsS http://HOST:PORT/api/v1/models/load ... or lms load MODEL_KEY --identifier my-model for context length load state or instance-specific questions.
  6,Wire downstream tools carefully,Use the exact model ID and base URL. Example: export LLM_API_BASE="http://HOST:PORT/v1" and export STRIX_LLM="openai/MODEL_ID"
  7,Report operating facts,Include whether lms existed which base URL was tested which model IDs were found whether the job stayed in OpenAI-compatible mode or required native management and the final config snippet needed downstream.