DEV Community: Ravi Patel

Claude Code Review 2026 — From Zero Code to 3 Live SaaS

Ravi Patel — Fri, 22 May 2026 14:04:37 +0000

Originally published on rikuq.com. Republished here for Dev.to's readers.

This is a review of Claude Code from someone with no traditional coding background, who shipped three production AI SaaS solo using it as the primary tool.

I say that upfront because most Claude Code reviews are written by senior engineers comparing it to their existing IDE workflow. That's not me. I'm the user who, a year ago, couldn't ship a basic landing page after a week of trying with GPT — and shipped my first live site in five minutes the day I tried Claude. This review is that perspective.

I'm Ravi. I built Prism (an OpenAI-compatible AI gateway), Citare (AI-search visibility tracker), and BatchWise (Indian compliance marketplace) — three live SaaS, ~107,000 lines of source code, solo, mostly through one tool. This is what I think of it.

TL;DR

Question	Answer
Is Claude Code worth it for serious solo founders?	Yes. It's the cheapest engineer you will ever hire.
Best for	Anything where the model needs to plan, reason across files, and execute — especially if you don't fully know how to code yourself.
Worst for	Speed-dependent routine work where you want instant responses (Gemini-via-Antigravity used to win this)
My setup	Claude Desktop App + ~8 MCP servers wired to my full stack. CLAUDE.md per project as an index. what-i-did.md as a running log.
Cost	$200/month Anthropic Max (20×). Upgraded from $100/month after I hit limits repeatedly during a 12-day sprint.
Verdict	If I could only keep one tool in my stack, this is it. By a margin.

The killer moment

I'll just tell the story.

For about a week I was trying to build a simple landing page with a lead-gen form. Using GPT as my AI. I would write a prompt, GPT would write some code, I'd paste it into the editor, run it, something would break, I'd describe what broke, GPT would write more code, I'd paste it in, something else would break. After ~30 hours of this loop spread across the week, I had nothing live.

One evening I tried Claude. Same kind of prompt. Five minutes later the site was live.

I want to be specific about why, because this is the actual insight: Claude was materially better at using tools. GPT would tell me code; Claude would tell me what to run, watch what happened, adjust, run again. The whole "model-in-a-loop-with-tools" thing was already 5x more useful than "model-as-code-generator-you-paste-into-an-editor."

That five-minute experience is the single most consequential moment in my last two years. Without it, I don't ship three SaaS. I don't build Prism competing with Portkey and Helicone. I don't write this article. The "aha" wasn't "Claude is smarter than GPT" — it was "AI with good tool use is a completely different category of useful from AI as a chat box."

That's also why "Claude Code" — the agentic, tool-using, can-actually-do-things version of Claude — is what I bet on, not generic chat-with-an-LLM workflows.

What Claude Code actually is (and what "Claude Code" means in 2026)

Strictly speaking, "Claude Code" started as Anthropic's CLI tool for agentic coding — open a terminal, run claude, talk to it about your codebase, watch it edit files, run tests, etc.

In practice, "Claude Code" now refers to a broader set of access patterns to Claude-as-coding-agent:

Claude Code CLI — the original. Lives in your terminal. Great if you're comfortable there.
Claude inside IDEs — VSCode/JetBrains plugins, third-party integrations.
Claude Desktop App + MCP — the desktop app with MCP servers wired to external tools. This is what I use now.

The third option is the most underrated and is my current setup. The Desktop App gives you the same Claude reasoning, but the entire surface becomes more conversational and visual than a CLI, and crucially, you can wire MCP servers for every external tool you'd otherwise context-switch out to.

My setup right now

For the past two weeks (since I dropped Antigravity after its May 2026 redesign), my workflow is:

Claude Desktop App as the primary interface
MCP servers wired for Vercel, Cloudflare, GitHub, Gmail, Supabase, Oracle Cloud, AWS, and Citare itself (which exposes 37 MCP tools — yes, I dogfood)
No persistent IDE open most of the day — I jump into VSCode only when I need to read or hand-edit something
One CLAUDE.md per project as a thin index
One what-i-did.md per project as a running action log

