Why Does Zhipu GLM-5.2 Have 4 Billing Records? A Complete Reconciliation of 3 API Requests and 10,880 Tokens

In the previous article, I documented how translating a historical WordPress post using GLM-5.2 kept returning HTTP 400, and how I ultimately succeeded by adjusting the Plaintext protection strategy and reducing the model Payload.

The execution result for post ID 4652 was:

Mode: execute
Integrity: ok
selected_count: 1

- zh=4652 result=completed category=completed returncode=0 error=

Mode: execute
Integrity: ok
selected_count: 1

- zh=4652 result=completed category=completed returncode=0 error=

After the translation finally succeeded, I originally just wanted to quickly check how many Tokens the GLM-5.2 resource pack had actually consumed.

Unexpectedly, after opening the “Fee Details” on the Zhipu Open Platform, I discovered another easily misunderstood issue:

This translation clearly only made 3 GLM-5.2 API requests, so why did 4 records appear in the fee details?

So I cross-checked the server Trace, Zhipu’s web fee details, the exported Excel, and the resource pack balance.

In the end, I finally figured out how this fee detail statistics work.

1. Server Trace clearly shows only 3 requests

During the previous troubleshooting process, I used the following on the server:

/tmp/swq-glm52-execution-trace.jsonl

to record the actual GLM-5.2 request activity.

4652 This final successful execution corresponded to three translation units:

The content finished around 17:12:00.

Further statistics on HTTP request events:

grep -c '"event":"http_request_args_before"' \
    /tmp/swq-glm52-execution-trace.jsonl

grep -c '"event":"http_request_args_before"' \
    /tmp/swq-glm52-execution-trace.jsonl

The result was:

3

3

Therefore, based on my own program execution logs, there is no ambiguity here:

This complete WordPress article translation actually called the GLM-5.2 API 3 times.

Used respectively for:

Title → Excerpt → Content

2. Yet, 4 records appeared on the fee details page

Then I opened the Zhipu Open Platform:

Fee Bills → Fee Details

After filtering the records for August 2026, I saw 4 records in the time period corresponding to this GLM-5.2 call:

【glm-5.2】模型推理

Among them:

At first glance, it’s easy to interpret this as:

4 fee records = 4 GLM-5.2 API requests.

That’s what I initially thought.

But this doesn’t match the 3 requests clearly recorded by the server Trace.

Moreover, these fee details on the webpage cannot be expanded, so there was no way to directly see exactly how many input and output Tokens each record consumed.

Fortunately, “Export Data” is provided in the top right corner.

So I exported the fee details to Excel and continued investigating.

3. Excel finally explains these 4 records

The exported fee details are much more complete than the information displayed on the webpage.

Several fields are particularly important:

用量, 用量单位, 抵扣资源包名称, 抵扣用量, 消费时间, 请求次数 (仅API), 价格类型

After extracting the 4 records corresponding to this GLM-5.2 call, the results were as follows:

Seeing this, the issue is basically clear.

4. One row in the fee details does not represent one API request

The key lies in two fields:

请求次数 (仅API)

and:

价格类型

Look at the first group first:

Here, the two rows do not each represent an API request.

In reality, this is the same group of 2 API requests that respectively generated:

Input Token fee details

and:

Output Token fee details.

And the server Trace happens to have:

17:11:25 → Title

and:

17:11:27 → Excerpt

which means two requests.

Now look at the second group:

This corresponds to:

Content

which is the single request for the content.

So the actual number of requests is:

2 + 1 = 3 API requests

And the number of fee detail rows is:

2 time periods × 2 price types (input/output) = 4 fee records

This perfectly matches the server Trace.

5. Why were the title and excerpt aggregated?

My program’s actual call times were:

17:11:25 → Title

17:11:27 → Excerpt

The two requests were very close in time.

In Zhipu’s exported fee details, they did not form separate billable items for the title request and the excerpt request, but instead both fell into:

17:11:00～17:12:00

this consumption time range.

So the exported records show:

请求次数 (仅API) = 2

Then the input Tokens and output Tokens for these two requests are calculated separately.

This also means:

You cannot reverse-engineer the number of API requests based on the “number of rows” in the fee details.

If you want to know the actual number of requests, the following in the exported data:

请求次数 (仅API)

is a much more meaningful field.

And if, as I did here, the program itself also has an HTTP Trace, further cross-validation can be performed.

6. How many Tokens did this translation actually consume?

Since I already had the Excel, I took the opportunity to calculate the exact Token consumption for this complete translation.

The first group, containing the title and excerpt:

Input:

910 Tokens

Output:

147 Tokens

Total:

1,057 Tokens

The second group, containing the content:

Input:

5,746 Tokens

Output:

4,077 Tokens

Total:

9,823 Tokens

For the entire article:

In other words, this complete GLM-5.2 WordPress article translation actually consumed:

10,880 Tokens

The vast majority of which came from the content.

7. The resource pack balance also exactly matches the 10,880 Tokens

Next, let’s look at the resource pack.

The test account originally had a:

【新用户专享】200万通用模型推理资源包

Initial quota:

2,000,000 Tokens

After this article was completed, the resource pack page showed:

