AI Token King Logo AI Token King
Get Started

Will the system prompt words be included in the AI ​​Token calculation?

Many people will have the same question after starting to use AI API: Will the system prompts and system instructions I wrote myself also be counted as tokens?

May 22, 2026

Will the system prompt words be included in the AI ​​Token calculation?

Many people will have the same question after starting to use AI API: Will the system prompts and system instructions I wrote myself also be counted as tokens?

The answer comes first: usually yes. As long as that content is sent to the model in the request, no matter it is called system prompt, system instructions, or developer instructions, in principle it is part of the input end and will affect the input token, context length, and usually the cost. This is the core point of your manuscript.

If you are searching for this question now, you usually don’t want to know the abstract definition, but you want to know three things:

Will the system prompt words eat the input token

Will the system prompt words affect the cost

Will the system prompt words be too long and the context will explode quickly

This article directly answers these three questions, and will try to explain it clearly in the most vernacular way.

Let’s talk about the most vernacular version first

You can think of an API request as a packet of data sent to the model. As long as the content in this package is usually read by the model, it is usually counted in the input side.

System prompt / system instructions you wrote

Uploaded files, pictures, PDF content

Other contexts that you actively brought into the request

So, do system prompt words count?

Forget it. The premise is that the system prompt is put into the request by yourself. This is also the principle you should adopt when making cost estimates.

Why does system prompt usually count towards token?

The reason is actually very simple: because the model does not only look at the user's question, it will also look at the entire package of information you gave it in the request.

You can understand system prompt as "you tell the background rules of the model first". Since the model really needs to read these rules, it cannot completely occupy no tokens. This is why many people know that the user question is very short, but the background input token is still very high, because what is actually sent to the model is not just a sentence, but:

system prompt

The sum of all is the input of that request.

What many people are confused about: the system prompt word is not just the paragraph "system"

Many novices think that only the paragraph marked with the system role is called the system prompt word cost. But in fact, the rules, roles, tools, and format requirements that you let the model know from the beginning often become input burdens.

Common things that eat input tokens together

Output JSON schema

In other words, it is not just the user's question that counts. Many things that you think are just "set up first" may actually be included in the token calculation.

This is why after the official product or automated process is completed, people often start to study:

How to shorten the system prompt

Which rules can be removed

Which content is worth caching

Can the tool definition be more streamlined

Because what really makes the input fat is often not the user, but the system layer itself.

Will system prompt also be included in the context limit?

This is not just a cost issue, but also a context window issue. If your system prompt is very long, has a lot of tool descriptions, plus conversation history and file fragments, you will soon find that the user only asks one question, but the entire request has become very heavy.

So if the system prompt is too long, the consequences are usually not only a slight cost increase, but may also make you:

Hit the context limit faster

It is easier for the output space to be compressed

It is easier for long tool definitions to slow down the overall cost performance

For novices, the most practical way to understand is:

The system prompt is not only about whether it costs money, it also eats up the space that the model can handle.

After caching, will the system prompt words still count?

Yes, but it may not be calculated using the general input algorithm.

If the platform has caching, the repeatedly used system prompt words or fixed prefixes may appear in usage in the form of cached input / cache read later. This is also a very important point mentioned in your original manuscript: after caching, it is not "not counted", but "it is still counted, but the algorithm usually changes, and it is often less expensive."

If you use the same long system prompt every time, you will sometimes see this in the background:

Part of it is normal input

Part of it is cached input / cache read

Some platforms may also have additional cache storage costs

So the answer is not "it doesn't count after caching", but:

It still counts after caching, but it is usually cheaper than complete resending every time.

This is why workflows with fixed rules, fixed roles, and fixed backgrounds are worth studying caching.

Is there any kind of "system content" that doesn't count as your money?

This question is very important because many people will misunderstand it here.

The more practical and safer approach is to understand it this way:

You take the initiative to send the system content of the request yourself

Usually treat it as a calculation first. This includes the ones you wrote yourself:

developer instructions

tool schema

the internal optimization tokens added behind the scenes by the platform itself

Such situations may not be counted in your paid content. You mentioned a very important detail in your original manuscript: some platforms will add some additional tokens within the system for optimization, but these provider-side system optimization tokens may not necessarily be counted in the content you are actually charged for.

For practical purposes, the safest way to judge is not to guess what is added behind the platform, but to directly use this principle:

