Where a Cheap DeepSeek API Fit in an Earlier Routing Stack

Archive note, August 2026: This page documents a May 2026 AutoKaam routing experiment. Its provider sequence, prices, free-tier limits, latency observations, and deployment statements are historical records. They do not describe the active AutoKaam setup or current DeepSeek terms. Evaluate current models, privacy terms, and billing before using a low-cost API in production.

In May 2026, the "cut your AI bill by 98 percent" headline was an attention-grabbing way to describe a low-cost model's token price. It was never a migration plan on its own. In the archived experiment, a cheap model was one candidate inside a multi-provider router, not the writer, planner, or automatic answer to every task. This updated version keeps the decision framework and removes the expired price card and active-configuration claims.

The mental model: evaluate a lane, not a brand

The May setup put each job behind a routing function rather than calling a model directly. Callers supplied a purpose, such as structured extraction, critique, or long generation, and the router selected a candidate according to the experiment's profile. If a response was unavailable, timed out, or failed validation, the caller received either a separately checked result or a clear failure.

That shape is still useful, but it should not be copied as an eight-profile configuration. The archived 5-model router shows why: provider order and terms change faster than a tutorial. What survives is the question asked before a model enters a lane: can the task be independently checked, and is the expected cost of a bad answer lower than the cost of another model or human review?

Cost reasoning without stale prices

The earlier price table compared specific model names and INR conversions. It is removed because current price, quota, cache, exchange-rate, and subscription assumptions need a live source. The calculation to run before a rollout is straightforward:

accepted-result cost =
  (input tokens x current input rate + output tokens x current output rate)
  x average attempts per accepted result
  + review and recovery cost

Measure accepted results, not merely API responses. A model that returns fast but needs retries or manual repair can cost more than a higher-priced candidate that passes validation on the first attempt. For a large batch of independently checkable records, a cost difference can compound. For a reader-facing page, a small token saving can disappear behind one rewrite.

A workload map that ages better than a provider list

The historical router used named profiles and a fixed provider order. Instead of treating that order as current guidance, sort a workload by its failure mode.

workload class	question to answer before using a low-cost candidate	safer default
Batch classification	Can an objective rule catch wrong labels?	Use a sampled evaluation set and quarantine uncertain output.
Structured extraction	Can schema validation and source checks reject bad fields?	Require a strict schema plus retries with bounded limits.
Deduplication and relevance scoring	Can another signal rank or reject the result?	Keep the score auditable and retain the source record.
Translation	Is there a reviewer for sensitive or public copy?	Test representative language pairs, including edge cases.
Reader-facing prose	Does one weak output damage trust more than it saves?	Use a reviewed writing workflow, not a cost-first default.
Multi-step planning	Does a single inconsistent step invalidate the plan?	Pin the model and test the whole chain end to end.

This is where a low-cost model earned consideration in the archive: high-volume, structured jobs with an acceptance check. Before a candidate entered a lane, I ran a fixed battery of objective hard tasks with checkable answers. The point was not to name a winner once; it was to make a promotion decision repeatable.

When a cheap candidate is the wrong default

Cost is not the only constraint. Two lessons from the archive still matter.

Reader-facing prose needs a trust budget. An inexpensive model can produce passable drafts, but a public article has a larger blast radius than a private batch record. If an editor or a higher-confidence model must repair the output, the apparent API saving can vanish. Keep the decision tied to the review path, not to an attractive price ratio.

Long structured generation needs a real-prompt test. During the experiment, a reasoning-mode candidate spent its output budget on internal work and returned no final content. The lesson was not tied to that one provider: test with the full production prompt, target length, and output limit. A toy smoke test can hide the exact failure that will happen on the real job.

Other caution areas include complex multi-step planning, agentic tool chains with irreversible side effects, and creative work where consistency is the product. In these lanes, start from a stable contract and change it only after a controlled evaluation.

Wiring a bounded fallback

A minimal fallback design needs a candidate list, response validation, logging, and a terminal error. It should never silently convert an unknown provider error into a result.

MODEL_TIERS = [
    "low-cost-candidate",       # admitted only after a lane-specific evaluation
    "reviewed-primary-model",   # known-good contract for the workload
    "independent-fallback",     # separate failure domain
]

def call_with_failover(messages, max_attempts=3):
    for model in MODEL_TIERS[:max_attempts]:
        try:
            response = client.chat.completions.create(
                model=model, messages=messages, timeout=60,
            )
            content = response.choices[0].message.content
            if not content:
                raise ValueError("empty content")
            validate(content)
            log.info("served=%s", model)
            return content
        except (TimeoutError, ValueError, ProviderError) as error:
            log.warning("candidate=%s failed: %s", model, error)
    raise RuntimeError("all candidates failed validation")

The precise errors and retry policy should match the SDK and the task. Do not catch every exception, and do not fail over when model identity is part of the contract. For a schema-bound extraction, log the candidate, latency, status, retry count, and validation reason. For a public publishing workflow, keep the source and reviewer decision alongside the output.

One historical detail that remains broadly useful: use an explicit timeout that matches the user experience, then measure it from the network where the job runs. A background worker can tolerate a different latency budget from an interactive endpoint. If a provider sits behind a restrictive gateway, use the documented client headers and record the upstream status instead of treating all failures as model quality problems.

Cost math where it compounds

The archived numbers are gone, but the decision test remains. Start with a representative sample, then record the variables that change the real bill:

measure	what it reveals
Calls per day and accepted-result rate	Whether volume is large enough for a token difference to matter.
Input and output token distribution	Whether prompt size or long completions drive the bill.
Cacheable prefix ratio	Whether prompt design is a larger saving than a model switch.
Retry and fallback rate	Whether nominal pricing survives provider instability.
Review minutes per accepted result	Whether quality recovery defeats the API saving.

For deterministic requests with the same input, the next lever may be to skip the model entirely: memoize LLM calls to a content-addressed cache and replay a validated answer. For everything else, route by accepted cost and failure impact, not by a banner percentage.

Latency is a cost too

Token price is visible; wait time and retries are easier to miss. A low-cost candidate can be appropriate for a background task that has room to retry and inappropriate for an interactive screen where a person waits for a response. Measure p50 and p95 latency with representative prompts, not a single short ping. Then define the budget before sending traffic: a batch job may accept a queued retry, while an interactive endpoint may need a stable primary and an explicit degraded mode.

Bottom line

This archived DeepSeek analysis is not a current price or routing recommendation. Its durable conclusion is more modest: a low-cost API can be valuable in a lane with objective validation, bounded retries, and a recovery path. It is a poor default when model identity, trust, or long-form quality is the product. Measure accepted-result cost, test the real prompt, and keep the failure mode visible before you optimise a token bill.