Billing

The Platform API uses a prepaid credit model. You buy credits up front, and each API request deducts the corresponding cost from your balance. Requests are rejected with a 402 Payment Required error when your balance reaches zero.

All billing is managed in the Platform API billing dashboard.

Credits

Purchasing credits

Go to Billing → Credits and choose a credit package or enter a custom amount (€5–€1,000). Payment is processed immediately via Stripe.

Credit balance

Your current balance is shown at the top of the Credits tab. Purchased credits expire 3 years after the purchase date (in accordance with §195 BGB) and are consumed oldest-first (FIFO).

How credits are deducted

Each successful API request deducts credits based on:

• Text completion — priced per input token and per output token
• Embeddings — priced per input token
• Image generation — priced per image, depending on quality and size

The exact per-token and per-image rates depend on the model. You can see per-model pricing on the Dashboard → Models page.

What a request cost, in the response

Every text-completion response reports its own price. /v2/chat/completions and /v2/responses both return it on usage:

"usage": {
  "prompt_tokens": 291339,
  "completion_tokens": 5,
  "total_tokens": 291344,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 291336 },
  "pricing": {
    "tier": "long_context",
    "currency": "EUR",
    "long_context_threshold_input_tokens": 272000,
    "input_per_1m": 0.44,
    "output_per_1m": 2.0,
    "cache_read_per_1m": 0.05,
    "cache_write_per_1m": 0.56
  },
  "cost": 0.16315948
}

cost is what was deducted from your credit balance, in EUR. pricing is the set of rates that produced it — your rates, after your organisation's price multiplier, not catalogue figures. Both come from the same ledger write that charged you, so they cannot disagree with your invoice.

On a streamed request the block rides on the usage chunk, so you need stream_options: { "include_usage": true } to receive it.

Two fields are omitted when they do not apply: cache_write_1h_per_1m on a model that does not charge for cache writes, and long_context_threshold_input_tokens on a model that bills one flat rate at every context size. The whole block is absent for a model you brought your own key for, because we charged you nothing for it.

Long-context pricing

Some models charge more once a single request's input crosses a threshold — typically 272,000 tokens for OpenAI models and 200,000 for Google ones. Above it the entire request is re-priced: input, cache reads, cache writes and output all bill at the long-context rates, which are usually double the short ones.

The threshold applies per request, not per conversation. Twenty requests of 15,000 tokens each are all billed at the short rates; one request of 300,000 tokens is not.

usage.pricing.tier tells you which of the two you paid, on every request. The thresholds and rates for each model are on Models & pricing and on Dashboard → Models; a dash there means the model has no long-context tier.

Prompt caching

For Anthropic models you can mark a stable prefix of your request with cache_control so it is cached upstream and re-used by later requests. Send the marker on the last element you want inside the cached prefix — a system message, a text content part, or a tool definition:

{
  "model": "claude-sonnet-5",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "<long, unchanging instructions>",
          "cache_control": { "type": "ephemeral" }
        }
      ]
    },
    { "role": "user", "content": "What changed today?" }
  ]
}

You place every breakpoint yourself. We never add one on your behalf, so a request with no cache_control is not cached at all — a cache write costs more than an uncached read, and only your access pattern says whether it will pay for itself.

A cache write costs 1.25× the input rate at 5m and 2× at 1h — and only /anthropic/v1/messages can reach 1h (see above).

At most four breakpoints per request. If you send more, the latest four are kept — those are the ones that make your next request cheap — and the response tells you (see What we do with your markers). The field is ignored by non-Anthropic models, so it is safe to leave in place while switching models.

Where a breakpoint lands

A breakpoint caches everything up to and including the element you marked, so where you put it decides what gets re-used:

• On a content part, the boundary is at that part. This is the usual shape — a long stable document as the first part, your varying question as the second, marker on the first — and it is honoured exactly: the document is cached and the question is not.
• On a message, the boundary is at the end of that message.
• On a tool definition, the tool block is cached. The breakpoint is placed on your system message — Anthropic orders tools → system → messages, so a prefix ending there covers the tool block in front of it. This needs a system message in the same request; without one the marker is dropped and reported, because the only other place to put it is your first user turn, which changes every request.

The one place a boundary cannot be exact is a system message with several blocks: it is sent as a single block, so a marker on anything but the last one widens to cover the whole system prompt. If text after your marker varies between requests, the cache will not be read — put that text in a user message instead. The response says so when this happens.

What we do with your markers

If we cannot honour a marker exactly as written, the response says so in prompt_cache rather than leaving you to infer it from your bill:

{
  "prompt_cache": {
    "cache_write_tokens": { "5m": 11219, "1h": 0 },
    "warnings": [
      {
        "code": "marker_dropped_no_anchor",
        "message": "1 cache_control breakpoint(s) on tool definitions could not be placed…"
      }
    ]
  }
}

