I've been learning Claude Code for agentic development lately, but I didn't want to burn through paid API credits while I was still figuring out ho...
For further actions, you may consider blocking this person and/or reporting abuse
Interesting, starred/bookmarked it, might try it out!
So, if I understand correctly: Claude Code does not have a built-in mechanism to switch models, but you "tricked" it via this proxy (which probably intercepts the HTTP calls) ?
Cool idea!
Exactly @leob, you understood well, chears...
Nice one, cool that CC's limitation can be circumvented like this ...
P.S. don't tell Anthropic that you made this, because of course they make $$$ from calls to their own LLMs ;-)
Okay, i will keep it secret 😉
Me too, I'll keep it secret as well !
Interesting strategy! I appreciate that, rather than portraying it as a "free Claude" solution, you explicitly outlined both the advantages and the drawbacks. For developers who wish to experiment without worrying about API charges, using LiteLLM with Bedrock to understand agentic processes is a feasible idea. I appreciate you sharing the setup and the insights you gained.
Appreciate your words, that's made my day..
Nice write-up! I especially appreciate the distinction between learning the agent workflow and evaluating the model. One thing I’d also consider is keeping the proxy provider-agnostic. If the CLI only targets an OpenAI-compatible (or similar) interface, you can swap Bedrock, Anthropic, OpenAI, Gemini, or even a local model without changing the client. That makes the proxy a long-term architectural layer rather than just a cost optimization for one provider.
Wow, What a great idea to implement !!
I will try it definitely 👍🏻
Glad you like the idea! 🙂 If you keep the proxy provider-agnostic, I’d also separate model capabilities from provider adapters. Let the client ask for capabilities like tool calling, vision, reasoning level, or prompt caching, and have each adapter translate those to the target provider. That way adding a new backend becomes mostly an adapter instead of changing the core proxy logic.
It also makes benchmarking much easier because you’re comparing providers behind the same abstraction instead of rewriting the client each time.
The caching question in the comments is the one I would chase first, because it does not just soften the cost claim, it can invert it. Per-token price is the wrong unit here. Claude Code's prefix is huge and almost entirely stable turn to turn (system prompt plus tool definitions), which is exactly the shape caching exists for, and cache reads run around a tenth of base input price. Caching is a strict prefix match and is scoped per model, so if the translation layer perturbs a single byte of that prefix between turns you are not paying 20-35% less per token, you are paying full price on many times more tokens. Log cache-read tokens per turn before trusting the projection. One concrete edge worth knowing: on Bedrock, explicit cache_control breakpoints are supported but automatic top-level caching is not, so anything relying on the automatic path silently gets nothing there and nothing errors to tell you.
Worth saying plainly since the title points at it: aiming Claude Code at Claude on Bedrock is a supported native path, the model IDs just carry an anthropic. prefix. The proxy is load-bearing only because the destination is Nova, which is the part your own conclusion already gets right.
Very thoughtful information you shared 👏🏻
Thanks. If you do end up testing it, the number to watch is the cache-read token count in the usage block of each response. If it comes back zero on turn two with an unchanged prefix, the translation layer is touching something, and that is the whole answer in one field.
The skew is worse than model quality alone. Claude Code's system prompts and tool schemas are tuned for Claude's tool-calling behavior, so with LiteLLM translating to Nova you are also learning how the harness behaves under a mismatched model: tool-call retries, malformed JSON recovery, context compaction triggers all fire at different rates. Those failure mechanics are a big part of what you are trying to internalize, and they will look different against the real backend. A cheap calibration: log raw tool-call error rate through the proxy for a week, then run one short paid Claude session on the same repo and compare. One more line for the cost math: prompt caching. Long agentic sessions on Anthropic's API get big cached-input discounts, and whether Bedrock's prompt caching actually kicks in for Nova through a LiteLLM translation layer is worth checking, so the 20-35% per-token figure may not survive a real multi-hour session. Did LiteLLM pass through Claude Code's streamed tool_use blocks cleanly, or did you have to patch around dropped blocks?
Yess, You are absolutely correct and even I also figured it out with using actual anthropic's model. But this is only experiment purpose and for starting learning journey with Claude Code as free.