Honey for Devs: A Coding Skill That Cuts Agent Token Spend, With Its Own Benchmark Attached

The problem Honey for Devs targets: volume, not correctness

Agentic coding sessions bill by volume. The agent writes the function, then narrates the function, then restates the narration in a summary, then hands a verbose blob to the next agent in the chain. Honey for Devs is aimed at that volume rather than at model choice or context management. The README frames it as "Write less code and say less about it" and splits the work into three levers: less code through a YAGNI ladder, less prose by dropping the wind-up and the hedging, and denser handoffs when the reader is another agent rather than a human. The intended user is someone already running an agent loop for real work, not someone evaluating a model. If your sessions are short and interactive, the skill has little surface to act on.

Three levers and the carve-outs that keep them from breaking code

Lever one is a ladder the agent walks before writing anything: does the code need to exist at all, then the standard library, then a language native, then an existing dependency, then one line, then the minimum block. The README states the agent stops at the first rung that works. Lever two removes prose that restates code. Lever three only fires when the reader is another agent: the handoff gets compact or columnar JSON, or the project's own ESON format described in eso/SPEC.md.

The carve-outs matter more than the levers. Input validation, error handling, authentication, secrets, migrations, deletes, and anything the user explicitly asked for are never compressed. That is the design answer to the obvious objection that a terseness skill produces lazy code. Intensity is picked as lite, full or ultra from the request itself, and the README is explicit that the skill does not spend reasoning tokens deciding how to comply, because on a reasoning model that deliberation would cost more than it saves. I think that is the correct call, and it is also the reason intensity selection is hard to audit from the outside: there is no planning step to inspect.

Installing Honey for Devs and a first real session

The repository ships INSTALL.md and two installers at the top level, install.sh and install.ps1, plus a bin entry named honey-install. The README does not reproduce the installer flags, so read INSTALL.md before running anything. For a quick look at the package itself, npm exposes the same binaries.

npm install -g honey-skill
honey-install

The package.json bin map declares honey-install, eso, eson and honey-usage. The eso and eson names both point at bin/eso.js, so they are the same command under two names.

honey-usage

That command is the one to run after a session, and it is the only way to see whether the skill is actually firing in your setup, since the skill itself produces no visible marker in the agent's output.

To reproduce the numbers rather than trust them, the bench scripts are the entry point. The README gives this example directly.

cd bench && npm run bench

The package.json scripts list bench:eso, bench:formats, bench:ccr, bench:px, bench:ccr:comprehension, bench:memory and bench:all, with bench:all chaining bench:formats, bench:ccr and bench:ccr:comprehension. Note that the README's npm run bench is not one of the declared script names, so check bench/ before assuming the exact command resolves.

Honey is distributed as a skill family rather than a single prompt file: an always-on core plus on-demand satellites named review, eco, gain and compress, plus a hive of read-only subagents that return compressed handoffs. The repository carries per-tool directories for the tools it supports, including .claude-plugin/, .cursor/, .clinerules/, .codex-plugin/, .windsurf/, .kiro/, .kilo/, .hermes/ and .openclaw/, with a build step at npm run build that regenerates rules and the OpenClaw and Hermes skill files. If you edit anything under skills/, run npm run check, which runs the rules build in check mode.

Reading the benchmark without taking it on faith

The bench/ directory is the reason to take this project seriously, and also the reason to slow down. The README describes 23 tasks across three tiers (code, user-facing, agent-to-agent), four arms (baseline, Caveman, Ponytail, Honey), the same model and the same prompts, with only the skill changing. Correctness is objective: unit tests, structural and accessibility checks, and lossless round-trip recovery for handoffs. Quality is scored by a four-model judge panel under a rubric that says nothing about length.

The methodology choice worth noting is that every figure is a paired per-task delta rather than a ratio of arm totals. The README argues the ratio approach is dominated by whichever task happens to be longest, which is a fair criticism of how token-saving tools usually publish numbers. Results are collapsed by median across runs and reported with a two-sided Wilcoxon p.