cache_write_tokens is the per-TTL split the upstream host reported — the two numbers that explain a cache-write charge. The field is omitted entirely when there is nothing to report, so a request without cache_control is unchanged.

On /anthropic/v1/messages the per-TTL split is returned in Anthropic's own field instead — usage.cache_creation.ephemeral_5m_input_tokens and …_1h_input_tokens — and prompt_cache carries only the warnings, since Anthropic's own API has no field for them.

Marking a tool definition caches the tool block, and the system prompt with it, since Anthropic orders tools first. It requires a system message in the same request: with none, the marker is dropped rather than moved onto your first user turn, which changes on every request and would never produce a hit.

The response reports what happened, inside usage.prompt_tokens_details on /v2/chat/completions and usage.input_tokens_details on /v2/responses:

Both rates differ per model and some models charge nothing to write, so read the exact figures off Models & pricing — or off usage.pricing in your own response, which reports the rates that request was billed at.

prompt_tokens / input_tokens is the inclusive total: both fields above are subsets of it, not additions to it. Caching only saves money when the prefix is re-sent — a write costs more than an uncached read, so mark a prefix you will send again, not a one-off request.

Prompt caching is enabled per organisation, and until it is, every input token — cached or not — is billed at the full input rate. What that gate does depends on the endpoint:

• On /v2/chat/completions and /v2/responses, cache_control is accepted and ignored, and cache_write_tokens is absent from the response. prompt_cache.warnings says so explicitly (markers_ignored_disabled) rather than leaving the markers to vanish quietly.
• On /anthropic/v1/messages, breakpoints have always been honoured and still are, and cache_read_input_tokens / cache_creation_input_tokens are reported as usual. Only the rate you are billed changes. ttl: "1h" is honoured here regardless of the gate, as it always has been.

Contact support to have it enabled for your organisation.

Mistral models: prompt_cache_key

Mistral caches prefixes automatically. There are no breakpoints to place, and cache_control does nothing on a Mistral model. What a Mistral request needs instead is prompt_cache_key — a stable, opaque string naming the cache lane the request belongs to:

{
  "model": "mistral-small-4",
  "prompt_cache_key": "conversation-42",
  "messages": [{ "role": "user", "content": "What changed today?" }]
}

Send the same value for every request that shares a prefix — one conversation, one session, one workflow run. Requests carrying the same key are routed to the same cache node, which is what lets the second request find the first one's prefix. It is accepted on /v2/chat/completions and /v2/responses, and /v2/responses echoes it back.

Three consequences worth knowing before you wire it up:

• There is nothing to opt into and nothing to spend. Unlike an Anthropic breakpoint, Mistral charges no cache-write premium: a cached read is 10% of the input rate and a miss is simply the normal input rate. A lane that never gets re-read costs exactly what the request would have cost anyway. That is why we always set a key — yours when you send one, your workspace when you do not — instead of asking you to opt in.
• A hit is a likelihood, not a guarantee. Mistral's own documentation says the key raises the chance of a hit rather than promising one, and measurement agrees: on one repeated prefix we saw close to 100% on some Mistral models and well under half on others, with no gap between requests short enough to fix it. Treat the saving as a discount you often get, not a rate you can budget against. Mistral also caches in 64-token blocks, so cached_tokens is always a multiple of 64 and a short prefix may not be cacheable at all.
• Your value is namespaced to your workspace. We hash it together with your workspace id before it leaves us, so two tenants who both send "default" never share a lane and your key cannot aim at anyone else's cache. It is a routing hint, not an isolation boundary — do not put secrets or personal data in it.

/anthropic/v1/messages takes no prompt_cache_key, because Anthropic's wire format does not define one. A Mistral model served through that endpoint uses your workspace as its lane.

Auto top-up

Auto top-up automatically adds credits to your workspace when your balance falls below a threshold, so your integrations stay running without manual intervention.

Setting up auto top-up

Payment methods

Open Billing → Payment Methods and click Manage to add or remove cards in the Stripe Billing Portal. You can save multiple cards; the default is used for purchases and auto top-up.

Payments are processed by Stripe. DeutschlandGPT does not store raw card details.

Monthly spending limit

To cap your total API spend for a calendar month, set a monthly spending limit on the Billing → Credits tab.

Once the limit is reached, all API requests return 402 Payment Required until the start of the next month or until you raise the limit. The limit resets at the beginning of each calendar month.

Setting the limit to no limit allows unlimited spending (subject to your credit balance).

Usage overview

Billing → Credits shows your current balance, this month's spending, and a chart of daily usage.

Dashboard → Usage breaks down spending by API key, model, and date range — useful for tracking which integrations are consuming the most credits.

Notifications

Configure email alerts in Billing → Notifications:

Each notification type has a 24-hour cooldown to avoid repeated emails.

Invoices

Stripe invoices for all credit purchases are available in the Stripe Billing Portal — open it from Billing → Payment Methods → Manage. Invoices are retained for 10 years in accordance with §147 AO.