Chisle: a token-diet ruleset for AI coding agents that publishes its own losing runs

The bill Chisle is trying to shrink

Every turn in a coding agent session re-sends the accumulated conversation. Tool output is the expensive part, because a large grep or build log is billed again on each later request rather than once. Chisle attacks that loop directly: the README states that tool output is compressed on the way back to the model, and that Read, Edit and Write are deliberately excluded so exact bytes still reach later edits.

The output side is a different problem. Models pad answers with hedges, option lists and unrequested abstractions, and every one of those tokens is paid for. Chisle's answer is a ruleset injected once per active session, not a post-processor. The README frames the goal as boring rather than golfed: the same behaviour with one less abstraction and no second file.

The project is aimed at engineers who already pay per token and can see the cost, not at teams evaluating assistants for the first time. Its own tagline is a senior dev who bills by the syllable, which tells you the intended user is already annoyed by verbosity.

Three compression axes and where each one attaches

The README splits the work into output prose, output code and input context. Prose and code are handled by a zero-fluff ruleset and what the project calls a YAGNI efficiency ladder, both applied at session start. Input context is handled per tool call.

The attachment points differ by timing. Ruleset injection happens once per active session. Mode tracking runs every turn, and the README lists it for Claude and Pi only. Tool-output compression runs on every tool call through Claude's PostToolUse hook or Pi's tool_result, in three stages the README names as scrub, elide and dedup, after which the compressed result is rebuilt into the tool's own shape before the model sees it.

The worked example in the README is a debounce request. The bare agent output is quoted at 142 lines and 1506 tokens, opening with a generic useDebounce hook in its own file, then two more options, a comparison table and a caveats section. The Chisle output is quoted at 35 lines and 602 tokens: a setTimeout inside the effect that already exists, two lines on why it works, and a note to use lodash.debounce if it is already installed. Both are described as verbatim committed output from benchmarks/results/raw/, which is the part worth checking yourself.

Installing Chisle and wiring your first agent

Install is one command with no dependencies. The README says the installer auto-detects Claude Code, Pi, Cursor, Windsurf, Cline, Kiro, Codex, Gemini, Copilot, OpenCode and Hermes, and wires each one it finds. Node 18 or newer is required for the installer and npx path.

npx chisle

If you would rather see the changes before they land, the README gives a dry run flag. This prints what the installer would touch and writes nothing.

npx chisle --dry-run

To limit the run to one agent, the README documents an only flag with an agent name. The same section also lists --help for the full surface and --uninstall to remove everything.

npx chisle --only claude

There are two non-npm paths, one per platform. The README gives a curl pipe for macOS and Linux and a PowerShell equivalent for Windows.

curl -fsSL https://raw.githubusercontent.com/JayPokale/Chisle/main/install.sh | bash

irm https://raw.githubusercontent.com/JayPokale/Chisle/main/install.ps1 | iex

After install, the README says /chisle toggling and input-side compression require Claude Code or Pi. On the other nine agents the always-on ruleset still ships, but the per-tool-call compression does not. That distinction is the single most useful thing to understand before you install.

Upgrading is not the same command as installing

This is the sharpest operational detail in the README, and it is easy to get wrong. A plain npx chisle run does not upgrade an existing install. Because every install path skips what is already present, an upgrade run reports success and changes nothing.

The documented upgrade command pairs a refresh with that presence check, and pins the version tag. The README explains the pin: npx chisle can serve a cached copy of the package from a previous run, so @latest is what guarantees you get the new one.

npx chisle@latest --update

The behaviour is asymmetric by design. The update refreshes every agent that already has Chisle and installs it into none that do not, so adding a new agent still requires a normal install run. Given the release cadence visible in the repository, with three releases tagged on 2026-09-13 and the last push on 2026-09-15, this is the command you will use most often after the first install.

The downside story, and where the claims stop

Chisle's differentiator is not the compression ratio, it is the disclosure. The README states that across 20 measured tasks over two suites, the tools it calls specialists exceeded the baseline 6 and 8 times respectively, blowing up to 424% of baseline, while Chisle exceeded it once, capped at 173%. It says that failure was root-caused, fixed in the ruleset, and re-validated live at 93%, with the investigation committed to the repository.

Treat that as a claim to verify, not a result. You can check it: the README points at benchmarks/results/raw/ for the verbatim outputs and names benchmarks/results/2026-07-07-verify-rerun.md as the rerun record. The repository also carries benchmarks/ and a bench script in package.json that runs benchmarks/run-live.sh, so the harness is in the tree rather than described only in prose.

The honest limitation is scope. The headline 44% figure is described as a share of a bare model's output tokens on coding prompts, which is not the same as a 44% cut in your monthly bill, because input tokens, retries and your own prompt length are outside that measurement. The worst-case framing is the more defensible number, and the README presents it that way.

Two other boundaries are worth stating. Read, Edit and Write output is never compressed, so a session dominated by large file reads will see less benefit than one dominated by greps and command output. And the ruleset is a behavioural instruction to the model, not a guarantee, which is exactly why the project publishes runs where it lost.

Chisle against caveman and ponytail

The repository's topics list caveman, caveman-alternative, caveman2 and ponytail, and the README links a comparison document at docs/comparison.md under the heading why not caveman or ponytail. So the project positions itself against prompt-level conciseness tools rather than against agent frameworks.

The difference in approach is where the compression is applied. A prompt-only conciseness tool changes how the model writes. Chisle changes how the model writes, what code it chooses to produce, and what the model is allowed to read back from a tool call. The third axis is the one a prompt cannot reach, because it happens in a hook after the command has already run.

That extra surface is also the cost. A hook that rewrites tool output can change what the model sees, which is why the README carves out Read, Edit and Write and rebuilds compressed output into the tool's own shape. If you want a single instruction file with no hooks and no installer, a prompt-level tool is simpler and has fewer places to go wrong. If your bill is dominated by repeated tool output, Chisle's third axis is the reason to pick it.

Licence, maintenance and what an upgrade costs you

Chisle is MIT licensed, and package.json declares the same. That permits commercial use and modification, but it is worth reading the LICENSE file in the repository rather than relying on the licence identifier alone, particularly if you fork the ruleset into an internal tool.

Maintenance looks current. The last push was on 2026-09-15, the repository is not archived, and the three most recent releases, v3.2.0, v3.2.1 and v3.3.0, were all tagged on 2026-09-13. There is a CHANGELOG.md at the repository root, plus CONTRIBUTING.md, SECURITY.md and SUPPORT.md, which is more process documentation than most projects in this category carry.

The upgrade cost is low but not zero. Because plain npx chisle silently skips existing installs, the risk is believing you upgraded when you did not, and the mitigation is the @latest pin on the update command. Because the ruleset is injected into agent configuration, a version bump can change model behaviour mid-project. If that matters, pin a version, read CHANGELOG.md before bumping, and keep the --uninstall path in mind as the rollback. The README does not document a rollback to a previous version, only removal.

Editorial conclusion

Adopt Chisle if you run Claude Code or Pi heavily and want a reversible, single-command ruleset with published downside numbers, and if you accept that Read, Edit and Write tool output stays uncompressed. Skip it if you only use Cursor, Codex, Gemini or Copilot, because the input-side compression is documented as Claude Code and Pi only, and the rest get the always-on ruleset alone. Before trusting it, open benchmarks/results/raw/ and the linked rerun document, then run npx chisle --dry-run to see exactly which files it would touch in your setup.

Frequently asked questions

Official sources

1. JayPokale/Chisle on GitHub
2. License: MIT
3. Project website
4. README
5. Releases