The shorthand for the operating model: try to do nothing manually. Every minute I spend clicking around in a different tab is a minute I could have wired into MCP and let Claude handle. Deployments? GitHub MCP + Vercel MCP. Database migrations? Supabase MCP. Reading email? Gmail MCP. The goal isn't to be lazy; it's to keep Claude inside the loop so it actually understands what's happening across my full system.

Before this, I ran Claude Code via the CLI inside a terminal beside VSCode. That worked too. The Desktop App + MCP shift happened because, post-Antigravity, I wanted the most unified surface possible, and the Desktop App with deep MCP wiring is closer to a "command center" than the CLI ever felt.

What I actually built with it

Concrete first-party data, the kind Google's post-May-2026 originality bar rewards:

Citare — ~76,000 lines of TypeScript, 130 pages + 83 API routes, 37 MCP tools, 5-stage Brand Radar agent pipeline. Shipped in 12 days. Built almost entirely with Claude Code.
Prism — ~19,200 lines of TypeScript + ~12,000 lines of Python, three-layer caching, multi-provider routing, Cloudflare edge replication. Shipped in 48 days.
BatchWise — compliance marketplace with Razorpay payments, BRSR assurance workflows, 160+ methodology pages.

Aggregate: ~107,000 lines of source code across three live SaaS, mostly through Claude Code, from someone with no formal coding background. This is the dataset behind every recommendation below.

The CLAUDE.md pattern — three phases I went through

I made every mistake. Sharing in case it helps you skip them.

Phase 1: No CLAUDE.md (the wrong default).
For my first few projects I didn't use one. Every session, Claude had to rediscover the project structure, conventions, and choices. Slow, expensive, repetitive. Don't do this.

Phase 2: Dump everything into CLAUDE.md.
Overcorrection. I started logging the full project context into CLAUDE.md — every decision, every endpoint, every schema. The model now had context, but it was burning its working memory on details that weren't relevant to whatever task I was actually doing.

Phase 3 (where I am now): CLAUDE.md as a thin project index.
CLAUDE.md is short — project goals, tech stack, where the important docs live, conventions to respect. For anything detailed (API contracts, business logic specifics, schema), the index points to a dedicated doc that the model can load on demand. This way the model has cheap context awareness, and pulls in expensive detail only when needed.

If you're new to Claude Code, start at Phase 3. Don't repeat my CLAUDE.md learning curve.

The what-i-did.md pattern — my single most useful file

This is the one I'd most want to share with other Claude Code users.

In every project, I keep a what-i-did.md file. Every meaningful action — feature shipped, bug fixed, decision made, dependency changed — gets a timestamped one-line entry. The model itself updates it as part of its workflow.

Why this is the highest-leverage file in the project:

Session continuity. New Claude sessions can read the last few entries and instantly know "what was happening when I was last here." No re-orientation needed.
Debugging. When something breaks unexpectedly, the log tells me what changed and when. Better than git log because it has intent, not just diff.
Cost compression. The model can load 50 lines of what-i-did.md and skip loading 5,000 lines of recent code changes for the same context awareness.
Memory across context resets. When the conversation gets long and you have to compress, what-i-did.md is the cheapest possible memory transfer.

Try it for a week. You won't go back.

Sonnet via Opus subagent — the token-saving pattern

When I have a task with planning-grade reasoning and heavy routine work, I don't run the whole thing on Opus. I let Opus plan, then spawn Sonnet subagents to execute the routine portions.

This is documented in Anthropic's agent docs but underused. Concretely: Opus reads the spec, decomposes into 5 subtasks, hands each to a Sonnet subagent (smaller, faster, cheaper), then aggregates the results.

For a Citare-scale build (76k LOC in 12 days), this pattern materially extends what the $200 Max plan can handle in a day. If I were running everything on Opus, I'd hit limits constantly. Routing the boring-but-bulky work to Sonnet keeps Opus available for the reasoning that actually needs it.

If you're hitting plan limits and considering an upgrade, try this pattern first. It's free.

The Max $100 → $200 upgrade story

I started on the $100/month Anthropic Max (5×) plan when I committed to Claude as my primary AI. For most of the work on Prism and BatchWise, $100 was fine.

Then I started Citare. On the first day of serious building, I hit the rate limit before lunch. On day two, mid-morning. By day three I was actively throttling my own thinking to stay under the cap, which is exactly the opposite of what a tool should make you do.