Any system / instruction / tools / schema that you explicitly send to the request will first be regarded as affecting the input cost and context.

This is the least likely way to underestimate the cost.

Which system prompt has the greatest impact on costs?

What is most likely to inflate costs is usually not a short sentence "You are an assistant", but the following:

Very detailed formats and examples

A large number of tools/function definitions

Fixed background data that is resent with every request

What these things have in common is: they don't look like user content, but they actually consume input every time.

So many teams will later discover that what really makes input heavy is not necessarily a user problem, but that the system layer they designed is too fat.

Which column should I look at in the background to know whether the system prompt is included?

If you want to look at usage, the focus is usually on the input / prompt token related fields.

For you, the most practical method is not to guess, but to compare directly:

The first step is to keep the current system prompt and look at the input token first.

The second step is to remove or greatly shorten the system prompt and look at the input token again.

The third step is to compare the difference before and after.

If the difference is large, it means that your system prompt is very token-hungry.

Where is this type of inspection best used?

You suspect that the system prompt is too long

You think the user questions are short, but the input is very high

You are going to officially launch the process

You start to care about the monthly cost

You want to know whether it is worth shortening the prompt before revising it

For novices, this is more useful than just looking at the theory.

Because you don’t just know “how to calculate”, but you can directly know “how much you can calculate”.

AI Token calculation usually takes into account the system prompt words you provide.

As long as it is part of the request, it belongs to the input side in principle and will affect:

token usage

context window

usually also affects the cost

So a more practical notation is not to ask "Does the system prompt count?", but to ask:

Did I actively send this content into the model? If so, treat it as knowing how to calculate first.

This way is the least likely to underestimate the cost, and the least likely to be scared by the input token after going online.

System prompt words and user questions, which one counts as input?

Both are usually considered inputs. As long as they are both in the request, the models are read together. It is very clear in your original manuscript that system prompt, message input, and tools usually belong to the input side.

Does tool/function schema also count as token?

Usually yes. Because tool definitions, function descriptions, and parameter rules are essentially what the model needs to read, and they are not free backgrounds.

Does the system prompt not count after caching?

No. After caching, it is usually still calculated, but it may be changed to a more economical calculation method such as cached input / cache read.

Why does the user only ask one sentence, but the input is very high?

Because what is actually sent to the model is usually not just that sentence, but may also include system prompts, historical dialogues, tool definitions, knowledge fragments, etc.

Will system prompt affect context limit?

Usually yes. Because it is what the model wants to see, it will occupy the context space together.

Which system prompt is most likely to increase costs?

Usually a long brand specification, a lot of examples, a lot of tool definitions, a long knowledge base prefix, and fixed background information that is resent every time.

Data source and credibility statement

This article is compiled and written based on the official documents related to token counting, pricing and request structures of mainstream AI platforms, focusing on the public descriptions of input tokens, system instructions, tool definitions, cached tokens and prompt counting by OpenAI, Anthropic and Gemini. The content is organized from three perspectives: "request structure × input cost × context impact". The purpose is not just to answer whether it will count, but to help readers establish a way of understanding that is less likely to underestimate the cost. The direction of your original manuscript is correct. This version of mine is to organize it into a more complete version that can be directly uploaded to the website.

If you want to have a more complete grasp of the direction of organizing this type of content, you can go back to AI Token and take a look.

This article belongs to the category of "AI Token Computing".

This category mainly organizes the calculation method of AI Token, the difference between input and output, word count conversion, usage estimation, system prompt cost interpretation and API billing logic. It helps novices when they come into contact with ChatGPT, Claude, Gemini or other AI APIs to not only know how tokens are calculated, but also know what content will be included in the input.

How to calculate AI Token? Newbies understand the most basic calculation method

How to check the usage of AI Token? Novices can understand the backend numbers and no longer be confused

How to calculate the cost of AI Token? It can be seen most clearly from the separation of input and output

What is the AI ​​API platform? What is the difference between using chat tools directly

  • token usage
  • input tokens

AI Token organizes the basic concepts, calculation methods, API fees and model comparisons of AI Token (word elements), and covers common models such as ChatGPT, Gemini, Claude, etc. to help you establish clear understanding and judgment faster.

Function
Model comparison
Usage context
AI Token Calculator

Learn
Getting Started
Article area

Other information
About us
Privacy Policy

© 2026 AI Token. All rights reserved.

Share: X / Twitter LinkedIn
Back to Blog