SGLang is a framework for running inference for large language models and multimodal models, meaning it processes inputs to produce model outputs such as text or other media. It is used to serve and accelerate open AI models and related workloads.
Borrowing it
Nothing to install: this file belongs to sgl-project/sglang. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/sgl-project/sglang/main/.claude/skills/cookbook-migrate-model/SKILL.mdgit clone --depth 1 https://github.com/sgl-project/sglangWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sgl-project/sglang/cookbook-migrate-model)<a href="https://agentmods.dev/skills/sgl-project/sglang/cookbook-migrate-model"><img src="https://agentmods.dev/badge/skills/sgl-project/sglang/cookbook-migrate-model/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/sgl-project/sglang/cookbook-migrate-model"><img src="https://agentmods.dev/badge/skills/sgl-project/sglang/cookbook-migrate-model.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 36 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 143 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00103 | $0.04054 |
| Opus 5 | $0.00051 | $0.02027 |
| Sonnet 5 | $0.00021 | $0.00811 |
| Haiku 4.5 | $0.00010 | $0.00405 |
Grade A, and why
cookbook-migrate-model scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 242 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cookbook Migrate Model
Convert one legacy cookbook page to the config-driven format, faithfully. The legacy page — its generator widget and its measured benchmark blocks — is the single source of truth. You are transcribing it into the new data model, not improving it.
Reuses the cookbook-add-model skill's assets (read them on demand):
../cookbook-add-model/templates/config.jsx.tmpl,page.mdx.tmpl,benchmarks.jsx.tmpl../cookbook-add-model/references/authoring-reference.md(config/cells/playground contract)../cookbook-add-model/references/mintlify-authoring.md(MDX rules)
Migration-specific references in this skill:
- references/dimension-mapping.md — legacy-control → new-dimension mapping rules, command rewrite table, per-family strategy sets, and the Qwen3.5 pilot as a worked example (PR #27848).
The round's per-model inventory (scope, batch order, quirks, measured-data survey) is tracked by the migration maintainer outside the repo — expect it in your dispatch prompt, or ask for it.
Hard rules (non-negotiable)
- Never modernize. Env vars, flags, TP values, docker tags, version strings
are copied verbatim from the legacy page — even when today's defaults differ
(e.g. a flag whose behavior has since become the default; keep it anyway). The recipe
that was verified is the recipe as written. Allowed normalizations are ONLY
the five alias rewrites in dimension-mapping.md §2 (
launch_server→sglang serve,--model→--model-path,--tp-size→--tp, abbreviated--speculative-algo→--speculative-algorithm,--expert-parallel-size→--ep). Accuracy-degrading flags (--kv-cache-dtype fp8_e4m3, W4A4-style runtime quant) follow a deterministic rule — enforced in migration, no asking: offered as a legacy selectable option → never select it (cells mirror the accuracy-safe side), and the option survives as a Playground axis — an existing one where it fits, else add one via a separate prior engine PR (rule 4); a legacy choice never degrades to a tips mention. Baked into the recipe's default/unconditional command → keep it verbatim (the recipe was measured with it, and fp8 KV halves KV memory — stripping could OOM it). See dimension-mapping.md §2 caveats. - Never invent versions or numbers. Benchmark numbers only from the
legacy page's measured blocks, and a result migrates ONLY when its
sglang_versionis a reproducible anchor — the bar is reproducibility, not "must be a release":- ✅ release tag/version (
v0.5.9/0.5.9), commit hash, OR — for Day-0 support (the enabling PR isn't merged and no release is cut yet) — a specific PR (PR #27944) or commit you cangh pr checkout/git checkout <sha>. Commit is most precise; a PR pin is fine for day-0. - ❌ a moving ref —
"main branch","main (2026-06-11)", open-ended"0.5.8+"— is NOT reproducible: drop the WHOLE result (speed AND accuracy), not just speed. KeepbenchmarkCommandsso ⚡Reproduce still guides re-measurement against a pinned build. Never inherit cross-model numbers — measurements the legacy page attributes to a different model (e.g. a K2.6 page carrying K2.5-measured speed) are dropped regardless of version. When kept,sglang_versionis the legacy page's string verbatim. Docker tags only the ones the legacy page pinned (unmapped hw falls back to:dev).
- ✅ release tag/version (
- Verified policy (strictest tier).
verified: trueONLY when (a) the legacy page has concrete measured data for that exact 5-dim combo AND (b) the cell's flags equal the deployment command used for that measurement — modulo{{HOST_IP}}/{{PORT}}, the five alias rewrites, and parser flags:--reasoning-parser/--tool-call-parserare stripped from every cell (Playground-only feature; when the measured run had them on, say so in the benchmarks file header). When the measured command diverges from the generator default, the verified cell follows the measured command; the generator default stays as the sibling strategy/cell or a tips note. Everything else is unverified (yellow) — including combos that look memory-infeasible; keep them verbatim and list them in the PR body for the re-verification track. - Engines are read-only.
_deployment.jsx/_playground.jsxmust not change in a migration PR. Model-specific features are config DATA consumed by generic axis handlers (MegaMoE precedent), so they need NO engine change. A titled single-select that strips a flag family — KV Cache DType (--kv-cache-dtype), mamba (--mamba-scheduler-strategy), … — is already covered by the merged genericflagSelectsaxis: declare it in the config (a list of{ id, title, stripPrefixes, options }; see the Qwen3.5 mamba example), no engine PR. Only a genuinely new control shape thatflagSelectscan't express would need a one-time generic primitive (never a model-named handler) on a separate prior PR (engine-axis.md). github.cookbookModelmust be set (<hf-org>/<page-slug>, e.g.qwen/qwen3.5) and the block never pruned — without it Submit ↗ mislabels as deepseek-v4. The issue template itself needs NO edits (free-form input).- Strategy tiers are signal-driven. A cell goes under
low-latency/high-throughputONLY on a signal present in the legacy source (an explicit performance toggle, a named recipe, or prose stating the operating point); no signal →balanced. Never derive a slant from your own hardware intuition — re-tiering on measured evidence is the hardware owner's follow-up PR, not part of a migration (dimension-mapping.md §4).
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 242 lines · 103 tokens per session scan A 87ee0c52d14d
cookbook-migrate-model is a skill published in the GitHub repository sgl-project/sglang (35,615 stars, last pushed today), licensed Apache-2.0. It adds 103 tokens to every session and 4,054 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
llama-factory
Expert guidance for fine-tuning LLMs with LLaMA-Factory - WebUI no-code, 100+ models, 2/3/4/5/6/8-bit QLoRA, multimodal support.
groq-inference
Ultra-fast LLM inference on custom LPU hardware. OpenAI-compatible API at api.groq.com. Lowest latency in the industry (500-1000+ tok/s). Supports chat completions, vision, audio (Whisper STT + TTS), tool calling, JSON mode, and streaming. Free tier available. Inference only — no training.
perf-optimize
Launch and operate this repo's perf-optimize workflow, which iteratively APPLIES TensorRT-LLM serving optimizations — baseline benchmark at one concurrency or a Pareto curve of them (tok/s/user vs tok/s/gpu), analytical SOL projection on by default (via the internal-perf-sol-analysis skill) sizing the headroom the…
perf-analyze
Launch and operate this repo's perf-analyze workflow, which DIAGNOSES a TensorRT-LLM serving deployment without applying changes — benchmark at one concurrency or a Pareto curve of them (tok/s/user vs tok/s/gpu), analytical SOL projection on by default (via the internal-perf-sol-analysis skill), nsys + ncu per-kernel…
fireworks-ai-inference
Fast inference and fine-tuning platform with serverless and on-demand GPU deployments. OpenAI-compatible API for chat completions, embeddings, function calling, vision, and structured output. Supports SFT, DPO, and RL fine-tuning. SOC2 + HIPAA compliant.
ort
ONNX Runtime in Rust via the ort crate (2.x): loading sessions, configuring CPU/CoreML/CUDA execution providers, tensor I/O with ndarray, async-safe spawnblocking wrapping, global thread-pool init, and debugging provider/opset issues.