I upgraded to $200/month Max (20×) on day three of Citare's build. Hit limits maybe twice in the remaining nine days of that 12-day sprint. The math is straightforward: the upgrade cost me $100/month; it saved me an unknown but clearly positive number of hours by removing throttle-anxiety. For shipping velocity, it was the easiest yes I've ever paid for.

My recommendation: start on $100 Max. Upgrade to $200 when you can feel the ceiling. The signal that you should upgrade isn't a particular usage number — it's the moment you start self-throttling to stay under the cap. The day you do that is the day the $100 plan is costing you money in lost output.

What it does poorly

Honest weaknesses, not the polite kind:

1. It is over-eager. This is my single biggest complaint. Claude will sometimes start executing — running commands, editing files — before the discussion of what to do is even complete. I've lost meaningful tokens (and time) to this pattern: I'm clarifying a constraint, Claude has already started, I have to interrupt, the partial work needs to be unwound or accepted, the model needs to be re-pointed. Annoying when it happens; expensive when it happens on a complex task.

The workaround is to be explicit upfront: "Let's plan before doing anything. Don't write code or run commands until I confirm." That works, but I shouldn't have to add it.

2. Tool-use loops can spiral when models disagree with reality. Occasionally Claude will keep trying the same approach despite signals that it's not working — because it "knows" the API works a particular way and the error message must be the user's fault somehow. Less common than the over-eager problem, but more expensive when it happens.

3. There's no IDE-grade tab completion. This isn't really a Claude Code problem — it's an "operating model" problem. If you want AI as fast hand-extension, use Cursor. If you want AI as fast feature-shipper, use Claude Code. Mixing the two metaphors leads to disappointment.

The "I miss this" gap (post-Antigravity)

Since I dropped Antigravity, the only thing I actively miss is Gemini's speed for small routine tasks. Pre-redesign Antigravity-with-Gemini was at least 2× faster than Claude for trivial edits and boilerplate. That speed isn't a Claude Code weakness — it's a model latency reality — but it's the workflow gap I notice most.

For now I just accept that Claude is slightly slower on trivial stuff, in exchange for being better at everything else. Worth it.

Comparison vs the alternatives

vs Cursor: Cursor wins as an everyday IDE if your default workflow is "type code with AI assist." Claude Code wins if your default workflow is "direct an AI to ship features." I'm in camp two, so Claude Code. Many founders are in camp one, and Cursor is the right call there. Not substitutes — they describe different operating models. Full landscape here.
vs Antigravity (pre-redesign): Antigravity was faster for routine work via native Gemini. Claude Code is broader and deeper. I used both for months; the combination was excellent. Full Antigravity story here.
vs GitHub Copilot: Copilot is fine if you're locked into JetBrains/Visual Studio. As a standalone agentic tool for solo founders, it's been outclassed. Not close anymore.
vs direct Anthropic API: If you're writing a programmatic agent system, the API is what you want. If you're shipping features as a human-in-the-loop, Claude Code (CLI or Desktop App) is the right interface. Same model, different ergonomics.

What I'd actually buy today

If I were starting from scratch tomorrow with no Claude history:

Anthropic Max ($100/month, 5×) — day one. Bet on flat-fee pricing; don't start with API pay-go.
Claude Desktop App — set it up properly with MCP servers for at least your version control, hosting, and database. Five MCP servers wired well is worth more than fifty installed and ignored.
A CLAUDE.md per project from day one — phase-3 style (thin index), not phase-2 (full dump).
A what-i-did.md per project from day one — same.
Upgrade to Max $200 (20×) the first day you feel yourself self-throttling to stay under cap.

That's the 2026 stack for a serious solo founder. Total: $100/month flat to start, $200/month flat at full intensity.

The verdict

If I could only keep one tool in my stack, this is it. Not close.

The case for Claude Code is mostly not about the model — every frontier model is impressive in isolation. The case is about the operating model: AI as the thing that actually ships features for you, given enough context (CLAUDE.md), enough memory (what-i-did.md), and enough integration (MCP), and the freedom to use tools without you babysitting every command.

If you accept that operating model, Claude Code at $200/month flat is the cheapest engineer you will ever hire. If you don't accept that operating model — if you want AI to be a fast hand-extension while you stay in the driver's seat — Cursor is your tool, not this.

