SkillFS is a FUSE file system that sits between an agent and its skill directory, deciding which skills the agent can see, whether each one is trustworthy, and what to serve when a skill goes bad. Alibaba Cloud published it on 10 October 2026 as part of ANOLISA, and it matters because the usual answer to skill sprawl, mounting every folder and letting the model read dozens of descriptions each turn, burns tokens and makes the agent pick the wrong tool.
The skill format it governs is simple and now widespread. A skill is a directory containing a SKILL.md with YAML frontmatter, plus optional scripts/, references/ and assets/ folders. The Agent Skills specification says the name and description fields, roughly 100 tokens per skill, are loaded at startup for every skill, and the full body only once the agent activates one. That startup load is the problem. Thirty-eight skills in a source tree means thirty-eight descriptions in context before the agent has done anything.
What the mount actually changes
SkillFS maps a physical source tree to a runtime view. With a normal mount, source and mountpoint are different directories and the agent reads from <mountpoint>/skills/<skill-name>/SKILL.md. Install it from the Alibaba Cloud Linux package repository and mount it:
sudo yum install skillfs
skillfs mount /data/agent-skills /tmp/skillfs-demo/mount --foreground
ls /tmp/skillfs-demo/mount/skills
The directory name is the authoritative skill id. The name field inside SKILL.md is display metadata and doesn't override the directory key. That's deliberate. Renaming a directory switches visibility immediately, and a stale frontmatter name can't reinject the old skill.
Visibility comes from skillfs-views.toml in the source root. High-frequency skills go in the default view and appear directly under /skills; everything else sits in a secondary view, reachable through a virtual skill called skill-discover:
[[view]]
name = "default"
default = true
description = "High-frequency skills appear directly in the runtime directory"
skills = ["weather-query", "ecs-diagnosis"]
[[view]]
name = "secondary"
default = false
description = "Low-frequency or backup skills, discovered through skill-discover"
skills = ["kernel-tuning", "image-helper"]
The default = true flag picks the default view, and the view's name has no say in it. Skills absent from every view land in the effective default view, so partial configuration degrades toward exposure instead of toward hiding things. Editing the file does nothing to a running mount; you remount to apply it. skillfs classify /path/to/skills generates a starting skillfs-views.toml, and skillfs validate reports parse failures with a non-zero exit code while degraded-only skills exit 0.
The token saving is real and modest
Alibaba's own benchmark covered 27 scenarios across 38 skills in five categories, four rounds each. The results split sharply by model. kimi-2.5 went from 174,167 to 136,942 tokens, a 21.37% saving, while qwen3.5-plus saved 0.94%, and minimax-m2.5 and qwen3.6-plus landed around 7%. Their cost formula weights cached tokens at 0.2.
So the honest read is that view clipping pays off in proportion to how badly the model handles tool selection on its own. A model that already retrieves skills well has little left to save. If you are choosing SkillFS purely on the token line, run your own two-way comparison before you commit, because a 0.94% saving doesn't justify a privileged FUSE mount in your pod.
The mis-selection argument is stronger than the cost argument. Fewer candidate skills means fewer wrong tool calls, and a wrong tool call costs a round trip plus whatever the tool did before someone noticed.
Trust: current, fallback, hidden
SkillFS makes no security decisions itself. External components such as agent-sec-core or Skill Ledger scan skills and write activation state; SkillFS consumes that state and resolves each skill to one of three outcomes. current serves the live source. fallback serves a trusted snapshot from .skill-meta/versions/*.snapshot, so a skill that drifted after an update stays usable at an older version. hidden makes lookup return ENOENT, and the skill simply isn't there as far as the agent is concerned.
Two details are worth copying into any design you build yourself. First, handle-level pinning: the current target is snapshotted onto the file handle at open time, so a background version switch cannot give one read the old bytes and the next read the new ones. Second, /.skillfs-inbox/<skill> is a fencing channel, where a new skill lands and enters the runtime view only after a scan decision passes.
The .skill-meta/ folder holds activation state and scan results. Writes from ordinary users return EACCES; only an authenticated trusted writer can write, and --trusted-writer-exe <PATH> verifies /proc/<tgid>/exe, the (dev, ino) pair and process start time. The older --trusted-writer <NAME> gate matches on TGID comm, which is spoofable, and the repository marks it deprecated. Use the exe form. Audit output goes to JSONL with --audit-log <PATH>.
For production, the docs point at in-place mount, where source and mountpoint are the same directory so every userspace access goes through FUSE policy:
skillfs mount /data/agent-skills /data/agent-skills \
--foreground \
--security-mode \
--audit-log /var/log/skillfs/audit.jsonl
--security-mode requires source and mountpoint to resolve to the same path. In-place mounts drop the extra /skills layer. Tools that rename or replace the mountpoint directory itself, such as workspace checkpoint or rollback tooling, have to run before mounting or after unmounting; the README notes ws-ckpt checkpoint -w <MOUNTPOINT> failing with Device or resource busy against an active mount.
What it costs to run
SkillFS is Apache 2.0, a standalone Rust project needing Rust 1.86+ for source builds, and it depends only on fuse3 at runtime. Linux only. macOS can run validate, list and classify but cannot mount.
The real cost is privilege. The published container image, ac2-registry.cn-hangzhou.cr.aliyuncs.com/ac2/agentic-os:1.3-skillfs0.4.2-alinux4, runs as a sidecar in the agent's pod and needs privileged: true, a hostPath /dev/fuse of type CharDevice, and mountPropagation: Bidirectional on the SkillFS side with HostToContainer on the agent side. Alibaba's own guidance is to grant privilege only to the SkillFS container, keep the agent container non-root, mount the FUSE view and not the physical source into the agent, and schedule to a dedicated trusted node where possible. The public image is linux/amd64 only, so heterogeneous clusters need nodeSelector: {kubernetes.io/arch: amd64}. An allowlist for privileged pods resolves cluster admission and nothing else; the node-level risk stays.
That trade is the decision. You are adding a privileged sidecar to govern a directory of Markdown files. For an agent fleet running dozens of third-party skills that get updated out from under you, the ledger, the fallback snapshots and the audit trail are worth it. For an internal agent with six skills you wrote and pinned in git, they are overkill, because a code review and a version tag do the same job with no kernel surface.
The limits of what it governs
SkillFS targets skill directories. It is general file sharing in no sense, it is no kind of overlay, and the container image rejects a configuration where source and mountpoint resolve to the same path even though the binary supports in-place mounts.
Its reach stops short of the model, the tool call, and the data the skill touches. A skill that passes every scan can still be handed credentials it should not have. Alibaba's own stack splits those concerns across other ANOLISA components, so if you want policy on what an agent reads from your warehouse, that is a different layer. On Databricks, agent governance runs through Unity Catalog permissions and Unity Gateway in the request path, which centralises LLM permissions, per-app cost attribution and traffic inspection without changing agent code. Databricks' documentation describes no FUSE skill mount, and serverless compute doesn't support compute-scoped init scripts or container services, so a SkillFS mount is something you cannot bolt onto a serverless job. Where it would sit is the self-managed agent host: a VM or Kubernetes pod running the agent process, with Databricks on the other side of the API boundary. We cover that boundary in our agents work.
One more thing to watch. Multiple sources in a mount config force read-only mode, the first source containing a skill name wins the whole skill including its scripts, and there is no hot reload, so changing the config or adding a skill means you remount. For a team that installs skills continuously, that remount is an operational event you need to plan around, and treating it as a footnote will hurt.
Start with classify and validate on a copy of your skill tree
Run skillfs classify and skillfs validate against a copy of your existing skill directory on any Linux box, before you think about mounts or privileges. Those two commands tell you how many skills you actually have, which ones fail to parse, and what a sensible default view looks like. If the generated default view is most of your tree, view clipping will not save you much and you can stop there. If it is five skills out of forty, you have a case to take to whoever owns your cluster's pod security policy.
Frequently asked questions
What is SkillFS?
SkillFS is a FUSE-based virtual file system from Alibaba Cloud that maps a physical agent skill directory into a controlled runtime view, exposing only the skills a task needs and resolving each one as live, a trusted snapshot or hidden. It is part of ANOLISA, released under Apache 2.0, and it runs standalone with fuse3 as its only runtime dependency.
How much does SkillFS reduce token usage?
Between 0.94% and 21.37% in Alibaba's own benchmark of 27 scenarios across 38 skills, with the largest saving on kimi-2.5 and the smallest on qwen3.5-plus. The gain tracks how poorly the model selects tools unaided, so measure on your own model before counting on it.
What does SkillFS require to run in Kubernetes?
A privileged sidecar container with /dev/fuse mounted as a hostPath CharDevice, bidirectional mount propagation on the SkillFS side and HostToContainer on the agent side, Kubernetes 1.29+, and an amd64 node for the current public image. Alibaba recommends granting privilege only to the SkillFS container and mounting just the FUSE view, never the physical source, into the agent container.
Does SkillFS scan skills for malware?
No. SkillFS executes decisions made elsewhere, consuming activation state written by an external scanner such as agent-sec-core or Skill Ledger through a decision command or an activation file, then exposing the skill as current, fallback or hidden.