Billing

Platform API requests are paid from your workspace. Most workspaces are prepaid: you buy credits up front and each request deducts its cost. Some organizations are instead billed by invoice, see Billing by invoice.

Everything here lives in the Platform API under Billing and Budgets & limits. Changing it needs the role permission Manage credits and spending limits.

The same balance also pays for pay-as-you-go chat and for Workflows.

Credits

Purchasing credits

On the Credits tab of Billing, click Purchase Credits and choose a package or a Custom Amount between €5 and €1,000. You need a credit or debit card as the default payment method; other payment methods can't be charged for credit purchases.

All prices are shown excluding VAT, which is added at checkout.

Credit balance

The Credits tab shows Total Available Credits, the Estimated Range in days at your current pace, and your spend over the Last 7 Days and Last 30 Days with the Daily Average.

Purchased credits expire 3 years after the purchase date and are consumed oldest first. The Credit History lists every purchase with its remaining amount and expiry date. Download invoice on a purchase gives you its invoice.

How credits are deducted

Each successful request deducts credits according to what it used:

• Text completion: per input token and per output token, with separate rates for cached input.
• Embeddings: per input token.
• Images: per image, depending on quality and size.
• Video, avatar video, speech, transcription and music: in the unit the model is priced in, for example per minute of generated music.
• Web search: a flat rate per request.

The rates depend on the model. You find them on Models & pricing in the Platform API and publicly on Models & pricing.

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 organization'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, because 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.

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 adds credits to your workspace when the balance falls below a threshold, so your integrations keep running.

Setting up auto top-up

Payment methods

On the Payment Methods tab, Manage Payment Methods opens the billing portal of our payment provider. There you add or remove cards and choose the default, which is used for purchases and auto top-up.

Card details are stored by the payment provider, Stripe. DeutschlandGPT never stores them.

Complete setup

The Credits tab shows Complete setup with three steps: Add a payment method, Add credits and Enable auto top-up. Each step has its own button, and the box disappears once all three are done.

Monthly spending limit

To cap the workspace's total spend for a calendar month, open Budgets & limits and set the Monthly Limit (€). Leave the field empty for no limit.

Once the limit is reached, requests return 402 Payment Required until the next month starts or you raise the limit.

The same page links to the other limits under Other limits: the Chat budget per member, the API key limits set on each key, and the Workflow budgets.

Billing by invoice

Some organizations are billed by invoice instead of from a prepaid balance. Their billing page says Billed by invoice and there is nothing to top up. Usage is invoiced monthly, quarterly or yearly, depending on the agreement. The invoices for this usage are listed on the Invoices tab of Billing, visible to everyone with the permission Manage billing and licences; licence invoices are under Organization settings → Billing & usage → Billing.

• Open, not yet invoiced shows what will appear on the next invoice.
• A credit line caps the usage that has not been invoiced yet. It is released again once the next invoice is issued. Without a credit line nothing can be billed.
• If the workspace also has credits, they are spent first.

The billing mode and the credit line are agreed with DeutschlandGPT. Contact Support to change them.

Usage overview

The Credits tab shows your balance and recent spend. Usage breaks spending down by API key, model and time range and exports it as a spreadsheet. See Dashboard.

Notifications

On the Notifications tab of Billing, the master switch Send notification emails turns all billing emails on or off. Below it you choose the individual notifications:

Each notification is sent at most once every 24 hours.

Invoices

Every credit purchase has an invoice. Download it with Download invoice in the Credit History, or find all invoices in the billing portal behind Manage Payment Methods. Invoices are kept for 10 years, as German tax law (§147 AO) requires.