I accepted the operating model. It built three SaaS for me.

The Merging Take Is Too Early

Ravi Patel — Fri, 17 Apr 2026 08:24:25 +0000

Everyone is calling for AI coding tools to consolidate. We are not in the merging phase — we are in the explosion phase. Calling for consolidation right now is reading the cycle wrong.

Everyone is calling for AI coding tools to merge. This week alone I've seen three takes saying the space is consolidating, the winners are picking themselves, time to pick a side.

I think this is reading the cycle wrong.

We are not in the merging phase. We are in the explosion phase. Hundreds of tools are going to emerge and die before any real merging happens. Calling for consolidation right now is like standing in the middle of the Cambrian explosion telling everyone to pick a vertebrate.

The actual thing happening right now — if you watch closely — is not merging. It's copying. Every tool is trying to do everything. The IDE plugin is adding agents. The agent is adding an IDE. The chat tool is adding a terminal. The terminal tool is adding a chat. Nobody is merging with anyone. They're all sprinting toward the same imaginary all-in-one product because that's what the funding decks told them to build.

This is what the noise looks like before a shakeout. Not before a consolidation.

What Merging Actually Requires

Merging requires a few things to be true that are not yet true.

The surface area of the problem needs to be stable. Right now it's changing every quarter. Last year, coding tools were autocomplete plus chat. This year they're autonomous agents that file PRs. Next year it will be something else. You cannot consolidate around a moving target.

The winners need to be clear enough that buying is cheaper than building. Nobody is in that position. Cursor is not buying Continue. Claude Code is not buying Aider. Windsurf is not buying anyone. They're all still in the land grab.

Distribution needs to matter more than capability. We're still in the phase where capability matters more, because the tools are genuinely different from each other in what they can actually do. Once they all converge on the same capability ceiling, distribution starts to matter — and then you see acquisitions. We are not there.

What Is Actually Happening

What's actually happening is the part of the cycle nobody likes to write about, because it's messy and there's no clean narrative.

Tools are copying each other. Features are getting cloned within weeks. Differentiation is collapsing on the obvious axes — autocomplete quality, chat quality, agent capability — and shifting to the non-obvious ones: latency, cost per task, long-context handling, integration with what you already use.

Most of these tools are going to die. Not because they're bad, but because they were built for a window that closed. They raised on the assumption that "AI coding" was the category and they just had to claim a slice of it. They didn't notice that the category is fragmenting faster than they can ship.

The survivors will be the ones that pick a real wedge and go deep instead of trying to be a platform. The wedges that win are the ones an all-in-one tool won't bother with, but that you can't work without once you've used them.

Why This Matters If You're Building or Buying

If you're building: Don't try to be a platform yet. The platforms haven't been built. The picks-and-shovels layer hasn't been built. There is far more room in doing one specific job better than anything else than in being the next Cursor.

If you're buying: Don't commit to a stack expecting it to be your stack in 18 months. It won't be. The tool you're using today will probably be acquired, killed, or pivoted before you finish onboarding your team. Build your workflow around the assumption that the tools will change and the API contracts will not.

The Merging Comes After the Shakeout

The consolidation will happen. But it happens after the shakeout, not before. When most of these tools are dead and the surviving three or four have stopped sprinting toward feature parity and started looking for ways to grow without spending more on capability they can't differentiate — that's when you'll see acquisitions.

Calling for merging right now is just rebranding the noise. The noise is the explosion. The merging comes after the shakeout, and we haven't had the shakeout yet.

I'm building one of these tools. Prism is an API proxy that does routing and session memory, nothing else. That's the bet — that the wedge is more useful than the platform, at least for now. Get an API key or read the docs.

There Is No Best AI Model in 2026 — And That's Actually Good News

Ravi Patel — Thu, 09 Apr 2026 03:36:45 +0000

GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro all dropped within weeks. Each is best at something different. Here's why that changes how you should build with AI.

The last six weeks produced one of the densest model release windows in AI history. OpenAI shipped GPT-5.4 with native computer use and a 1M context window. Anthropic shipped Claude Opus 4.6 with the strongest expert task performance scores anyone has measured. Google shipped Gemini 3.1 Pro at $2 per million input tokens, undercutting both. DeepSeek dropped V4 with 1 trillion parameters at less than a tenth the price of frontier models. Mistral, MiniMax, and Alibaba all released models that beat last year's flagships.

