ANOLISA: An Agentic OS Layer That Strips Tool Responses Before They Reach the Model
ANOLISA (Agentic Nexus Operating Layer & Interface System Architecture) | Agentic OS with runtime, security, observability, and Tokenless response compression for lower token usage and cost.
At a glance
- What is it?
- ANOLISA bundles a shell copilot, a response compressor, a memory store and an eBPF tracer into one Apache-2.0 install. The compression path is the part with a concrete mechanism and a number attached; the rest of the stack is broader and less specified in the README.
- Who is it for?
- Adopt ANOLISA if you already run Claude Code or a similar framework on Linux or macOS and your bill is dominated by tool output, not by reasoning tokens. Do not adopt it if you need a stable API surface today: the README documents nine components with independent release cadences, and the newest ones (agent-memory at v0.2.7, tokenless at v0.8.1) are still pre-1.0.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is tool output, not model reasoning
An agent that reads files, runs commands and queries APIs spends most of its context window on tool results, and most of those results are payload the model never needs: debug fields, trace arrays, null metadata, empty tag lists. The README frames this as one of three constraints of agent execution, alongside terminal entry and execution environments. The intended user is someone running an agent framework on Linux or macOS who has already picked a shell and a sandbox and does not want to replace either. The README states plainly that you keep the Shell, Agent framework, and sandbox you already use, and that each capability can be enabled independently through a single CLI entry point. That independence is the design claim worth testing: nine components are listed, and nothing in the material shows whether enabling one pulls in the others.
How Token-less compresses a tool response
The mechanism is a proxy sitting between the agent and the model, so no framework code changes. The README describes three transformations applied to responses: a field blacklist drops debug and trace, metadata is reduced to null, and tags and extra are reduced to empty values. Array items that get dropped are not discarded outright. They stay retrievable through a marker in the form <<tokenless:KEY>>, which the README calls out as what keeps the compression reversible. That reversibility is the interesting engineering choice. A compressor that silently deletes array elements breaks any agent that later indexes into the result, so the marker gives the model a handle to pull the item back. The README reports 65.8% fewer tokens on tool responses, 47.3% on tool schemas, and a full-pipeline figure that is cut off in the supplied text. It also cites one observed coding task where Token-less saved 317K tokens, 40.5%, measured by AgentSight, with the caveat that results vary by workload. Treat those as vendor measurements from a single task, not as a general rate.
Install commands and the adapter step
The README gives a three-minute path for Claude Code. Install the CLI with a curl pipe to get.agentic-os.sh, add $HOME/.local/bin to PATH, then run 'anolisa install tokenless' and 'anolisa adapter enable tokenless claude-code'. Restart Claude Code afterwards. Inspection is two commands: 'tokenless stats summary' and 'tokenless stats list --limit 5'. The adapter step is the load-bearing one and the README only demonstrates it for claude-code. Whether other frameworks are supported is not stated in the material provided, so check the adapter list before assuming your stack is covered. The compression itself runs between the agent and the model, which means the adapter is what wires the proxy into your framework's request path. If no adapter exists for your framework, the install command alone will not do anything useful.
AgentSight traces from the kernel with eBPF
AgentSight is the observability component and the one with the most distinctive approach. On Linux it uses eBPF to observe an agent without changing its code, following user input through model calls and tool calls, with token use and sub-agent branches in the same view. That is a real difference from SDK-based tracing, which requires the agent to emit spans. Kernel-level observation means you can instrument an agent you did not write and cannot modify. The cost is platform scope: the README lists Linux and macOS as supported platforms overall, but the eBPF mechanism is described specifically for Linux, and macOS has no eBPF. What AgentSight does on macOS is not covered in the supplied material. If your agents run in containers, note that eBPF visibility depends on host kernel access, which is a deployment question the README does not address.
The rest of the stack: checkpoints, sandbox, memory, skills
The remaining components split into three groups. Runtime and security includes ws-ckpt for checkpoint and rollback, SkillFS for keeping the current skill view focused while making others discoverable, Agent Sec Core for sandbox and verification, and Blaze for sandbox lifecycle. Context efficiency includes Agent Memory for cross-session reuse and the token-saving pair already covered. Agent entry includes cosh-ng, an AI-native Linux terminal that keeps Bash and Zsh behavior and adds an agent that asks for approval before risky work, plus OS Skills and ktuner for kernel tuning. The README does not give mechanisms for most of these, only one-line descriptions. That is a documentation gap, not a defect, but it means you cannot evaluate ws-ckpt's rollback semantics or Blaze's sandbox model from the repository front page. Version numbers hint at maturity: agent-memory is at v0.2.7 and tokenless at v0.8.1, while agentsight reached v0.12.1. Anything below 1.0 in a component that touches your execution environment deserves a read of its own docs first.
Where ANOLISA is the wrong tool
If your token spend is dominated by long reasoning chains rather than tool output, the compression layer has little to remove and the install buys you nothing. The README's own framing is that Token-less targets redundancy in tool schemas and responses, so a single-turn question-answer workload is out of scope. A second case: if you cannot tolerate any mutation of tool results, the field blacklist is a hard stop. Dropping debug and trace, nulling metadata and emptying tags and extra changes what the model sees. The <<tokenless:KEY>> marker keeps dropped array items retrievable, but it does not restore blacklisted fields. An agent that branches on a debug field will behave differently after installation. Third, the whole stack assumes Linux or macOS. There is no Windows path in the material. Fourth, the eBPF tracing path is Linux-specific, so on macOS you get a smaller observability story than the README's headline suggests.
How this differs from SDK-based agent platforms
The obvious comparison is an agent SDK such as LangChain or the OpenAI Agents SDK, where observability comes from instrumented callbacks inside your process and context management is something you implement. ANOLISA inverts both. Observation happens at the kernel via eBPF rather than through in-process hooks, which is why it works on agents you did not write. Compression happens in a proxy between agent and model rather than in your prompt assembly code, which is why the README can claim no framework code changes. The trade-off is coupling: an SDK-based approach works wherever Python or TypeScript runs, while ANOLISA's tracing needs a Linux kernel with eBPF and its compression needs an adapter for your specific framework. You are trading portability for transparency. If you control your agent's source and run it on managed infrastructure, an SDK gives you the same token visibility with fewer platform constraints. If you are debugging an agent you inherited, kernel-level tracing is the only option that does not require a code change.
Licence, versions and what maintenance looks like
ANOLISA is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That matters if you are embedding the compression proxy in a product. The licence does not, however, tell you anything about the health of the project, and the material shows a stack that releases components independently: sight/v0.12.1, tokenless/v0.8.1 and memory/v0.2.7 all shipped within two days of each other in September 2026. Independent versioning means an upgrade to one component does not force a coordinated bump of the others, which lowers upgrade cost in theory. It also means you need to track nine release streams rather than one, and the README does not describe a compatibility matrix between them. The install path goes through a curl pipe to get.agentic-os.sh, so you are trusting a remote script unless you fetch and read it first. Do that. The CLI also writes to $HOME/.local/bin, which is a per-user install with no system-wide option documented in the material.
Editorial conclusion
Adopt ANOLISA if you already run Claude Code or a similar framework on Linux or macOS and your bill is dominated by tool output, not by reasoning tokens. Do not adopt it if you need a stable API surface today: the README documents nine components with independent release cadences, and the newest ones (agent-memory at v0.2.7, tokenless at v0.8.1) are still pre-1.0. Before installing, verify two things: that your agent framework has an adapter listed by 'anolisa adapter enable', and that the field blacklist in Token-less does not drop keys your agent actually reads back. Check both with 'tokenless stats list --limit 5' after one tool-heavy task.
Community notes