1,989,120 Tokens

Let’s calculate:

2,000,000 – 1,989,120 = 10,880 Tokens

This is exactly the same as the total from the 4 GLM-5.2 fee details in the Excel just now:

10,880 Tokens

Perfectly consistent.

At this point, the data from the server, the fee bill, and the resource pack all matched.

8. Why didn’t the purchased 20 million GLM-5.2 resource pack deduct a single Token?

This test account actually also had a newly purchased:

GLM-5.2 特价尝鲜包

With a quota of:

20,000,000 Tokens

But after this translation was completed, this resource pack still showed:

20,000,000 Tokens

At first, I was worried that the purchased GLM-5.2 resource pack hadn’t taken effect.

But the Excel provided a very clear answer.

Among these 4 GLM-5.2 model inference records:

Tokens资源包名称

were all:

【新用户专享】200万通用模型推理资源包

This means that what was actually hit this time was the 2 million general-purpose resource pack gifted to new users.

Zhipu’s official fee explanation also clearly states that when a model is called, it will prioritize deducting from the resource pack that matches the applicable scenario before deducting the cash balance; if multiple eligible resource packs exist at the same time, the one expiring earlier is deducted first. (Large Model Documentation)

So the fact that the 20 million GLM-5.2 paid pack didn’t change this time doesn’t mean it hasn’t taken effect.

It’s just that another general resource pack capable of deducting GLM-5.2 currently exists, and this time it was actually used first.

9. “Post-paid” also doesn’t necessarily mean cash was deducted

There is another particularly misleading point.

In the web fee details:

付费类型

shows:

后付费

Seeing this, it’s easy to interpret it as:

These GLM-5.2 calls didn’t use the resource pack, but instead directly incurred post-paid fees.

Actually, that’s not the case.

Zhipu’s definition of “post-paid” is:

Model inference is a product type that is used first, billed later; whereas the resource pack itself is a prepaid product. (Large Model Documentation)

It describes the product billing model, rather than telling me:

“This time, money was definitely deducted from the cash balance.”

In the exported Excel:

付费类型 = 后付费

But at the same time, it clearly records:

Tokens资源包名称 = 【新用户专享】200万通用模型推理资源包

抵扣用量 = 实际 Tokens

And:

总消费金额 = 0

应付金额 = 0

未付款金额 = 0

So ultimately, no cash fees were incurred.

In the future, when seeing:

后付费

you cannot rely solely on this field to determine whether cash was actually deducted.

You also need to combine it with:

抵扣资源包名称

抵扣用量

and:

应付金额

to make a judgment.

10. If there were no resource pack, how much would this cost approximately?

The Excel also recorded the list price for GLM-5.2.

This bill shows:

Input:

0.008 元 / 千 Tokens

Output:

0.028 元 / 千 Tokens

Actual usage this time:

Input 6,656 Tokens

Output 4,224 Tokens

Calculated at list price:

Input portion:

6.656 × 0.008 = 0.053248 元

Output portion:

4.224 × 0.028 = 0.118272 元

Total:

Approximately 0.17152 yuan

This means that for this rather long historical article, after the Plaintext Payload optimization documented in the previous article, a single successful complete translation calculated at list price would only cost about:

0.17 yuan

Of course, since the gifted general resource pack was used this time, the actual final payment was:

0 yuan

11. The web fee details are suitable for viewing trends, while Excel is better for actual reconciliation

After this experience, my understanding of Zhipu’s “Fee Details” has also changed somewhat.

The webpage is great for quickly checking:

Model name, API Key, payment type, and consumption time range.

But if you want to answer:

“Exactly how many requests were made?”

“How many input and output Tokens were used respectively?”

“Which specific resource pack was deducted?”

“How much did the resource pack deduct?”

just looking at the webpage is not enough.

Only after exporting to Excel can you truly see:

请求次数 (仅API)

价格类型

抵扣资源包名称

抵扣用量

these crucial reconciliation fields.

Zhipu’s official documentation also explains that the fee bill details provide fields for reconciliation, and distinguish between information such as billing period, posting time, model product, and payment type. (Large Model Documentation)

Therefore, if I encounter fee anomalies or Token consumption mismatches again in the future, I will prioritize:

Server call logs + exported fee details + resource pack balance

cross-checking all three together.

12. This time, I finally figured out the 4 records and 3 requests

Back to the original question:

Why did 4 records appear on the fee details page when there were clearly only 3 GLM-5.2 API requests?

The answer is now very clear.

Actual server calls:

Zhipu billing:

So:

3 API requests ≠ 3 fee details

But rather:

3 API requests → 2 billing time ranges → input/output calculated separately → 4 fee details

Final Token consumption:

10,880 Tokens

Resource pack change:

2,000,000 → 1,989,120 Tokens

Difference:

10,880 Tokens

The four sets of data are ultimately completely consistent.

This time, what seemed like just an effort to figure out “why there was an extra fee record” ended up leading me to thoroughly reconcile the entire chain of Zhipu GLM-5.2, from API requests and input/output billing to resource pack deductions.

In the future, when looking at fee details, I will at least no longer simply:

count the total number of rows and assume that’s how many API calls were made.