If you're a developer trying to pick "the best model" right now, you've probably noticed something strange. Every comparison article picks a different winner. Every benchmark tells a different story. Every Twitter thread argues for a different model.

That's because there is no best model. And after building an AI proxy that routes across all three major providers, I've come to think that's actually the better outcome.

The current landscape — who wins what

Let me walk through the actual numbers, because the marketing pages bury them.

GPT-5.4 leads on knowledge work and computer use. Its GDPval score of 83% matches industry professionals across 44 different occupations. It hit 75% on OSWorld, which is the first AI model to surpass human performance on desktop task benchmarks. If you're building agents that need to navigate operating systems, browsers, and terminal interfaces, GPT-5.4 is the one. Pricing: $2.50 per million input, $20 per million output.

Claude Opus 4.6 leads on coding and expert-level reasoning. It scores 80.8% on SWE-bench Verified and 81.4% with prompt modification. Its GDPval-AA Elo benchmark score of 1,633 points is 316 points ahead of Gemini 3.1 Pro, indicating that human evaluators consistently prefer Claude's outputs for expert tasks. It also has 128K max output, which means it can generate entire multi-file patches without truncation. Pricing: $5 per million input, $25 per million output. Above 200K context, the price doubles.

Gemini 3.1 Pro is the price-performance king. It scores 80.6% on SWE-bench (within 0.2% of Opus), 94.3% on GPQA Diamond (the highest of any frontier model), and 77.1% on ARC-AGI-2. Context window is 1M tokens standard, 2M in some configurations. Pricing: $2 per million input, $12 per million output. That's 2.5x cheaper than Opus on input and roughly half the price on output.

Claude Sonnet 4.6 is the quiet workhorse. 79.6% SWE-bench, $3 input, $15 output. Within 1 point of Opus on most coding tasks at 60% of the price. Most production apps probably should be using Sonnet by default, not Opus.

Claude Haiku 4.5 at $1 input, $5 output. Half the price of Sonnet. Handles classification, extraction, summarization, and routine generation tasks at quality that would have been considered frontier 18 months ago.

Gemini Flash at $0.50 input, $3 output. Cheap enough that you can run high-volume workloads almost for free.

DeepSeek V4 at $0.28 input, $1.10 output. Open-weight, frontier-class performance on many benchmarks, roughly 27x cheaper than the closed flagships.

The pattern that matters

Notice something? Six different models, each best at something different. None of them is best at everything. The price spread between them is more than 90x for similar quality on appropriate tasks.

Five years ago there was one model that mattered for production work. Three years ago there were maybe three. Today there are easily ten frontier-class models, each with distinct strengths.

The decision isn't "which model do I pick" anymore. It's "how do I match each task to the right model."

The two ways developers respond to this

Option 1: Pick one and call it done. Most developers do this. They sign up for OpenAI, integrate GPT-4o or GPT-5.4, and never look back. It's simpler. There's only one billing dashboard, one SDK, one set of failure modes. The cost is significant overpayment on simple tasks and underpayment on complex ones (where a stronger model would have given a better result).

Option 2: Multi-model routing. Use the right model for each job. Simple classifications go to Haiku or Flash. Coding tasks go to Sonnet or Opus. Reasoning-heavy work goes to Opus or Gemini Pro. Computer-use agents go to GPT-5.4. The cost savings are 30-70% on most workloads. The quality on hard tasks goes up because you're using the right tool. But the engineering overhead is significant — three API keys, three SDKs, three sets of error handling, three billing dashboards.

This is a real tradeoff. Most teams pick Option 1 because Option 2 is too much work for too little immediate payoff. You can save 40% on your AI bill, but you spend two weeks building the infrastructure to do it.

Why proxies exist

This is exactly the problem proxies solve. A proxy sits between your application and the providers. You make one type of request to one endpoint with one API key. The proxy handles the routing, the multiple SDKs, the failover, the cost tracking. Your code stays simple. You get the multi-model benefits without the multi-model overhead.

The proxies that exist today fall into two camps:

