Prompt Caching

Caching is automatic — no parameter to set. Here is exactly what it costs on each tier.

#How it works

Prompt and response caching is fully automatic. There is no cache-control parameter to set — repeated and short queries are served efficiently by default, with nothing to configure on your side.

#Seeing cache hits

Every response surfaces cache activity in metadata.usage.cached_tokens, so you can see, per call, how much of the request was served from cache.

{
  "answer": "...",
  "metadata": {
    "usage": {
      "input_tokens": 12084,
      "output_tokens": 291,
      "total_tokens": 12375,
      "cached_tokens": 11820
    }
  }
}

Tip

Keep context stable to maximise cache hits — reuse the same birthDetails and a stable conversationId across follow-up turns instead of re-sending fresh values each time.

#Cost impact

Caching changes your bill in two distinct ways. Which one applies depends on whether the whole answer was reused, or only part of the input was.

#1. Answer-cache hit — flat $0.01, every tier

When you repeat an identical question for the same chart, the answer is served from the Vedika answer cache without calling the reasoning engine at all. That call bills a flat $0.01 on every tier, and the usage block reports zeros because no tokens were generated:

{
  "metadata": {
    "cost": { "costUsd": 0.01, "currency": "USD" },
    "usage": { "input_tokens": 0, "output_tokens": 0,
                "cached_tokens": 0, "total_tokens": 0 }
  }
}

#2. Reused input inside a live answer

When the engine does run but part of your input is reused, those cached input tokens are priced per tier. Vedika passes through the economics of the delivery path each tier runs on: some paths bill reused input at a genuinely lower rate, and some bill it at the normal rate and return the benefit purely as speed.

Tier	Cached input tokens	What caching buys you
Vedika Eco	Reduced rate — roughly 60% of the fresh-input rate	Lower cost and lower latency
Vedika Standard	Same rate as fresh input	Latency only — no per-token discount
Vedika Standard 2.5	Same rate as fresh input	Latency only — no per-token discount
Vedika Swift	Same rate as fresh input	Latency only — already the fastest tier
Vedika Pro Ultra	Same rate as fresh input	Latency only — no per-token discount

Note

This is deliberate, not a markup choice: Vedika bills reused input the way the underlying delivery path bills it. Where a path gives a cache discount, you get it; where its cache only improves time-to-first-token, you get the speed and the price is unchanged. Whatever the tier, metadata.cost.costUsd on every response is the exact amount charged.

See Pricing for the full per-call rate table and Model Catalog for the per-tier capability grid.