Question 1

Why does the system prompt cost money on every request?

Accepted Answer

Because the API is stateless — it does not remember your previous call — so anything you want the model to know each time has to be sent each time. The system prompt, the persona and rules, few-shot examples and the JSON schemas of your tool definitions all live in that fixed preamble, and every one of them is counted as input tokens on every request. A user who types a single word still pays for the entire preamble that rode along with it. That is why a bloated system prompt behaves like a fixed tax: it does not scale with how much the user actually said, it is charged in full on the smallest and largest requests alike. This calculator isolates that fixed cost so you can see it as a line item instead of a hidden part of the total.

Question 2

How much of my bill is the system prompt?

Accepted Answer

It depends on the ratio of your fixed preamble to the variable content of each request. If your system prompt is two thousand tokens and a typical user turn plus retrieved context is only five hundred, the preamble is most of your input tokens and can dominate the bill — especially on short, high-volume calls like classification or routing where there is barely any user text to dilute it. If your requests carry long documents or full chat histories, the fixed preamble is a smaller slice. The dangerous case is high volume plus short requests plus a long prompt, because the tax is multiplied by every call. This calculator prints the system prompt as a share of your total monthly input-plus-output cost so you know whether it is worth trimming.

Question 3

Does prompt caching remove the system prompt cost?

Accepted Answer

It removes most of it, on the calls that hit the cache. Prompt caching lets the provider store a stable prefix — your system prompt is the perfect candidate because it is identical every time — and bill reads against it at a steep discount, commonly around 90% off the normal input rate, so a cached system prompt costs roughly a tenth of an uncached one. The catch is that only requests arriving while the cache is warm get the discount, there is sometimes a small premium to write the cache, and the prefix has to be byte-for-byte identical, so a timestamp or a per-user string near the top breaks it. This calculator lets you set both the cache discount and the share of requests that hit the cache, then shows the reduced system-prompt cost and the dollars saved.

Question 4

Is it better to trim the system prompt or cache it?

Accepted Answer

Do both, but they solve different problems. Trimming cuts the number of tokens in the preamble, which lowers the cost on every request including the ones that miss the cache, and it also frees context window and can improve the model's focus. Caching leaves the prompt long but makes the repeated reads cheap on warm calls. Trimming is the more robust win because it helps unconditionally, while caching depends on your traffic keeping the cache warm and on the prefix staying identical. A good order of operations is to strip the prompt of anything that is not earning its tokens — verbose instructions, redundant examples, tool schemas you rarely call — and then cache what remains. This calculator shows both levers side by side so you can compare a 30% trim against turning caching on and decide which to reach for first.

システムプロンプトコスト計算ツール

入力トークンの行き先

プロンプトサイズによる税金の調整方法

一度書いたプロンプトは、100万回支払うことになる

この計算機の仕組み

よくある質問

システムプロンプトではリクエストごとに料金がかかるのはなぜですか?

システムから請求される金額はいくらですか?

プロンプトキャッシュによってシステムプロンプトコストが削減されますか?

システムプロンプトをトリミングするのが良いでしょうか、それともキャッシュした方が良いでしょうか?