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 agentmods add skills/yogasw/wick/wick-resource-limitsnpx skills add yogasw/wick --skill wick-resource-limitsgit clone --depth 1 https://github.com/yogasw/wickWrote 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/yogasw/wick/wick-resource-limits)<a href="https://agentmods.dev/skills/yogasw/wick/wick-resource-limits"><img src="https://agentmods.dev/badge/skills/yogasw/wick/wick-resource-limits.svg" alt="Measured on agentmods" 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 | $0.00084 | $0.01923 |
| Opus 5 | $0.00042 | $0.00962 |
| Sonnet 5 | $0.00017 | $0.00385 |
| Haiku 4.5 | $0.00008 | $0.00192 |
Grade A, and why
wick-resource-limits 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 5d 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 — 127 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent resource limits
Wick can cap how much memory, CPU, and IO its agents consume, and records what they actually used. Enforcement is done by the kernel, not by wick sampling and killing — a sampler cannot catch a process that allocates a gigabyte between two samples.
Two things follow from that, and they explain most questions about this subsystem:
- Enforcement needs cgroups, so it is Linux-only. Measurement, reporting, and crash recovery work everywhere.
- A killed agent is killed by the kernel. Wick's job is to report it accurately, not to prevent it after the fact.
The three modes
memory_guard_mode, default off:
| Mode | Writes limits | Kills anything | Records usage |
|---|---|---|---|
off |
no | no | no |
measure |
no | no | yes — fully |
enforce |
yes | kernel kills the offender | yes |
The distinction that trips people up: measure records everything and applies nothing. It is not a dry run that logs what it would do — it is real measurement with no ceilings. That makes it the correct first step: run in measure for a while, look at the observed peaks, then set limits from real numbers rather than guesses.
Do not describe measure as "not doing anything". It is doing the measuring; it is only withholding the enforcement.
What each platform can actually do
Answer from this table rather than inferring from "Linux-only":
| Capability | Linux + systemd | Linux, no systemd | Windows | macOS |
|---|---|---|---|---|
| Per-agent memory ceiling | yes | yes | no | no |
| Aggregate ceiling for all agents | yes | yes | no | no |
| CPU weight / quota / task cap | yes | no | no | no |
| Naming an OOM kill with its peak | yes | no | no | no |
Peak readable in measure mode |
yes | yes | no | no |
| Agents die before wick does | yes | yes | no | no |
| Queue a spawn when RAM is low | yes | yes | no | no |
| Machine memory total / available | yes | yes | yes | no |
| Process listing | yes | yes | yes | no |
| Disk capacity | yes | yes | yes | yes |
| Usage history + Resources page | yes | yes | yes | partial |
| Crash recovery + respawn | yes | yes | yes | yes |
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.
- 5d ago First seen · 127 lines · 84 tokens per session scan A abd0377059eb
wick-resource-limits is a skill published in the GitHub repository yogasw/wick (5 stars, last pushed yesterday), licensed MIT. It adds 84 tokens to every session and 1,923 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
research-wiki
Persistent research knowledge base that accumulates papers, ideas, experiments, claims, and their relationships across the entire research lifecycle. Inspired by Karpathy's LLM Wiki pattern. Use when user says "知识库", "research wiki", "add paper", "wiki query", "查知识库", or wants to build/query a persistent field map.
mnemon
Persistent memory CLI for LLM agents. Store facts, recall past knowledge, link related memories, manage lifecycle.
mnemon
Persistent memory CLI for Hermes Agent. Store facts, recall past knowledge, link related memories, manage lifecycle.
pneuma-project
Project-context awareness — multi-session workflows around one topic, shared materials and preferences, and cross-mode handoffs as a high-value user path.
alive:session-history
Revive sessions (quick or heavy), browse, and search — 'what happened recently?', 'find the session where we discussed X', 'revive yesterday's session'. For single-session recall and multi-session browsing. If the human needs to merge multiple sessions into one working context or detect conflicts between parallel…
alive:mine-for-context
Deep context extraction from source material. Creates reference bundles, builds extraction plans, tracks what's been extracted, and discovers new targets — people, subjects, patterns, connections. The archaeologist that turns raw sources into structured knowledge. Can be invoked by alive:session-history for targeted…