Pass-through routers like OpenRouter let you specify a model name in your request and they forward it to the right provider. Useful for accessing many models through one billing relationship, but you still have to pick the model yourself. The intelligence is on you.

Intelligent routers classify your query and pick the model for you. This is what I built with Prism. You pick a mode (eco, balanced, or sport) and Prism's classifier decides which model handles each query. Simple tasks go cheap. Complex tasks go capable. Quality floor enforced — eco mode never sends complex reasoning to Flash.

Both approaches are valid. The pass-through routers are great if you already know exactly which model you want for which task and you just want unified billing. The intelligent routers are better if you want the routing decisions made for you.

What the model proliferation actually means

The model release pace has compressed from quarterly to monthly. OpenAI confirmed monthly GPT-5 series releases. Anthropic, Google, and the open-source labs are matching that cadence. By the end of 2026 we'll likely have 15-20 frontier-class models, each with distinct strengths.

This means three things for developers:

1. Vendor lock-in is increasingly expensive. If you hardcoded GPT-4o into your app two months ago, you're already on a deprecated model. The next version is better and cheaper, but switching means code changes, prompt rewrites, and regression testing. Building against an abstraction layer (OpenAI-compatible API or a proxy) means swapping models becomes a config change instead of a migration project.

2. Continuous evaluation matters more than picking right once. No matter which model you choose today, a better one will exist in 6 weeks. The right strategy is to build the ability to swap and re-evaluate easily, not to pick the perfect model upfront.

3. Routing infrastructure is now table stakes. What used to be a "nice to have" optimization is becoming standard practice. The teams winning on AI economics are the ones who've automated model selection. The teams losing are the ones still hardcoding flagship models for every request.

The simple version

If you remember nothing else from this post, remember this: the AI model landscape in 2026 is no longer a "pick the best one" problem. It's a "match each task to the right model" problem.

The savings from doing this correctly are 30-70%. The quality improvements on hard tasks are also significant. The engineering cost is the only thing standing in the way, and that's exactly what proxies and routers solve.

Stop picking. Start routing.

I built Prism because I wanted intelligent routing without building it myself. It's an OpenAI-compatible proxy that classifies your queries and routes them to the optimal model across Anthropic, OpenAI, and Google. Free tier available. Get an API key or read the docs.

How I Cut My AI API Costs by 40% Without Changing a Single Prompt

Ravi Patel — Tue, 07 Apr 2026 09:50:20 +0000

Most developers overpay for AI by sending every query to the same model. Here's how intelligent routing across Anthropic, OpenAI, and Google saved me 40% on API costs.
I was spending about $200 a month on Anthropic API calls. Building a product that makes a lot of AI requests — some complex, some dead simple. Every single call went to Claude Sonnet because it was "good enough" and I didn't want to deal with multiple providers.

Then I sat down and actually looked at what those calls were doing.

About 60-70% of my API calls were simple tasks. Summarise this paragraph. Extract the name from this email. Classify this support ticket. Translate this sentence. These don't need Sonnet. A model like Gemini Flash or Claude Haiku handles them perfectly at a fraction of the cost.

The other 30% were genuinely complex — analysing financial data, generating reports, multi-step reasoning. Those needed a capable model. But I was paying Sonnet prices for the simple stuff just because I couldn't be bothered to manage multiple providers and figure out which model to use for each call.

So I fixed it. And the fix turned into a product.

The actual cost difference between models
Here's what caught my attention. These are real per-million-token costs as of early 2026:

Gemini 2.5 Flash costs about $0.15 per million input tokens and $0.60 per million output. Claude Haiku is $0.80 input and $4.00 output. GPT-4o-mini is $0.15 input and $0.60 output.

Compare that to the "default" models most developers use: Claude Sonnet at $3.00 input and $15.00 output. GPT-4o at $2.50 input and $10.00 output.

For a simple summarisation task, you're paying 10-20x more than you need to by using Sonnet instead of Flash. And the output quality on straightforward tasks is nearly identical.

The maths is simple. If 65% of your calls can go to cheap models and 35% need the mid-tier ones, your blended cost drops from roughly $8 per million tokens to about $3-4 per million. That's a 50% reduction before you've changed a single prompt.

