Same answers. Up to 75% off your input bill.

Tokens in
18,200
Optimizer · ~250ms
−12,740
Tokens out
5,460

70% smaller bill on this request.

Set up once. Save on every conversation.

STEP 01

Swap your base URL

Point your client at our proxy and add one header. Your provider key still goes to your provider.

STEP 02

We cut the dead weight

Old, wordy turns get frozen into a checkpoint and rewritten tight once - every later request just replays that checkpoint byte-for-byte, which is also why your provider's own cache never sees a reason to miss. Your code, JSON, IDs, and recent turns come through exactly as written.

STEP 03

You pay for the short version

The provider bills the shorter prompt, so your bill drops. Flat monthly price means the savings are yours to keep. Streaming and tool calls work like always.

Two lines of code

from anthropic import Anthropic

client = Anthropic(
    api_key="sk-ant-...",                            # your key, forwarded
    base_url="https://api.promptcrunch.dev",        # the only swap
    default_headers={"X-PromptCrunch-Key": "pc_live_..."},
)

resp = client.messages.create(
    model="claude-sonnet-4",
    max_tokens=1024,
    messages=conversation_history,             # long history? we shrink it.
)

One 40-turn session, 75% of the input bill gone

This is a real 40-prompt run on Claude Sonnet 4.6. Your code, JSON, IDs, system prompts, and latest turns ride through word for word. We only rewrite the old, wordy context, and we keep what it means.

Before
851,859tok
After
212,181tok
75% smaller · Saved $1.92 on Sonnet 4.6 at $3/MTok input

Here's one follow-up turn. The chatty lead-ins and back-references get cut. The real claim and the full stack trace ride through unchanged.

Before 94 tok
OK so after your last suggestion the build passes, but I'm hitting a different issue now. Integration tests fail with a database connection error. Nothing has changed in the DB config. Stack trace below:
PrismaClientInitializationError:
  Can't reach database server at `localhost:5432`
    at PrismaClient._engine_initEngine (lib.js:1234)
    at PrismaClient._engine_request (lib.js:1289)
After 68 tok
The build passes; integration tests fail with a database connection error. Stack trace:
PrismaClientInitializationError:
  Can't reach database server at `localhost:5432`
    at PrismaClient._engine_initEngine (lib.js:1234)
    at PrismaClient._engine_request (lib.js:1289)

Same stack trace, down to the character. Only the dimmed filler got cut: 94 tokens to 68, with no meaning lost.

What we never touch, and what we trim

Never altered

  • Code blocks
  • JSON, YAML, TOML
  • Tool use calls and results
  • System prompts
  • Recent turns
  • IDs, URLs, numbers
  • Cache hits. Anything with cache_control rides through untouched, breakpoints intact. Never worse than going direct.

Fair game to trim

  • Verbose prose in older turns
  • Repeated context
  • Hedging and filler
  • Long explanations of past decisions
  • Self-references to earlier turns

Across 227 benchmark requests

Measured across our own multi-model benchmark runs.

6.1M
input tokens processed
2.9M
input tokens saved
87%
peak input cut on long chats
0
quality regressions on benchmark suite

If we ever fail, you don't

Optimizer error

We forward the original

If our optimizer ever chokes, your original prompt goes straight to the provider, unchanged. The response carries status: "error", so nothing slips by.

Network blip

Your SDK throws normally

If we're unreachable, your SDK errors like any other network issue. One-line fallback to direct provider URL.

Cache-safe

We never touch a cache hit

Already using prompt caching? Those requests go straight through, so you keep every cache hit while we crush the bill on everything that grows. Every response shows the original-vs-forwarded token count, so you can see exactly what we saved.

Try it on a real workload

Point one base URL at us and watch a long conversation get cheaper. $5 credit, no card.

Cut your token bill Compare plans