My experience using Deepseek via API: From low-cost to high-cost by mistake

If you've ever implemented direct integrations with Artificial Intelligence providers like OpenAI or DeepSeek, you've likely fallen into one of the most subtle (and expensive) traps of their APIs: opaque model fallbacks.

In this article, I want to share an architectural lesson I learned when analyzing my platform's consumption metrics and discovering how millions of tokens were evaporating out of control.

1. The Automatic "Fallback" Trap

When I started doing my first experiments with OpenAI and DeepSeek, the architecture was simple. I had dedicated classes for each provider: OpenAIChatService and DeepSeekChatService.

At first, I set a maximum spending limit of $5. During my initial tests in February, the service seemed absurdly cheap:

The bug masked by low costs

The real danger of ultra-cheap models is that they forgive poor operational practices. In May, my request volume skyrocketed from 145 to 2,310, consuming a staggering 44.5 million tokens. This was due to a flaw in my code (an inefficient loop of repetitive calls or a lack of caching).

However, since the system was using deepseek-v4-flash, the bill barely reached $1.90. That ridiculous cost ended up cementing a false sense of technical and economic security: "if a massive calling bug only costs me less than two dollars, there's no rush to optimize".

Note — Scaling the problem to the enterprise level:
This trap isn't unique to individual developers. Recently, an enterprise client accidentally racked up a $500 million bill on Anthropic's Claude AI in a single month after failing to set spending caps for employees. Similar friction has led tech giants like Microsoft, Uber, and Amazon to throttle licenses or exhaust annual budgets in months. Treating usage-based AI like a traditional flat-rate SaaS subscription without setting hard guardrails is a recipe for disaster at any scale.

The "Silent Fallback" Scare: drop in requests, crazy costs

The disaster struck when calls were redirected without warning to the Pro model (deepseek-v4-pro) due to the saturation of DeepSeek's servers.

Here the analytical paradox occurred: even though the number of requests dropped significantly (traffic went down after I realized the inefficiencies), token consumption and costs skyrocketed.

By opaquely routing to the Pro model, every individual call became a trap: the Pro model not only processed and returned more tokens per request due to its nature and context size, but the cost per token multiplied. A single inefficient call to the Pro model consumed resources at an infinitely more devastating rate than hundreds of calls to the Flash model.

As seen in the July chart, the consumption of the flash version dropped to less than a cent, while all traffic and costs were opaquely routed to the pro version, quickly leaving the balance in the negative.

What was going on?

After investigating thoroughly, I stumbled upon one of the most common yet least documented problems in modern APIs: invisible load redirections. If you are not familiar with why these redirections occur (whether due to opaque load balancing or internal orchestrators), I recommend reading my detailed technical article on Dynamic Routing and Cost Control in AI APIs.

The practical conclusion was harsh: I was suffering from a total loss of cost control because the API was deciding for me when to route to a more expensive model.

[!WARNING]
Pricing Update: "Peak-Valley" Strategy in DeepSeek
A new risk adds to this fallback problem. Starting in mid-July, the official DeepSeek API adopts a variable pricing strategy. During Peak hours, prices are multiplied by two (x2) for all consumption.
The established peak hours are:

• UTC: 1:00 to 4:00 AM and 6:00 to 10:00 AM.
• (UTC+8 Equivalent: 9:00 AM to 12:00 PM and 2:00 PM to 6:00 PM).
  This makes losing control of routing during these timeframes even more catastrophic for your budget.

2. Regaining Control: OpenRouter to the Rescue

To solve this, I decided to change my architectural approach. I stopped tying myself to individual providers and pivoted towards an agnostic model using OpenRouter.

OpenRouter is a transparent middleware that groups hundreds of models from dozens of providers. Its immense catalog allows not only swapping LLMs quickly but also leveraging advanced capabilities like tool-calling, granular context control, and precise metrics.

The danger of pure automatic routing

At first, seeking maximum convenience, I delegated routing intelligence to the platform's default behavior. My expectation was that it would choose the fastest and cheapest option for routine tests.

The reality was very different. Automatic routing detected the complexity of my prompt and decided to route traffic to massive high-capacity models (like iterations of GPT-4o or equivalent). As a result, my first calls through the middleware incurred high costs, perpetuating the exact same lack of control I was trying to fix:

The lock from the Dashboard

To mitigate this, I switched to using a strict router: openrouter/free. This is not a model per se, but a selector that actively searches the catalog for which models are 100% free at the time of the request.

To guarantee there would never be a financial surprise, I configured OpenRouter's native interface by applying a double lock. I globally forced the platform to always sort by the cheapest provider (Price: cheapest first) and to assign an absolute zero-cost model as the default fallback:

The lock from the Code: Prioritizing Tencent Hy3

Blindly delegating to OpenRouter's interface is still a black-box risk. Therefore, I decided to implement an architectural firewall directly within the payload of my HTTP requests (managed by Laravel).

Instead of sending the request to the generic router, I programmed the backend to explicitly request an ordered list of specific models. The absolute favorite was the free model tencent/hy3:free, accompanied by the "allow_fallbacks" => false flag to explicitly prohibit routing to premium versions if the free model failed.

[!WARNING]
The Mirage of Free (Bait and Switch)
If we analyze the official URL for the model (https://openrouter.ai/tencent/hy3:free), we can spot a small warning sign: the free version will disappear on July 21, 2026.
This reflects a classic strategy in the AI API ecosystem. Providers (like Tencent or Novita) launch free endpoints to collect telemetry, stress test their systems in production, and most importantly, build technical dependency among thousands of developers. Once they've captured enough user base, they abruptly shut off the free tap, forcing projects to migrate to paid instances (with highly lucrative margins) to keep their applications running.

3. Conclusion: Decoupled Architecture

Thanks to this pattern, the flow of my application is completely decoupled:

1. .env defines my spending and reliability strategy depending on the environment (development vs. production).
2. config/ai.php (or services.php) structures this data.
3. Laravel's Dependency Injection Container automatically injects the abstract ChatService interface.
4. The Controller consumes the service without caring if OpenAI, DeepSeek, or a smart router is behind it.

The next time you integrate artificial intelligence into your application, don't tie yourself to a direct provider. Implement routing middlewares and, above all, consciously parameterize your fallback configurations. My wallet, and my platform's uptime, have greatly appreciated it.