The headline table is on Claude Opus 5: minus 71% LOC, minus 38% output, minus 24% cost, all at p<0.001, with 100% tests passing across 207 cells. On Opus 4.8, where the full competitor set ran, the whole-suite figures are minus 43% LOC (p<0.001) and minus 29% output (p=0.020), against minus 28% and minus 22% for Caveman and minus 33% and minus 7% for Ponytail. The agent-to-agent tier is the cleanest result: Honey is described as the only variant staying 100% lossless while roughly halving handoff size, with Caveman and Ponytail at 67% and 50% recovery. That tier has two tasks, so there is no p-value, and the README says so.

Where the numbers get thin and where the skill is the wrong tool

The README is more honest about its weak points than most, and the weak points are real. The cost saving is not established: minus 21% on Opus is p=0.104 at 23 tasks, and the README states plainly that output volume is down while the bill is not yet a claim. If your reason for adopting Honey is a specific monthly invoice reduction, that is the claim to be sceptical of.

The user-facing tier is the other soft spot. The output delta there is minus 7% at p=0.673, which the README calls a tie. The carve-outs are doing the work, not the compression. If your agent spends its time on UI copy, accessibility polish and design detail, Honey's lever one has almost nothing to grab.

Quality is also a tie overall at p=0.648, and the README explains why that tie is two effects cancelling. On Opus, Honey wins the user-facing judge 6/0/1 (p=0.031) and loses the code judge 2/11/1 (p=0.022), on tasks where every variant passes 100% of unit tests. That is a stylistic penalty for terseness rather than a correctness one, and the README notes neither effect replicates on GPT-5.5, so it treats the code-judge dip as suggestive. I would go further: a 2/11/1 loss on code tasks means reviewers who care about readable diffs may push back, and the benchmark cannot tell you whether your team will.

One more thing the README does not document: rollback. There is no described uninstall path for the skill files the installer writes into per-tool directories, so plan on reviewing install.sh or INSTALL.md before running it on a machine you care about.

How Honey differs from Caveman and Ponytail

Honey's README positions it explicitly against two earlier projects, and the comparison is concrete. Caveman targets terse prose; Ponytail targets minimal code. Honey combines both and adds the handoff lever, which neither of the others has. The benchmark numbers back the split: Caveman cuts LOC by 28% but only 22% of output, Ponytail cuts LOC by 33% but only 7% of output, and Honey cuts 43% and 29%. Ponytail's mandatory self-check is also described as inflating trivial code by 60% on Opus and 92% on GPT-5.5, which is a design cost Honey avoids by not requiring a self-check step.

The trade-off runs the other way too. Caveman and Ponytail compress handoffs harder and lose recovery, at 67% and 50%. Honey gives up some compression to stay lossless. If your pipeline can tolerate a lossy handoff and you want the smallest possible payload, Honey is not the right pick. If a dropped field breaks a downstream agent, the lossless property is the whole reason to choose it.

Licence, maintenance and what an upgrade actually costs

Honey for Devs is MIT licensed, and the repository carries a NOTICE file alongside LICENSE, which usually means bundled third-party material. Read NOTICE before redistributing. MIT is permissive, but it is not legal advice and I am not giving any; if you vendor the skill into a commercial product, have someone check NOTICE.

The last push was on 2026-09-07, so the repository is not archived and is being touched. The recent releases listed are v1.1.0 (Honey harness plus ESON) on 2026-07-03 and v1.3.1 (benchmarked output discipline) on 2026-08-03, with package.json at 1.3.1. Upgrade cost is concentrated in the build step: skills are generated into per-tool rule files by npm run build, and npm run check verifies the generated output matches. If you fork the skills, that check is what stops your rule files drifting from the source. The dev dependencies pin @anthropic-ai/tokenizer, @toon-format/toon, gpt-tokenizer and pxpipe-proxy, so reproducing the benchmark pulls a tokenizer stack and a proxy package, not just the skill.

Editorial conclusion

Install Honey for Devs if you run long agentic coding sessions in Claude Code, Cursor, Codex or Cline and you already accept terser diffs. Do not install it if your work is mostly user-facing UI, where the README reports the output delta as a statistical tie and the carve-outs do most of the work. Before trusting the numbers, open bench/METHODOLOGY.md and check the pre-registered endpoints, then run cd bench && npm run bench yourself on the model you actually use. The dollar saving is the one claim the README explicitly declines to make: -21% on Opus at p=0.104.

Frequently asked questions

Official sources

1. Green-PT/honey-for-devs on GitHub
2. License: MIT
3. Project website
4. README
5. Releases