Why developers don't do this already
Because it's genuinely painful to set up. You need to sign up for Anthropic, OpenAI, and Google. Manage three API keys. Learn three different request formats (they're similar but not identical). Build routing logic. Handle failures when one provider goes down. Track costs across three billing dashboards.

Nobody does this for a side project. Most companies don't do it either — they pick one provider and accept the overspend because the engineering cost of multi-provider routing isn't worth it.

What intelligent routing actually looks like
The approach I built classifies each incoming query before routing it. The classifier looks at signals in the prompt: how long is it, does it contain code, does it ask for analysis or reasoning, is there a system prompt, what's the conversation depth.

Based on those signals, each query gets tagged as one of four types: simple, code, reasoning, or complex. Then the routing table maps that type to a model based on your cost-quality preference.

If you want aggressive cost savings, simple tasks go to Gemini Flash, code goes to Haiku, reasoning goes to Haiku, and only truly complex multi-step queries go to Sonnet. That's the cheapest option that still maintains a quality floor.

If you want the best answer regardless of cost, everything goes to the most capable model available. Simple or not.

The interesting case is the middle ground — you want good answers at a reasonable price. Simple tasks go cheap, but anything with substance goes to a capable model. This is where most production apps should operate.

The quality floor matters more than the routing
Here's the thing I learned building this: the routing algorithm is less important than the quality floor. If your cost optimisation ever sends a complex reasoning task to a model that can't handle it, the developer loses trust immediately. One bad answer and they switch back to hardcoding Sonnet.

So the classifier has to be conservative. When in doubt, route to a more capable model. It's better to overpay slightly on an edge case than to return a garbage response. The savings come from volume — getting the easy 60-70% of calls right, not from being aggressive on the hard 30%.

Session memory: the other cost nobody talks about
While building the router, I noticed another source of waste. Every AI API is stateless. If you're building a chatbot or any multi-turn interaction, you resend the entire conversation history on every single call.

Message 1: you send 1 message. Message 5: you send all 5 messages. Message 20: you send all 20. You're paying input token costs on the same messages over and over.

The fix was adding a memory layer at the proxy level. The developer sends a session identifier with their request. The proxy stores the conversation history and assembles it before forwarding to the provider. The developer sends one new message each time. The proxy handles the rest.

This doesn't reduce the provider cost — the full history still gets sent. But it eliminates the need for the developer to build conversation management infrastructure. No Redis store, no message assembly logic, no context window overflow handling. One header and it works.

The more interesting cost benefit comes later with compression. When conversations get long, the proxy can summarise older messages using a cheap model before forwarding. The developer doesn't manage this. The summary is transparent. And the input token count on long conversations drops significantly.

Real numbers from production
I ran a test with the same prompt across different routing strategies.

A reasonably complex prompt about Indian tax law sent directly to Claude Sonnet: 955 input tokens, 1115 output tokens, cost roughly $0.018.

The same prompt through intelligent routing in balanced mode: same quality response, same token counts, but routed to the optimal model. Cost was comparable in this case because the classifier correctly identified it as a reasoning task.

Where the savings show up is in aggregate. Across a mix of simple and complex calls — the kind any production app generates — balanced mode saves 30-50% compared to hardcoding a single mid-tier model. Aggressive cost mode saves 50-70% on workloads that are mostly simple tasks.

The five-minute integration
The whole point is that none of this should require work from the developer. The proxy accepts OpenAI-compatible requests. Switching means changing one URL:

base_url = "https://api.openai.com/v1"
base_url = "https://api.prism.ssimplifi.com/v1" Existing prompts work unchanged. Existing response parsing works unchanged. The developer adds one header to choose their cost-quality preference, and optionally a session header for memory.

The proxy handles model selection, provider failover, session memory, cost tracking, and response normalisation. The developer's code stays exactly as it was.

What I'd tell myself six months ago
Stop overpaying for simple tasks. The model landscape has cheap, capable options for straightforward work. Reserve the expensive models for queries that actually need them. And if the engineering overhead of managing multiple providers is what's stopping you, use a proxy that handles it.

The AI API cost problem isn't about any single model being too expensive. It's about using the same model for everything when the tasks have wildly different complexity levels. Fix the routing and the savings follow.

I built Prism to solve this for myself and now it's available for any developer. Free tier available, no credit card required. Read the docs or get an API key.