honey

🍯 Honey (I Shrunk the AI)

Write less code and say less about it. Honey (I Shrunk the AI) by GreenPT is a cross-tool coding skill that cuts AI coding-agent token usage and LLM API costs — making agents emit less code and less prose without losing correctness. It works with Claude (claude.ai and the API), Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, Windsurf, Cline, OpenClaw, oh-my-pi, Kiro, Kilo Code, and Hermes Agent. Three independent levers, applied reflexively:

1. Less code — YAGNI first. Walk a ladder (does it need to exist? → stdlib → language native → existing dependency → one line → minimum block) and stop at the first rung that works. The cheapest line is the one you never write.
2. Less prose — drop the wind-up, the hedging, the narration of code that already speaks for itself. Answer first.
3. Denser agent-to-agent handoffs — when the reader is another agent, not a human, hand it the most token-efficient format it parses losslessly (compact / columnar JSON, or ESON). Cuts handoff size ~in half at zero loss of recovery. Fires only here — never as a user-facing answer.

Honey combines what Ponytail (minimal code) and Caveman (terse prose) do separately, then goes further:

• Auto-intensity — lite / full / ultra chosen reflexively from the request, with no deliberation tax (it never spends reasoning tokens deciding how to comply — that would defeat the purpose on reasoning models).
• Safety carve-outs — input validation, error handling, auth, secrets, migrations, deletes, and anything you explicitly asked for are never compressed. Lazy ≠ broken.
• A skill family, not one prompt — an always-on core plus on-demand satellites (review, eco, gain, compress) and a hive of read-only subagents that return compressed handoffs. See Skills & subagents.

Why

Volume is cost. In agentic coding sessions, the volume of generated code and prose is what runs up the bill — and most of it is waste.

This repo ships a reproducible benchmark (bench/) so you don't have to take the numbers on faith: 23 tasks across three kinds of work — baseline vs Caveman vs Ponytail vs Honey — same model, same prompts, only the skill changes. Correctness is objective (unit tests, structural / accessibility checks, and lossless round-trip recovery for agent handoffs); quality is scored by a 4-model cross-family judge panel (median of Opus 4.8 + Sonnet 4.6

• Haiku 4.5 + GPT-5.5) under a neutral rubric that says nothing about length, so a terse skill gets no thumb on the scale. The figures below are the committed results (Claude Opus 4.8, 3 runs each) — run cd bench && npm run bench to reproduce.

Every number is a paired per-task delta vs baseline — runs collapse by median, tasks pair up, and the figure is the median of those paired deltas with a two-sided Wilcoxon p. Not a ratio of arm totals: that is dominated by whichever task happens to be longest, and it is how token-saving tools end up publishing numbers nobody can reproduce. Endpoints and the run ladder are pre-registered in bench/METHODOLOGY.md.

On Claude Opus 5 (23 tasks × 3 runs, 207 cells, zero refusals or truncation — full-opus5-lean):

	Δ LOC	Δ output	Δ cost	Tests
Honey	−71% (p<0.001)	−38% (p<0.001)	−24% (p<0.001)	100%

Honey is the only arm with no failing cell — the no-skill baseline fails four. And the cut is larger on the newer model, not smaller: −71% LOC on Opus 5 against −39% on Opus 4.8. That runs against the 2026 prompting guidance that newer models need less instruction, which we tested directly and rejected — see METHODOLOGY.md.

A single blended number hides the story, because the levers fire differently per task type. Honey on Opus 4.8, where the full competitor set was run — Δ LOC measures Lever 1 directly, Δ output measures the tokens (code and the prose around it):

Task tier	tasks	Δ LOC	Δ output
Code	14	−53% (p=0.002)	−39% (p=0.007)
User-facing	7	−23% (p=0.022)	−7% (p=0.673 — a tie)
Agent-to-agent	2	— (no code)	−49% (n=2, no p)
whole suite	23	−43% (p<0.001)	−29% (p=0.020)

Against the competitors on the whole suite (judge win/loss/tie by exact sign test):

Variant	Δ LOC	Δ output	Judge W/L/T	Tests
Caveman	−28% (p<0.001)	−22% (p<0.001)	3/16/2, p=0.004	94%
Ponytail	−33% (p=0.028)	−7% (ns, p=0.267)	1/19/1, p<0.001	90%
Honey	−43% (p<0.001)	−29% (p=0.020)	8/11/2, p=0.648	100%

• Code — the deepest cut (−39%) at 100% unit-test pass. Ponytail's mandatory self-check inflates trivial code (+60% on Opus, +92% on GPT-5.5).
• User-facing — the carve-out keeps Honey from compressing polish: the output delta here is a statistical tie, and Honey holds the only 100% accessibility pass while Ponytail drops to 81% on the structural/a11y checklist.
• Agent-to-agent — under adversarial relay queries (ordinal, nested, absence, cross-field count) Honey is the only variant that stays 100% lossless while roughly halving handoff size; Caveman and Ponytail compress harder and lose recovery (67% / 50%). Its biggest, cleanest win — on 2 tasks, so no p-value.
• Quality is a tie overall (p=0.648) — fewer tokens at no measurable quality cost, not higher quality. But the whole-suite tie is two opposing effects cancelling: on Opus, Honey wins user-facing 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 the unit tests, so that is a stylistic penalty for terseness, not a correctness one. Neither effect replicates on GPT-5.5 (p=0.375 / p=1.000), so treat the code-judge dip as suggestive, not established. Caveman's judge mean also ties baseline exactly — but paired, it loses 16 of 23 tasks (p=0.004). Means hide that; sign tests don't.
• The dollar saving is unproven at this sample size. −21% on Opus is p=0.104 — not significant on 23 tasks. Output volume is down; the bill is not yet a claim.

The output cut holds on GPT-5.5 (−20%, p=0.004; full two-provider table in bench/README.md), but there cost comes out +14% (ns) because no prompt caching engaged in that arm, so every task paid the skill prompt fresh. Honey is the only variant with no test regressions across all three tiers on Opus.

End-to-end agentic measurement (Cline harness)

npm run bench makes one API call per task — clean for isolating the output lever, but it never exercises an agent loop, tool schemas, or multi-turn context growth, where a real agent's token bill actually lives. bench/src/cline-bench.js (npm run bench:cline) runs each task through the Cline CLI headless, so the measured tokens are end-to-end agentic — harness prompt and every loop iteration included. Honey is injected as a Cline rule, recommended as the per-turn-cheap skills/honey/cline-rule.md (the operational core; the full SKILL.md re-sent every turn inflates input). See bench/README.md.

ESON — Efficient Structured Object Notation

Honey includes ESON, a zero-dependency, schema-first format for agent handoffs. Repeated record keys are emitted once; declared row counts catch truncated messages; JSON-compatible cells preserve types. ESON is developed in its own repo — Green-PT/honey-eson: the normative spec, JS + Python reference implementations, conformance vectors, the canonical LLM primer, the Honey Wire Profile, and negotiation. Honey vendors the codec in eso/.

The reproducible ESON/TOON/JSON benchmark measures bytes, two tokenizer estimates, codec speed, and lossless recovery across five agent handoff shapes. Run it with npm run bench:eso.

printf '%s' '{"from":"reviewer","findings":[{"sev":"H","issue":"expired token"}]}' | eson encode
eson decode < handoff.eson

CCR — for huge, redundant array tool output

ESON is lossless, for handoffs where every row matters. CCR (Compress-Cache-Retrieve) is the lossy-but-recoverable lever for the opposite case: a long uniform array you must read but mostly skim — logs, scan results, event streams. It keeps an informative sample (endpoints, anomalies/change-points, head/tail), caches the dropped rows locally, and leaves a <<ccr:HASH N_rows_offloaded>> sentinel. Nothing is lost — retrieve restores the original by hash on demand.

some-tool | eson crush          # → sampled view + sentinel; originals cached in .honey-ccr/
eson retrieve <hash>            # → the full original array, verbatim

Validated on a 90-row log (opus-4.8 + gpt-5.5): −82% tokens, crushed-only 96% answer accuracy, 100% with retrieve — and the lone crushed miss was a refusal, not a hallucination. Benches: npm run bench:ccr (tokens) and npm run bench:ccr:comprehension (quality). The honey-ccr skill tells the agent when to reach for it.

Known limitation (upstream): Claude Code builds affected by anthropics/claude-code#68951 (a regression present since ~2.1.121, still open) ignore a PostToolUse hook's updatedToolOutput for the built-in Bash tool. On those versions the entry-time hook runs and stashes the original, but the model still receives the raw uncompressed output — honey warns once at session start when it detects an affected version. Piping explicitly (some-tool | eson crush) is unaffected: compression happens before the output leaves the tool. Separately, the hooks need Node >= 14 on the PATH Claude Code spawns them with — desktop-app sessions inherit the launchd PATH, not your shell profile, so a stale /usr/local/bin/node is common; the hook now warns instead of failing silently.

PX — image-rendered reads for huge dense read-only bulk

The intuition: sending a file as text pays per character; sending an image pays per pixel, no matter how much text is crammed into it. So a "photo of the page" costs ~5× less than the page itself — and reading it has photo problems: the gist survives, an exact serial number might not.

Concretely: dense text packs ~3 chars per image-token vs ~1 as text. PX exploits the gap on the read path: when the agent must skim something huge it will never edit (vendored code, a large diff, docs), it renders it to PNG pages with pxpipe's export and Reads the images instead of the text.

npx pxpipe-proxy export --json --out "$TMPDIR" src/   # → page-*.png + factsheet.txt + token report

Measured: up to −85% tokens on a single read. Repo-corpus bench (npm run bench:px, results): −79…85%, −82% average (26.4k Claude text tokens → 4.8k image est.); ~−75% all-in per read after the factsheet + report overhead; pxpipe's own end-to-end proxy bill measures −59…70% at whole-workload level.