The Short Answer
Alibaba Cloud has open-sourced ANOLISA, an agent-first Linux distribution that turns context compression, sandboxing and agent observability into operating-system services. On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — which is what makes an OS-layer shift usable rather than another vendor dependency, because infrastructure only becomes an asset when you control the layer it runs on.
ANOLISA — "Agentic Nexus Operating Layer & Interface System Architecture," shipped as Alibaba Cloud Linux 4 Agentic Edition — is public on GitHub under Apache 2.0.
It matters less as a product than as a signal about where agent plumbing is migrating: out of the application and down into the platform.
What is ANOLISA, and what does it actually ship?
ANOLISA is a Linux distribution designed to be operated by AI agents rather than by people. Alibaba Cloud's documentation groups its components into three families:
| Group | Components | What it addresses |
|---|---|---|
| Agent entry | cosh-ng, OS Skills, ktuner | A natural-language shell, structured capability manifests, kernel tuning |
| Context efficiency | Token-less, AgentSight, Agent Memory | Tool-output compression, trace and token visibility, cross-session memory |
| Runtime & security | ws-ckpt, SkillFS, AgentSecCore, Blaze | Checkpoint and rollback, scoped skill views, sandboxing and verification |
Read that list as a claim about ownership of responsibilities. Every one of those concerns is something teams currently solve inside an agent framework, or buy from a vendor, or do without.
Does ANOLISA strip tool output in the kernel?
No — and this is worth stating plainly, because the claim circulates in the shortened form "it strips redundant tool output at the kernel level," which merges two different components.
Token-less runs in userspace. Alibaba's own documentation describes it as operating "between the Agent and the model," through plug-ins and hook mechanisms, with "no Agent framework code changes." That placement is the feature, not a limitation: sitting outside the kernel is what lets it compress traffic for an agent whose code you are not modifying.
AgentSight is the kernel-level component, and it does observability rather than compression — eBPF instrumentation that watches LLM API calls, token consumption and process behavior without the agent being aware of it.
The distinction matters if you are deciding what to adopt. A userspace compression shim is portable and low-risk. Kernel-level eBPF observability is powerful and carries a different operational and security review.
How much context does it actually save?
Alibaba publishes numbers from one traced task rather than a benchmark suite, so treat them as an illustration of the mechanism, not a guaranteed rate:
| Measure | Reduction |
|---|---|
| Tool responses | 65.8% |
| Tool schemas | 47.3% |
| Overall, one observed task | 40.5% (317K tokens) |
The reason the numbers are large is unglamorous. Agent context is dominated by machine-generated text that no model needs in full: verbose JSON schemas describing tools, and tool responses padded with fields the agent will never read. That is compressible in a way prose is not.
Why does moving agent plumbing to the OS layer matter?
Because it changes what you are buying. When context compression, sandboxing, checkpointing and observability live inside a hosted agent product, they are features with a subscription attached.
When they are OS services, they are infrastructure — you run them, inspect them, and keep them.
This is the same migration containers went through. Namespaces and cgroups existed as kernel features long before anyone paid for a container platform; the platform business formed on top of primitives that stayed free.
ANOLISA is a bet that agent isolation and context management follow the same path.
The bet is not obviously correct. Some of what agents need — model routing, evaluation, memory policy, multi-tenant governance — is application logic that no operating system will absorb.
But the parts that are genuinely systems problems, which is most of that component list, plausibly do belong lower in the stack.
What does this mean if you are choosing an AI platform?
An OS-layer shift only benefits you if you control the layer.
If your agents run inside a vendor's managed environment, you do not get to choose your operating system, adopt a compression shim, or attach an eBPF probe — those decisions were made for you, and the savings accrue to the vendor's margin rather than your budget.
That is the practical case for owning the stack. On ibl.ai you own all the code and the data: the platform is source-available under a perpetual license and runs on your infrastructure, so the decision to adopt something like ANOLISA is yours to make.
It is model-agnostic across any LLM, and billed with no per-seat pricing, so a 40% cut in token consumption shows up as a 40% cut in your bill rather than as improved unit economics for someone else. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
What should you watch next?
Three things will tell you whether the OS-layer thesis holds:
Whether the primitives get adopted outside their origin. Apache 2.0 means the components can be lifted independently. A Token-less-style compression shim running in front of agents on non-Alibaba infrastructure would be the strongest signal that this is a layer shift rather than one vendor's differentiator.
Whether observability standardizes. eBPF-based agent tracing is the most portable idea in ANOLISA, because it requires no cooperation from the agent being traced. Token accounting that works regardless of framework is something every operator needs.
Whether compression stays lossless enough. Stripping fields from tool responses is safe until the model needed the field. Anyone adopting this should measure task success, not just token count — a cheaper run that fails is not cheaper.
For more on why the deployment layer decides who captures these savings, see our analysis of enterprise AI ownership versus rental economics and why model-agnostic architecture matters more than any single model choice.