by llmmanorg
Run any agent on any model, models stored as OCI images
# Add to your Claude Code skills
git clone https://github.com/llmmanorg/llmmanLast scanned: 9/6/2026
{
"issues": [
{
"file": "README.md",
"line": 72,
"type": "remote-install",
"message": "Install command (remote install script piped to a shell — review the source before running): \"curl -fsSL https://llmmanorg.github.io/install.sh | sh\"",
"severity": "low"
}
],
"status": "PASSED",
"scannedAt": "2026-09-06T08:23:41.915Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}llmman is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by llmmanorg. Run any agent on any model, models stored as OCI images. It has 481 GitHub stars.
Yes. llmman passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/llmmanorg/llmman" and add it to your Claude Code skills directory (see the Installation section above).
llmman is primarily written in Rust. It is open-source under llmmanorg on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh llmman against similar tools.
No comments yet. Be the first to share your thoughts!
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
llmman launch claude --model qwen3.8
That starts a local inference server, downloads a llama.cpp build matching your
GPU, loads the model, and execs an agent against it.
Models are OCI images, so moving one takes no tooling you don't already have:
llmman transfer hf.co/unsloth/Qwen3.5-0.8B-GGUF docker.io/owner/model:latest
That copies from Hugging Face into your own registry directly, without a copy landing in your local store.
launch, run and list commands work
against a local model or any hosted provider (--provider baseten,
--provider groq, ...). One endpoint, one agent config, local or hosted.llmman run qwen3.8 pulls straight from Docker
Hub; llmman run hf.co/org/model pulls straight from Hugging Face. Or
package a model as a plain OCI artifact and push it to GHCR, quay, Harbor
or a self-hosted mirror, then llmman run it from there. No curated
library, no account with llmman, no gatekeeper.llama.cpp releases (or the
llama-server already on your PATH), vllm and mlx-lm as-is, serving
unmodified GGUF and safetensors files. No fork to wait on, no import step,
no private blob format: the store is a standard OCI Image Layout that all
can read.pull understands paired with any OCI
registry destination, optionally signed, without a copy in your local store.
That is the shape air-gapped and compliance-bound environments need.llmman serve daemons form an
aggregation: name the others, and a request to any of
them runs on whichever node has the model loaded or the most room for
it. A laptop, a workstation and a Spark look like one endpoint.| llmman | Ollama | |
|---|---|---|
| Model registry | Hugging Face directly, or any OCI registry (Docker Hub, GHCR, quay, Harbor, self-hosted) | ollama.com library, own registry protocol |
| Model format on disk | Unmodified GGUF / safetensors in a standard OCI Image Layout | GGUF and safetensors imported via Modelfile into Ollama's blob layout |
| Inference engine | Upstream llama.cpp release, or your own llama-server; vllm; mlx-lm |
Bundled llama.cpp/ggml fork plus Ollama's own engine |
| Hosted models | Any provider via --provider |
Ollama Cloud |
| Registry-to-registry transfer | llmman transfer hf.co/... docker.io/... in one step, nothing added to your local store |
Pull, write a Modelfile, create, push to ollama.com |
| Signing and verification | cosign-format signatures; verify command and per-repo pull-time trust policy |
None |
| Multiple machines | Aggregation: daemons pool hardware, any node answers for all | One host per endpoint |
Linux, macOS:
curl -fsSL https://llmmanorg.github.io/install.sh | sh
Windows (PowerShell):
irm https://llmmanorg.github.io/install.ps1 | iex
Homebrew:
brew install llmmanorg/tap/llmman
winget:
winget install llmmanorg.llmman
Cargo:
cargo binstall llmman # prebuilt binary
cargo install llmman # build from source; needs Go 1.25+ (and LLVM on Windows) as well as Rust
Three commands cover most of it:
llmman launch claude --model qwen3.8 # an agent on a local model
llmman run qwen3.8 # just chat with a model
llmman serve # an Ollama/OpenAI/Anthropic-compatible endpoint
Run llmman launch with no arguments to see the supported agents and whether
each is installed. Want a hosted model instead of a local one? Every command
above takes --provider; see Hosted providers. Want both
at once, picked per request? See Hybrid model pairs.
| Command | Description |
|---|---|
serve |
Start an inference server (Ollama / OpenAI / Anthropic APIs) |
launch |
Launch an integration (Claude Code, OpenCode, …) |
run |
Run a model interactively or with a one-shot prompt |
pull |
Pull a model from a registry or HuggingFace |
list (ls) |
List locally stored models, or a hosted provider's (--provider) models |
ps |
List models currently loaded |
providers |
List the hosted providers --provider can route to |
stop |
Stop (unload) a running model |
build |
Package model files into a local OCI image |
push |
Push a local image to a registry |
transfer |
Transfer an image directly from one location to another (e.g. HuggingFace to an OCI registry) |
cp |
Copy a local image to a new reference |
rm |
Remove a local image |
show |
Show a local model's architecture, parameters, license, and template |
verify |
Check a registry model's signatures against trusted public keys |
login |
Log in to a container registry or HuggingFace |
logout |
Log out from a container registry or HuggingFace |
config |
Read and write llmman.conf settings (aliases, API keys, trust policy, aggregation peers) |
Models are packaged as standard OCI artifacts and stored in any compatible
registry: Docker Hub, GHCR, quay, self-hosted. There is no curated library and
no gatekeeper: push a model anywhere you can push a container image, and anyone
can llmman run it straight from there.
llmman pull qwen3.8
Transfer an image directly from a source to a destination without adding it to your local store, e.g. HuggingFace straight to an OCI registry:
llmman transfer hf.co/unsloth/Qwen3.5-0.8B-GGUF docker.io/owner/model:latest
Any source llmman pull understands (an OCI registry, hf://, ms://, ...) can be paired with any OCI registry destination.
No gatekeeper means nothing vouches for a model implicitly, so llmman
verifies the artifact rather than trusting the hub. Signatures are
cosign-format, so cosign verify
reads what llmman writes and the check works the same on Docker Hub,
GHCR, quay, or an air-gapped mirror.
llmman push docker.io/myorg/mymodel:v1 --sign-key signing.key
llmman verify docker.io/myorg/mymodel:v1 --key signing.pub
A [verify] trust policy turns that into an automatic check on every
pull, warning or refusing outright per repository. Off by default —
there is nothing to check against until you have said whom you trust.
See docs/verification.md.
llmman serve
One endpoint on 127.0.0.1:17434 that speaks Ollama, OpenAI and Anthropic:
| API | Endpoints |
|---|---|
| Ollama | /api/chat, /api/generate, /api/embed, /api/tags, /api/ps, /api/pull, /api/push, /api/create, ... |
| OpenAI | /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models, /v1/responses, /v1/audio/transcriptions |
| Anthropic | /v1/messages |
So any existing client works unchanged:
OLLAMA_HOST=127.0.0.1:17434 ollama run unsloth/Qwen3.5-0.8B-GGUF
Models load on demand, each in its own backend process, and unload after
five idle minutes (keep_alive, as in Ollama). GGUF is served by upstream
llama.cpp, downloaded to match
your GPU if no llama-server is on PATH; safetensors by
vllm, or by
mlx-lm on Apple Silicon. Tool
calling, vision, structured output, embeddings (GGUF) and the Responses
API (what Codex speaks) all work; there is a web UI at / and an
optional Prometheus /metrics.
The full endpoint list and per-API notes are in docs/api.md; backend selection in docs/backends.md; bind address, context length, keep-alive and the other daemon settings in docs/configuration.md.
Several machines each running llmman serve can pool their hardware — a
group of manatees is an aggregation. Name the others on each node and a
request to any of them is served by whichever has the model loaded, or
the most room to load it:
llmman config set aggregation.peers asahi,spark
LLMMAN_HOST=0.0.0.0 llmman serve
llmman ps, /api/tags and /v1/models then show the whole
aggregation, and llmman stop reaches a model wherever it was loaded.
Nothing is elected and nothing is shared: every node is a whole llmman
that knows the others' addresses. See docs/aggregation.md.
Point an integration at a model in one step. llmman launch starts serve
in the background if it isn't already running (preloading a local
model), then sets the right environment variables and execs the
integration:
llmman launch claude --model qwen3.8
Run llmman launch with no arguments to list the supported integrations
(Claude Code, OpenCode, Codex, Aider, Qwen Code, Gemini CLI, ...) and
whether each is installed. Any extra arguments after -- are forwarded to
the integration's own CLI. Short names work wherever a model reference is
accepted.
--provider points llmman at a model it doesn't serve itself, from
launch, from run, and from `lis