Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add StamKavid/last-ds-mile --skill ds-deploygit clone --depth 1 https://github.com/StamKavid/last-ds-mileWrote 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/stamkavid/last-ds-mile/ds-deploy)<a href="https://agentmods.dev/skills/stamkavid/last-ds-mile/ds-deploy"><img src="https://agentmods.dev/badge/skills/stamkavid/last-ds-mile/ds-deploy/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/stamkavid/last-ds-mile/ds-deploy"><img src="https://agentmods.dev/badge/skills/stamkavid/last-ds-mile/ds-deploy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00085 | $0.01129 |
| Opus 5 | $0.00043 | $0.00564 |
| Sonnet 5 | $0.00017 | $0.00226 |
| Haiku 4.5 | $0.00009 | $0.00113 |
Grade A, and why
ds-deploy 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 8d 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ds-deploy — Make It Callable, Safely
Overview
A model that ships without monitoring degrades in silence. This stage stands the
/ds-package container up as a callable endpoint and requires the operational layer
that keeps it honest in production: logging predictions against the same baseline it
beat offline, watching for input drift, and a one-command way back. It is
local-container-first by design — the plugin never pushes to a remote or a cloud target
on its own. It ships no code; it guides you to generate the endpoint wiring, monitoring
and drift hooks, and rollback record into .last-ds-mile/deploy/.
When to Use
- After
/ds-packagehas produced a parity-verified image and an inference contract, and the model is ready to serve real requests. - NOT before parity passes — an unverified package is not deployable.
- NOT for retraining automation — retraining triggers are out of scope (roadmap).
Core Process
- Gate check. Confirm
/ds-packageproduced a parity-verified image and acontract.json. If parity was never proven, stop and run/ds-package. - Local endpoint. Stand the container up locally as the default callable service
(a thin HTTP or CLI entry over the packaged
predict). Cloud targets are documented adapter stubs the user fills in — never a baked-in vendor path. - Operational gate — all three required before full-traffic deploy:
- Monitoring hook →
.last-ds-mile/deploy/monitor.jsonl: append inputs, predictions, and — once labels arrive — the online metric against the same baseline heuristic the model beat at/ds-baseline. Newline-delimited JSON, no tool dependency. (If the team already runs MLflow, it can log there instead; the discipline is what matters, not the tool.) - Drift hook: compare serving-input distributions against the training
distributions and warn on drift. Reuse the
distribution-shiftskill for the method rather than reinventing it. - Rollback pointer →
.last-ds-mile/deploy/rollback.json: the previous image digest and a one-command revert.
- Monitoring hook →
- Canary discipline. Recommend shadow or a small canary before routing full traffic — never send 100% to a freshly deployed model on the first cutover.
- Confirm before any outward push. Standing up locally is fine to proceed. Pushing to a container registry, a remote host, or a cloud serving target is outward-facing — stop and ask the user to confirm (and let them perform any credentialed step). The plugin makes no network calls of its own.
- Write
.last-ds-mile/stages/12-deploy.md: the endpoint location, the monitoring and drift hook locations, the rollback pointer, and the canary plan.
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.
- 8d ago First seen · 81 lines · 85 tokens per session scan A 4af506318d11
ds-deploy is a skill published in the GitHub repository StamKavid/last-ds-mile (3 stars, last pushed 1mo ago), licensed MIT. It adds 85 tokens to every session and 1,129 once invoked, about $0.0004 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-31.
Other skills, from other repositories
modal
Cloud computing platform for running Python on GPUs and serverless infrastructure. Use when deploying AI/ML models, running GPU-accelerated workloads, serving web endpoints, scheduling batch jobs, or scaling Python code to the cloud. Use this skill whenever the user mentions Modal, serverless GPU compute, deploying ML…
marimo-pair
Work inside the user's live marimo notebook from the code editor: run Python in the same kernel the user does, inspect live notebook state, and commit durable notebook changes through code mode. Use whenever you create, analyze, or improve the user's marimo notebook.
fill-model-descriptions
Fill missing and refresh obsolete model descriptions in packages/llm-info/data/models.yml by querying OpenRouter and provider documentation. Use when the user asks to populate model descriptions, enrich the model catalog, or curate descriptions after running pnpm sync-models.
dstack-prototyping
Use with the dstack skill for model-serving work when the image, serving command, resources, backend/fleet choice, or service behavior is not proven. Guides task-first prototyping on real hardware, choosing fleets/backends that can reuse idle instances and caches, checking vLLM/SGLang sources, and verifying the final…
dstack-presets
Create and manage dstack presets: a toolkit that streamlines model inference optimization with agents, and a portable preset format. Use together with the dstack skill, and only when the user explicitly asks to create a preset or manage existing presets, not for deploying or serving a model.
ml-expert
Expert-level machine learning, deep learning, model training, and MLOps. Use when the user mentions machine learning, deep learning, neural networks, MLOps, or data science, or when the task involves Machine Learning Fundamentals, Data Preparation, or Model Training.