As per its own FAQ this plugin is out of date and doesn’t actually do anything incremental re:caching:
> "Hasn't Anthropic's new auto-caching feature solved this?"
> Largely, yes — Anthropic's automatic caching (passing "cache_control": {"type": "ephemeral"} at the top level) handles breakpoint placement automatically now. This plugin predates that feature and originally filled that gap.
Is it perhaps because this is for claude code but there's other tools that use anthropics api like custom agents? (some i prefer to use than claude code - e.g sketch.dev what is now called shelley at exe.dev) perhaps?
Hasn't this been largely solved by auto-caching introduced recently by Anthropic, where you pass "cache_control": {"type": "ephemeral"} in your request and it puts breakpoints automatically? https://platform.claude.com/docs/en/build-with-claude/prompt...
Looking at my own usage with claude code out of the box and nothing special around caching set up. For this month according to ccusage I have in tokens 0.2M input, 0.6M output, 10M cache create, 311M cache read for 322M total tokens.
Seems to me that it caches out of the box quite heavily, but if I can trim my usage somehow with these kind of tools I'd love to know.
Interesting – I've been using Claude heavily for building projects without writing code myself. Token costs add up fast, anything that reduces that is welcome. Has anyone tested this in production workflows?
> This plugin is built for developers building their own applications with the Anthropic API.
> Important note for Claude Code users: Claude Code already handles prompt caching automatically for its own API calls — system prompts, tool definitions, and conversation history are cached out of the box.
Slightly off-topic, but I recently tested some tool and it turns out Opus is far cheaper than Sonnet, because it produces way less output tokens and those are what's expensive. It's also much slower than Opus (I did 9 runs to compare Haiku, Sonnet and Opus on the same problem). I also thought "oh, Sonnet is more light-weight and cheaper than Opus", no, that's actually just marketing.
Claude subscriptions (strangely) have a Sonnet limit which is lower than the general model limit. Using Sonnet counts against both limits, using Opus only the general limit. So the subscriptions are discouraging Sonnet use as well.
This is not at all an MCP server you want to use with a regular tool, as this is about low level context window management. Tbh it’s really trivial to do this, and I have no idea why OP decided to make an MCP server for this as it’s completely useless for that.
As a matter of fact, i think this is not a problem at all as Anthropic makes it extremely easy to cache stuff; you just set your preferred cache level on the last message, and Anthropic will automatically cache it under the hood. Every distinct message is another “cache” point, eg they first compute the hash of all messages, if not found, compute the hash of all messages - 1, etc.
No. Claude.ai is a consumer product — you have no access to the API layer underneath it. cache_control is an API-level feature only. This plugin works exclusively when you're making direct Anthropic API calls, either through the SDK in your own code or through MCP-compatible clients like Claude Code, Cursor, Windsurf, etc.
As per its own FAQ this plugin is out of date and doesn’t actually do anything incremental re:caching:
> "Hasn't Anthropic's new auto-caching feature solved this?"
> Largely, yes — Anthropic's automatic caching (passing "cache_control": {"type": "ephemeral"} at the top level) handles breakpoint placement automatically now. This plugin predates that feature and originally filled that gap.
I don't understand and I'm curious, why a dead on arrival open source tool needs a separate domain?
Is it perhaps because this is for claude code but there's other tools that use anthropics api like custom agents? (some i prefer to use than claude code - e.g sketch.dev what is now called shelley at exe.dev) perhaps?
Hasn't this been largely solved by auto-caching introduced recently by Anthropic, where you pass "cache_control": {"type": "ephemeral"} in your request and it puts breakpoints automatically? https://platform.claude.com/docs/en/build-with-claude/prompt...
Looking at my own usage with claude code out of the box and nothing special around caching set up. For this month according to ccusage I have in tokens 0.2M input, 0.6M output, 10M cache create, 311M cache read for 322M total tokens. Seems to me that it caches out of the box quite heavily, but if I can trim my usage somehow with these kind of tools I'd love to know.
This is not about caching things for stuff that others built, it’s solely to modify code that you’re writing that will use Anthropic’s API endpoints.
Yes, it has, this is a non-problem, and even if it was a problem, an MCP server would most definitely be one of the worst ways to fix it.
It is answered in the FAQ.
Interesting – I've been using Claude heavily for building projects without writing code myself. Token costs add up fast, anything that reduces that is welcome. Has anyone tested this in production workflows?
> This plugin is built for developers building their own applications with the Anthropic API.
> Important note for Claude Code users: Claude Code already handles prompt caching automatically for its own API calls — system prompts, tool definitions, and conversation history are cached out of the box.
Source: their GitHub
This is applicable only to the API from what i understand. Since claude code already caches quite aggressively (try npx ccusage)
Also the anthropic API did already introduce prompt-caching https://platform.claude.com/docs/en/build-with-claude/prompt...
What is new here?
Slightly off-topic, but I recently tested some tool and it turns out Opus is far cheaper than Sonnet, because it produces way less output tokens and those are what's expensive. It's also much slower than Opus (I did 9 runs to compare Haiku, Sonnet and Opus on the same problem). I also thought "oh, Sonnet is more light-weight and cheaper than Opus", no, that's actually just marketing.
Claude subscriptions (strangely) have a Sonnet limit which is lower than the general model limit. Using Sonnet counts against both limits, using Opus only the general limit. So the subscriptions are discouraging Sonnet use as well.
I don't understand, Claude code already has automatic prompt caching built in.[0] How does this change things?
[0] https://code.claude.com/docs/en/costs
Will this work for Cowork as well?
This is not at all an MCP server you want to use with a regular tool, as this is about low level context window management. Tbh it’s really trivial to do this, and I have no idea why OP decided to make an MCP server for this as it’s completely useless for that.
As a matter of fact, i think this is not a problem at all as Anthropic makes it extremely easy to cache stuff; you just set your preferred cache level on the last message, and Anthropic will automatically cache it under the hood. Every distinct message is another “cache” point, eg they first compute the hash of all messages, if not found, compute the hash of all messages - 1, etc.
It’s really a non problem.
No. Claude.ai is a consumer product — you have no access to the API layer underneath it. cache_control is an API-level feature only. This plugin works exclusively when you're making direct Anthropic API calls, either through the SDK in your own code or through MCP-compatible clients like Claude Code, Cursor, Windsurf, etc.