OpenClacky: a Ruby AI agent that trades tool count for token spend

The bill, not the feature list, is what OpenClacky targets

Most open-source agents compete on how much they can do. OpenClacky competes on what the doing costs. The README frames the project as matching Claude Code on capability at comparable cost while saving against other open-source agents, and it puts a number on that claim: roughly 50 percent against OpenClaw and about one third of Hermes. The audience is anyone paying per token for an agent that runs long sessions, which in practice means teams routing work through BYOK API keys rather than a flat subscription. The project is written in Ruby, requires Ruby 3.1.0 or newer, and is MIT licensed, so the harness itself is not the thing you are buying. The token bill is. That reframing matters because it changes which design decisions look clever and which look like bloat. A 52-tool agent is not more capable in this view; it is a larger schema sent on every turn.

Sixteen tools and one meta-tool that hides the rest

The core mechanism is subtraction. OpenClacky exposes 16 core tools, against 40-plus in Claude Code, 23 in OpenClaw and 52 in Hermes according to the comparison table. Everything that would otherwise be a tool is pushed into the skill ecosystem and reached through a single invoke_skill meta-tool. The README states the reasoning directly: tool count is not the metric, task completion rate is. This is a real architectural bet, and it has a cost the README does not dwell on. A fixed tool schema is predictable for the model. A meta-tool means the model must first decide which skill to invoke, then invoke it, then interpret the result. That is at least one extra reasoning step per capability, and the savings only materialise if the skill descriptions are good enough for the routing decision to be correct on the first try. When routing fails, you pay for the failed call plus the retry, which is exactly the kind of overhead a small tool set is supposed to avoid.

Cache strategy: never mutate the system prompt, compress after inserting

The cost argument rests on cache behaviour rather than on doing less work. The README describes sessions that never restart, double cache markers, and a technique it calls Insert-then-Compress, where the system prompt is never mutated so that compression still reuses the cache. The stated result is a cache hit rate near 100 percent on the project's own workloads. There is also an idle-time behaviour: while the agent is unattended, it compresses long context in the background and pre-warms the cache, which the README says cuts cold-start first-token cost by more than half. The design constraint here is worth naming. If the system prompt must stay byte-identical across turns for the cache to hold, then anything that would naturally belong there (project-specific instructions, changing environment details) has to be injected elsewhere in the conversation. That is a discipline the harness enforces on itself, and it is the kind of constraint that tends to leak into how you structure your own skills.

Installing it: gem, one-line script, or container on port 7070

The README gives several paths. The Ruby route is gem install openclacky with Ruby >= 3.1.0. The scripted route on Mac and Ubuntu is /bin/bash -c "$(curl -sSL https://raw.githubusercontent.com/clacky-ai/openclacky/main/scripts/install.sh)", with a PowerShell equivalent for Windows. Desktop installers are offered as .dmg for macOS and .exe for Windows 10 2004+ and Windows 11. Once installed, openclacky starts the interactive agent in the current directory and openclacky server starts the Web UI on http://localhost:7070. The Docker image is published to GHCR on version tags, so docker pull ghcr.io/<owner>/openclacky:latest works, or you can pin a release such as 1.5.3. The container takes one documented environment variable, CLACKY_ACCESS_KEY, which protects the Web UI; an empty value means public mode, and the README notes the variable must be present when binding 0.0.0.0. On Linux the documented run command uses --network=host so the agent can reach Chrome's remote debugging port on the host. On macOS and Windows, the README states --network=host is not supported and browser automation may be limited, so the port-mapped form (-p 7070:7070) is a partial substitute, not an equivalent one.

Skills as the extension surface, and what self-evolution actually means

Skills carry the weight that tools would otherwise carry. They are invoked with a leading slash, support fuzzy search, and can be created in natural language: the agent drafts SKILL.md, breaks the task into steps and runs validation. The README also describes self-evolution, where after each run the agent updates the skill from execution context and results so the next call is more stable. That is the most consequential claim in the document and the least specified. An agent that rewrites its own instructions after every run has no described review gate, no versioning scheme and no rollback path in the material provided. Skills are also described as compatible with Claude Skills and Markdown Pack formats, and as monetizable through packaging, encrypted distribution, license management and creator-set pricing. If you plan to sell skills, the licence question is not the MIT licence on the harness; it is whatever terms you attach to the packaged skill, and that is outside what this repository settles.

The cost table is internal, and the README says so

The relative cost figures (0.8x for OpenClacky, 1.0x for Claude Code as baseline, roughly 1.5x for OpenClaw, roughly 3x for Hermes) carry a footnote: numbers are averages measured on internal common agent tasks using Claude Code as the baseline, and full benchmark reports will be published on GitHub. Until those reports exist, the central claim of the project is not independently checkable. The same applies to the near-100-percent cache hit rate and the claim that cold-start first-token cost drops by more than half. None of this makes the claims false. It makes them unverified, and the honest position is to treat the tool-count comparison, which is a fact about the code, as much stronger evidence than the cost ratios, which are a fact about someone's task mix. There is also a structural reason to expect the ratio to move: cache pricing, model routing and task length all shift the denominator, and a harness tuned for one provider's cache semantics may behave differently on a compatible relay.

Where a smaller tool set is the wrong answer

The 16-tool design assumes a capable model that can route through a meta-tool reliably. Point it at a weaker or heavily quantised model and the routing step becomes the failure point: the model picks the wrong skill, or invokes invoke_skill with a description that does not match any registered skill, and you spend turns recovering. A harness with 52 explicit tools gives a weaker model far less room to make that mistake, because the capability is named in the schema rather than inferred. The same trade-off appears in the container story. The Linux instructions rely on host networking to reach Chrome's debugging port; on macOS and Windows that path is closed, so a browser-automation workflow that works on a Linux host is not portable to a laptop container. And the cache strategy depends on session continuity. If your workflow is a series of one-shot invocations with fresh sessions, the Insert-then-Compress and pre-warm machinery has little to reuse, and the cost advantage narrows toward whatever the underlying model charges. For a comparison point, Claude Code is closed-source and Anthropic-only, which removes model choice entirely but also removes the BYOK configuration surface; OpenClacky's answer is to let you point at any OpenAI-compatible endpoint and route subtasks to a cheaper model, which is a genuine difference in approach rather than a feature checkbox.

Upgrade cadence and what the MIT licence does and does not cover

Releases are frequent. The three most recent tags are v1.5.14, v1.5.13 and v1.5.12, dated roughly one week apart, and the repository is not archived. That cadence is good for fixes and bad for anyone pinning behaviour: the Docker instructions themselves show how to pin a version with docker pull ghcr.io/<owner>/openclacky:1.5.3, and the build-from-source path accepts a VERSION build argument for the OCI image label, which suggests pinning is an expected practice rather than an afterthought. The gem route gives you the same lever through normal Ruby version constraints. On licensing: the harness is MIT, which is permissive and places few obligations on how you use or redistribute the code, but it says nothing about the skills you write on top of it, the model providers you route to, or the terms attached to any skill you package for sale. Those are separate agreements and this repository does not speak to them. If you are evaluating OpenClacky for a team, the first thing to verify is not the feature table. It is whether the cache and cost behaviour holds on your own task mix, using your own keys, before the internal averages are treated as a planning input.

Editorial conclusion

Adopt OpenClacky if you are comfortable in Ruby, want an MIT-licensed harness you can install with gem install openclacky, and your priority is keeping tool schemas small while letting capabilities live in SKILL.md files you can edit. Do not adopt it if you need a published, reproducible cost benchmark before committing budget, or if you expect full browser automation from the container image on macOS or Windows, where the README states --network=host is unsupported. Before rolling it out, verify the cache hit rate and relative cost figures on your own task mix, since the README labels them internal averages with full reports still to be published.

Official sources

1. clacky-ai/openclacky on GitHub
2. License: MIT
3. Project website
4. README
5. Releases