HarnessTrim

One token policy for Claude Code, Codex, OpenCode, Hermes Agent and Pi.

HarnessTrim is a cross-harness control plane for coding agents: a portable skill pack, thin per-harness adapters, and a reproducible benchmark suite that together cut input tokens, output tokens, and noisy tool output, instead of optimizing just one of those layers the way existing tools do.

Full design rationale and phased roadmap: see PLAN.md.

Quick start

No checkout required — run the CLI straight from npm:

npx harnesstrim doctor                  # diagnose token waste in the current project
npx harnesstrim install claude --apply  # install an adapter (dry-run without --apply)
npm test 2>&1 | npx harnesstrim reduce  # slim noisy tool output through a pipe

The published package is a single self-contained bundle (no runtime dependencies); the skill pack and the Hermes/Pi plugin files ship inside it. bench is the one command that needs a checkout (it reads the repo's benchmark fixtures).

From a checkout (for development)

git clone https://github.com/giuliastro/HarnessTrim.git
cd HarnessTrim
pnpm install

# Run directly from a checkout on Linux, macOS, or Windows:
pnpm exec harnesstrim doctor            # diagnose token waste in the current project
pnpm exec harnesstrim reduce < output   # slim noisy tool output

# Install an adapter (dry-run first, then --apply):
pnpm exec harnesstrim install hermes --apply      # Hermes Agent plugin
pnpm exec harnesstrim install opencode --apply    # OpenCode runtime plugin
pnpm exec harnesstrim install claude --apply      # Claude Code PostToolUse hook
pnpm exec harnesstrim install codex --apply       # Codex skill pack + AGENTS.md instruction
pnpm exec harnesstrim install codex --hook --apply # optional experimental Bash PostToolUse hook
pnpm exec harnesstrim install codex --hook --global --apply # enable the hook for trusted projects
pnpm exec harnesstrim install pi --apply          # Pi extension

After installing an adapter, the harness automatically reduces tool output (test logs, git diffs, JSON responses, file listings, long prose briefings) before the model sees it.

The problem

In a coding agent, tokens are spent across several channels — and most tools only attack one of them:

Channel	What fills it	Who attacks it today
Tool output	test logs, `git diff`, grep, build output, big JSON, file reads	RTK (shell only)
Model output	the agent's own verbosity	Caveman
Thinking	reasoning tokens, billed as output	mostly nobody
Fixed instructions	always-loaded `CLAUDE.md`/`AGENTS.md`	skills (native)
Conversation history	everything that survives compaction	compaction (native)

Each existing tool moves one lever. The waste is spread across all of them, so single-lever tools leave most of the budget on the table. HarnessTrim's thesis: coordinate all five levers behind one policy, using the deterministic hook/skill primitives every modern harness already exposes.

Strategy: skill-first, adapter-second, measured

Three principles, in priority order:

Skill-first. The portable value is a pack of Agent Skills (the format every target harness already understands). Skills carry the policy; they cost almost nothing until invoked.
Adapter-second. Thin per-harness adapters translate one shared policy into each harness's native dialect (hooks, plugins, compaction events). Adapters are where the real work is — and where fragility lives — so they stay deliberately small and delegate all logic to the shared core.
Measured, not asserted. Every claim is backed by a reproducible benchmark. Competitors report self-measured numbers that don't compose; HarnessTrim ships the measurement harness itself.

flowchart TB
    subgraph Harnesses
        CC[Claude Code]
        CX[Codex]
        OC[OpenCode]
        HM[Hermes Agent]
        PI[Pi]
    end

    subgraph Adapters["Adapter layer (thin, per-harness)"]
        A1[hooks / plugins / compaction events]
    end

    subgraph Core["@harnesstrim/core (shared, deterministic)"]
        R[reducers]
        D[content dispatcher]
        P[policy presets]
        M[metrics / TrimEvent]
    end

    subgraph Skills["Portable skill pack"]
        S[delta-response · debug-log-slim · review-delta<br/>compact-handoff · scaffold-fast · delegate-bulk]
    end

    CC --- A1
    CX --- A1
    OC --- A1
    HM --- A1
    PI --- A1
    A1 --> Core
    Core --- Skills

    classDef done fill:#1f6f3f,stroke:#0d3,color:#fff;
    class CC,CX,OC,HM,PI,A1,R,D,P,M,S done;

Green = has a shipped adapter. All five targets (OpenCode, Codex, Claude Code, Hermes Agent, Pi) now have one, reusing the same core and skills.

The five levers

Lever	Mechanism	HarnessTrim component
Progressive disclosure	recurring instructions live in on-demand skills, not always-loaded files	skill pack + `doctor`
Tool-output reduction	a deterministic reducer slims noisy output before it reaches the model	`reducers` + adapter `tool.execute.after`
Thinking routing	match reasoning effort to task type (low for mechanical, high for architecture)	policy presets (advisory)
Subtask isolation	isolate/handoff noisy work instead of polluting the main context	`compact-handoff` + `delegate-bulk` skills, compaction hook
Observability	normalize what was actually saved into one schema	`TrimEvent` + `metrics`

How tool-output reduction works

The adapter intercepts tool results, the shared core decides what (if anything) to slim, and only the signal reaches the model. Reducers are deterministic and idempotent and never touch the cacheable prompt prefix — so they shrink cost without busting the prompt cache.

sequenceDiagram
    participant M as Model
    participant H as Harness
    participant A as HarnessTrim adapter
    participant C as core.reduceAuto
    M->>H: request tool call (e.g. run tests)
    H->>H: execute tool (1410 chars of output)
    H->>A: tool.execute.after(output)
    A->>C: reduceAuto(output)
    C-->>A: slimmed output + TrimEvent (124 chars)
    A-->>H: mutated output.output
    A->>A: append TrimEvent (telemetry, opt-in)
    H-->>M: slimmed output enters context

KPIs

What HarnessTrim optimizes for, and how each is measured:

KPI	Definition	Target	Source
Tool-output reduction	1 − (chars out / chars in) per reduced tool call	≥ 50% on noisy output	adapter telemetry, benchmark
Signal fidelity (recall)	must-keep signal lines surviving reduction / total must-keep	100% (bench fails otherwise)	Tier A benchmark (measured now)
Blended session reduction	total tokens saved / baseline session tokens	30–50% (model)	end-to-end benchmark (Tier B, planned)
Quality retention	task-success parity vs the untrimmed baseline	100% (no regressions)	Tier B benchmark
Cache preservation	share of reductions that leave the cacheable prefix untouched	100%	design guarantee (reducers only touch volatile output)
Coverage	share of noisy tool calls that a reducer actually matched	grow over time	telemetry (`reducer: null` = missed)
Overhead	added latency / tokens from the stack itself	negligible	reducers run locally, no tokenizer in-process

Savings: measured vs hypothesized

Two honesty tiers. Keep them separate.

Measured (real numbers today)

The token number alone is not the point — a reducer that drops the one line you needed would post a great percentage and ruin the context. So the benchmark measures both: token reduction and signal fidelity — of the lines that must survive (the error, the failing test, the assertion, the changed files, the summary), how many are kept. It also audits any dropped line that looks like signal. Headline: −63% tokens at 100% signal recall across the seed fixtures (pnpm run bench, no LLM). The bench fails loudly if signal recall drops below 100% or a signal-looking line is dropped.

Fixture	Reducer	Tokens	Reduction	Signal kept
jest, mostly-pass	test-output-slim	408 → 216	−47.1%	6/6
pytest, mostly-pass	test-output-slim	395 → 211	−46.6%	5/5
lockfile-heavy diff	git-diff-slim	939 → 183	−80.5%	4/4
JSON API array	json-output-slim	527 → 140	−73.4%	3/3
file listing (long)	file-listing-slim	508 → 190	−62.6%	3/3
daily briefing (prose)	generic-text-slim	196 → 150	−23.5%	3/3
Measured blend		2973 → 1090	−63.3%	24/24 (100%)

Each fixture's must-keep lines are annotated in benchmarks/src/run.ts, so "what survives" is explicit and reproducible, not a claim.

One live OpenCode session: a real bash test run was reduced 1410 → 124 chars (−91.2%) in the actual pipeline, with the FAIL line and summary preserved (see PLAN.md §9, Phase 2 hardening).

These cover the tool-output lever only, on selected inputs. They are not a session-wide claim.

Hypothesized (illustrative model, not measured)

To reason about the blended win we model a "typical" medium debugging session. These percentages are an engineering hypothesis to be validated by the Tier B benchmark — not results.

Baseline budget of an illustrative session, by channel:

pie showData
    title Baseline session token budget (illustrative)
    "Tool output" : 45
    "Conversation history" : 15
    "Model output" : 15
    "Thinking" : 15
    "Instructions (fixed)" : 10

Applying a conservative per-lever reduction to each channel:

Lever	Channel share	Assumed reduction of channel	Saved (% of total)
Tool-output reduction	45%	65%	29.3%
Thinking routing	15%	50%	7.5%
Model-output discipline	15%	40%	6.0%
Progressive disclosure	10%	50%	5.0%
Subtask isolation	15%	30%	4.5%
Blended			≈ 52%

xychart-beta
    title "Hypothesized token savings by lever (% of total session budget)"
    x-axis ["Tool output", "Thinking", "Model output", "Instructions", "Subtask iso."]
    y-axis "Saved % of total" 0 --> 35
    bar [29.3, 7.5, 6.0, 5.0, 4.5]

Scenario range (blended reduction of total session tokens):

Scenario	Assumptions	Blended reduction
Conservative	low per-lever rates, tool output only partially matched	~30%
Expected	the table above	~50%
Optimistic	noisy debugging session, high tool-output share	~65%

xychart-beta
    title "Blended session reduction — hypothesized scenarios (% of total tokens)"
    x-axis ["Conservative", "Expected", "Optimistic"]
    y-axis "Reduction %" 0 --> 70
    bar [30, 50, 65]

Why the model is plausible but unproven: the tool-output lever (the largest slice) is already backed by the measured −63%/−91.2% numbers above. The other levers are extrapolated from vendor documentation on reasoning-token billing, prompt caching, and progressive disclosure. The Tier B end-to-end benchmark (planned) will replace this section's hypotheses with measured, quality-checked numbers comparing vanilla harness vs harness + HarnessTrim.

Status

Phases 0–4 in progress. Shipped: reducers + benchmark, the 6-skill pack, adapters for OpenCode (runtime plugin, hardened in a live session), Codex (skills + AGENTS.md reduce-pipe, live-validated via codex debug prompt-input), Claude Code (PostToolUse reducer hook), Hermes Agent (transform_tool_result plugin, verified in a live session), and Pi (tool_result extension, verified live on 0.82.1), plus an MCP reduce server, the harnesstrim CLI (doctor / install / uninstall / capabilities / preset / metrics / reduce / hook / mcp / bench), telemetry, and policy presets. All five target harnesses now have an adapter. The CLI is published on npm (npx harnesstrim) as a single self-contained bundle. End-to-end Tier B runs on OpenCode (two tasks × two runs, quality retained in all 8) measured billed-token savings of ~2% on a tiny one-tool-call task and ~22–25% on a large-noisy-output task, with the prompt cache preserved — the blended win scales with noisy-output volume vs fixed overhead. A larger multi-model, multi-tool-call study is the remaining Tier B work. 175 tests passing, typecheck clean on all packages. Installers support narrowing (skills-only installs via --no-hook/--no-instructions, OpenCode --mode/--min-length/--tools baked into the wrapper), doctor/install/metrics emit --json, capabilities reports per-harness surfaces/write-sets as JSON, and uninstall reverses an install dry-run-first (only removing what HarnessTrim wrote, marker-guarded). Telemetry lines carry a schema version and a stable event id.

Known limitation (Claude Code): the PostToolUse reducer hook installs and fires correctly, but Claude Code (verified on 2.1.37 and 2.1.212) does not currently apply a hook's updatedToolOutput, so the slimmed output does not yet reach the model. This is a Claude-Code-side issue, not an adapter defect. Until it lands, use the MCP reduce tool (harnesstrim mcp) or the harnesstrim reduce pipe on Claude Code. OpenCode and Hermes reduction are verified working.

Layout

packages/core/              deterministic, idempotent reducers + content dispatcher + presets + metrics
packages/adapter-opencode/  OpenCode plugin: slims tool output + injects compaction handoff + telemetry
packages/adapter-codex/     Codex: skill bundle + AGENTS.md reduce-pipe instruction
packages/adapter-claude/    Claude Code: PostToolUse reducer hook + skill bundle
packages/adapter-hermes/    Hermes Agent: transform_tool_result reducer plugin (Python)
packages/adapter-pi/        Pi: tool_result reducer extension (TypeScript)
packages/mcp/               MCP server exposing a `reduce` tool (Codex, Claude Code, any MCP client)
packages/cli/               harnesstrim CLI: doctor, install, uninstall, capabilities, preset,
                            metrics, reduce, hook, mcp, bench
skills/                     portable Agent Skills (delta-response, debug-log-slim, review-delta,
                            compact-handoff, scaffold-fast, delegate-bulk)
benchmarks/                 Tier A micro-benchmarks: reducer token-reduction, no LLM involved
examples/opencode/          minimal .opencode/ local-plugin wrapper wiring the adapter (dry-run)

CLI

pnpm exec harnesstrim doctor [dir]            # diagnose token-waste signals in a project
pnpm exec harnesstrim install opencode [dir]  # OpenCode: local plugin wrapper in .opencode/ (dry-run)
pnpm exec harnesstrim install opencode --preset lean-debug --apply
pnpm exec harnesstrim install opencode --mode dryrun --apply      # preview without reducing
pnpm exec harnesstrim install opencode --min-length 2000 --apply  # leave outputs <2k chars untouched
pnpm exec harnesstrim install opencode --tools bash,read --apply  # reduce only bash + read output
pnpm exec harnesstrim install codex [dir]     # Codex: skills + AGENTS.md reduce-pipe (dry-run)
                                             # add --hook for experimental automatic Bash reduction
                                             # add --hook --global to install it once in ~/.codex
                                             # add --no-instructions for skills only
pnpm exec harnesstrim install claude [dir]    # Claude Code: skills + PostToolUse hook (dry-run)
pnpm exec harnesstrim install claude --no-hook --apply            # skills + CLAUDE.md, no hook
pnpm exec harnesstrim install hermes [dir]    # Hermes Agent: transform_tool_result plugin (dry-run)
pnpm exec harnesstrim install pi [dir]        # Pi: tool_result extension (dry-run)
pnpm exec harnesstrim uninstall claude [dir]  # reverse an install, dry-run (add --apply to remove)
pnpm exec harnesstrim capabilities            # per-harness capabilities / write-sets as JSON
pnpm exec harnesstrim preset list             # list policy presets
pnpm exec harnesstrim metrics [path]          # summarize adapter telemetry (JSONL)
pnpm exec harnesstrim doctor --json           # any command emitting a report accepts --json
pnpm exec harnesstrim metrics --json          # machine-readable telemetry summary
npm test 2>&1 | pnpm exec harnesstrim reduce  # pipe: slim noisy output (Codex/Claude/shell)
npm test 2>&1 | pnpm exec harnesstrim reduce --metrics .harnesstrim/metrics.jsonl  # + record the saving
pnpm exec harnesstrim bench                    # run the Tier A reducer micro-benchmark

doctor flags oversized always-loaded instruction files (CLAUDE.md/AGENTS.md/...), reports whether on-demand skills are used, and whether the OpenCode adapter is wired in.
install <harness> is dry-run until --apply. Each adapter uses that harness's native surface: OpenCode a tool.execute.after plugin, Claude Code a PostToolUse hook, Hermes a transform_tool_result plugin, Pi a tool_result extension, Codex an AGENTS.md reduce-pipe instruction. --preset (OpenCode) bakes a policy preset's adapter config in. Installs can be narrowed per harness: --no-hook/--no-instructions (Claude/Codex) install skills only, and OpenCode's --mode active|dryrun|off, --min-length <n>, and --tools <list> overrides are baked into the generated wrapper.
uninstall <harness> reverses an install. It is dry-run until --apply and only touches files HarnessTrim wrote: marker-guarded instruction regions, the skills it copied (including a now-empty parent skills dir), hook entries it added, and the OpenCode wrapper/dependency.
capabilities prints a JSON table of what this build supports per harness: adapter surface, available narrowing flags, and the exact write-set each installer owns.
doctor, install, and metrics accept --json for machine-readable output (scripts/CI).
reduce is the pipe-friendly reducer (RTK-style) shared across harnesses.
metrics aggregates the telemetry the adapter emits (off by default) into totals with per-reducer and per-harness splits, a pass-through rate (attempted-but-unchanged output — the evidence base for adding reducers) and reduction-error counts (attempts that grew the output). Pass-throughs are recorded whenever telemetry is on; opt out with HARNESSTRIM_TRACK_PASSTHROUGH=0. Lines carry a schema version and a stable event id; only character counts are recorded, never tool payloads.

Try it

pnpm install
pnpm run test        # unit tests (core reducers + dispatcher + adapter hooks)
pnpm run typecheck   # type-check every package against real dependency types
pnpm run bench       # Tier A micro-benchmark: token reduction on fixed fixtures

The package bin is cross-platform: the same pnpm exec harnesstrim … command works from Linux, macOS, and Windows. To expose it globally, use your package manager's standard linking command:

pnpm --filter harnesstrim link --global
harnesstrim --help

Using it in your harness

Each harness has a one-command installer (dry-run until --apply). Use pnpm exec harnesstrim … from a checkout, or harnesstrim … after linking the package globally. The installer preview is separate from each adapter's runtime reduction mode below.

Reduction mode & telemetry (per adapter)

Once installed, does the adapter actually slim output, and does it record metrics? This differs by harness. "dry-run mode" here means the adapter logs what it would slim without changing anything.

Harness	Reduces after install?	Make reduction permanent	Telemetry (metrics)
OpenCode	Yes — the local plugin wrapper defaults to `mode: "active"`	permanent once installed; set `mode: "dryrun"` in `.opencode/plugin/harnesstrim.ts` to only preview	on when installed via the CLI (the generated wrapper sets `telemetry: true` → `.harnesstrim/metrics.jsonl`), read with `harnesstrim metrics <path>`
Claude Code	Via the pipe / MCP — the `PostToolUse` hook is spec-correct but Claude Code 2.1.37–2.1.212 don't apply `updatedToolOutput`, so `install claude` also adds a `CLAUDE.md` instruction to pipe noisy output through `harnesstrim reduce` (slims in-shell before the model sees it) and registers the MCP `reduce` tool.	keep the CLAUDE.md instruction / MCP registration	on — the pipe instruction uses `harnesstrim reduce --metrics .harnesstrim/metrics.jsonl`; the MCP server records too (`--metrics`)
Codex	Default: model pipes through `harnesstrim reduce` or calls MCP `reduce`. Experimental `--hook`: automatically reduces supported Bash results.	`AGENTS.md` / MCP, project `--hook`, or global `--hook --global` for trusted projects	hook telemetry is written per project to `.harnesstrim/metrics.jsonl`; MCP/pipe telemetry is manual
Hermes	No — starts in `dryrun`	set `HARNESSTRIM_MODE=active` in Hermes' persistent environment	off; set `HARNESSTRIM_TELEMETRY=1`, then run `harnesstrim metrics`
Pi	No — starts in `dryrun`	set `HARNESSTRIM_MODE=active` persistently in Pi's environment	none yet (the extension only reduces)

Guidance: for the dry-run adapters (Hermes, Pi) keep the default while you confirm it slims the right things (watch stderr for [harnesstrim] dryrun ... lines), then flip to active persistently. Telemetry is off by default everywhere; enable it only where you want a metrics trail.

Telemetry lines are JSONL with a schema version and a stable event id, e.g.:

{"schemaVersion":1,"eventId":"…","ts":"2026-08-01T…","harness":"opencode","tool":"bash","reducer":"test-output-slim","beforeChars":1410,"afterChars":124,"beforeTokens":null,"afterTokens":null}

beforeTokens/afterTokens are null unless the emitting path has real counts (no tokenizer runs in the harness process). harnesstrim metrics <path> aggregates these; legacy schemaVersion-0 lines are still accepted.

OpenCode

harnesstrim install opencode /path/to/project --apply

Installs a local plugin wrapper at .opencode/plugin/harnesstrim.ts (plus .opencode/package.json, whose dependency it installs) and removes any stale adapter entry from opencode.json. This is required because OpenCode's plugin config is a string array that can't pass options — the wrapper is how mode/telemetry are applied. It reduces tool output automatically via tool.execute.after, defaults to mode: "active" with telemetry on (→ .harnesstrim/metrics.jsonl); set mode: "dryrun" in the wrapper to preview first. Reload OpenCode after installing so it loads the plugin. Details: packages/adapter-opencode, example: examples/opencode.

Codex

harnesstrim install codex /path/to/project --apply

Copies the skill pack into .codex/skills and adds a reduce-pipe instruction to AGENTS.md. The agent then slims noisy output by piping it (pytest 2>&1 | harnesstrim reduce), so harnesstrim must be on PATH. For a first-class, native tool instead of a shell pipe, register the MCP reducer:

codex mcp add harnesstrim -- harnesstrim mcp

For experimental automatic reduction of simple Bash results, add the opt-in hook:

harnesstrim install codex /path/to/project --hook --apply

It writes a project-local .codex/hooks.json entry for PostToolUse (Bash only) and records reductions in .harnesstrim/metrics.jsonl. Codex currently lacks a supported in-place tool-output replacement API, so the hook uses Codex's documented block-and-replace fallback. It is deliberately opt-in: it does not intercept every shell execution or non-shell tools, and you must review/trust the hook in Codex before it runs.

To enable the same opt-in hook for every trusted project without copying skills or changing any project AGENTS.md, install it once in your Codex home:

harnesstrim install codex --hook --global --apply

This writes ~/.codex/hooks.json. Because Codex runs the hook with the session's project directory as its working directory, each project's metrics still land in that project's .harnesstrim/metrics.jsonl.

Details: packages/adapter-codex, packages/mcp.

Claude Code

harnesstrim install claude /path/to/project --apply

Installs three things (so harnesstrim must be on PATH):

The skill pack → .claude/skills.
A PostToolUse hook (matcher Bash) → .claude/settings.json. Caveat: the hook is spec-correct and fires, but Claude Code (2.1.37–2.1.212) does not currently apply a hook's updatedToolOutput, so on its own it does not yet reduce what the model sees (a Claude-Code-side issue — see Status). It stays for when Anthropic fixes that.
A CLAUDE.md reduce-pipe instruction — the effective path today. It tells the model to pipe noisy commands through harnesstrim reduce --metrics .harnesstrim/metrics.jsonl, which slims output in the shell before it reaches the model (real token saving) and records the saving.

For a native, always-available tool, also register the MCP reducer (records metrics too):

claude mcp add-json harnesstrim-reduce \
  '{"command":"harnesstrim","args":["mcp","--metrics","~/.harnesstrim/metrics.jsonl"]}' --scope user

Reload Claude Code after installing. Details: packages/adapter-claude, packages/mcp.

Hermes Agent

harnesstrim install hermes --apply                    # ~/.hermes/plugins/harnesstrim/
harnesstrim install hermes /path/to/project --apply   # project-local .hermes/plugins/

install hermes --apply refreshes the Python plugin, enables it with hermes plugins enable harnesstrim when the Hermes CLI is available, and verifies recognition via hermes plugins list — reporting "on disk" separately from "loaded by the running gateway". The no-argument form targets the user-level Hermes home; pass an explicit directory only for a project-local or alternate-profile installation.

Hermes loads plugin bundles at gateway startup, so after a refresh run hermes gateway restart (or systemctl --user restart hermes-gateway) from a shell outside the gateway process — a gateway cannot safely replace itself from inside an active agent turn. It starts in dryrun; set HARNESSTRIM_MODE=active to reduce and HARNESSTRIM_TELEMETRY=1 to record metrics. The plugin handles terminal, read_file, web_extract, search_files, browser_snapshot, and vision_analyze, preserving each tool's result schema. Run harnesstrim metrics to read the active Hermes profile's telemetry. It detects test output, git diffs, long JSON arrays, file listings, and prose briefings via the shared dispatcher. Details: packages/adapter-hermes.

Pi

harnesstrim install pi --apply             # <project>/.pi/extensions/harnesstrim/
harnesstrim install pi ~ --apply           # global: ~/.pi/... (pass your home dir)

Copies a TypeScript extension that hooks Pi's tool_result and slims noisy output via harnesstrim reduce (so harnesstrim must be on PATH). It starts in dryrun; set HARNESSTRIM_MODE=active in Pi's environment to reduce. Verified live on Pi 0.82.1: the extension ships as harnesstrim/index.ts because Pi's loader only auto-discovers a subdirectory extension via index.ts (or a package.json with a pi.extensions field); dryrun logs [harnesstrim] dryrun ... to stderr, active mode replaces text chunks (a 13902-char JSON array reached the model as 6 lines), output passes through when harnesstrim is missing, and already-reduced output is never reduced twice. Details: packages/adapter-pi.

Any MCP-capable harness

harnesstrim mcp starts a stdio MCP server exposing a reduce tool. Register it with any client that speaks MCP (Codex, Claude Code, …). See packages/mcp.

License

MIT — see LICENSE.

Name		Name	Last commit message	Last commit date
Latest commit History 77 Commits
.github/workflows		.github/workflows
benchmarks		benchmarks
docs		docs
examples/opencode		examples/opencode
packages		packages
scripts		scripts
skills		skills
.gitattributes		.gitattributes
.gitignore		.gitignore
AGENTS.md		AGENTS.md
LICENSE		LICENSE
PLAN.md		PLAN.md
README.md		README.md
package.json		package.json
pnpm-lock.yaml		pnpm-lock.yaml
pnpm-workspace.yaml		pnpm-workspace.yaml
tsconfig.base.json		tsconfig.base.json

Navigation Menu

Repository files navigation

HarnessTrim

Quick start

From a checkout (for development)

The problem

Strategy: skill-first, adapter-second, measured

The five levers

How tool-output reduction works

KPIs

Savings: measured vs hypothesized

Measured (real numbers today)

Hypothesized (illustrative model, not measured)

Status

Layout

CLI

Try it

Using it in your harness

Reduction mode & telemetry (per adapter)

OpenCode

Codex

Claude Code

Hermes Agent

Pi

Any MCP-capable harness

License

About

Releases

Packages

Contributors

Languages

Folders and files

Latest commit

History

Repository files navigation

HarnessTrim

Quick start

From a checkout (for development)

The problem

Strategy: skill-first, adapter-second, measured

The five levers

How tool-output reduction works

KPIs

Savings: measured vs hypothesized

Measured (real numbers today)

Hypothesized (illustrative model, not measured)

Status

Layout

CLI

Try it

Using it in your harness

Reduction mode & telemetry (per adapter)

OpenCode

Codex

Claude Code

Hermes Agent

Pi

Any MCP-capable harness

License

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages