DeepSeek Changed Its CSV Export Format (Aug 2026)

DeepSeek Changed Its Usage Export Format

If you export usage or billing data from the DeepSeek platform, you may have noticed something different recently: the amount and cost CSV files no longer carry the utc_date column you were used to. They now ship ISO timestamps instead — and the filenames themselves changed shape.

That is not cosmetic. Any tool or script that hardcoded the old columns will now fail on the new exports. Here is exactly what changed, how to read the new format, and how to keep your usage analytics working.

• The date column utc_date was replaced by start_time_iso and end_time_iso.
• user_id and (in the cost file) wallet_type are now always present.
• Filenames changed from amount-2026-8.csv to date-range names like amount-2026-08-01_2026-08-17.csv.

Amount CSV — Column by Column

• utc_date → replaced by start_time_iso / end_time_iso (ISO 8601 timestamps).
• user_id — now always present (previously optional).
• model, api_key_name, api_key, type, price, amount — unchanged.

A sample row looks like this (keys masked for privacy):

Cost CSV — Column by Column

• utc_date → replaced by start_time_iso / end_time_iso.
• wallet_type — now always present (e.g. Paid), previously optional.
• cost and currency — unchanged.

Note that the cost file still has no per-key breakdown: it is keyed by date and model only, which is why cost attribution to individual API keys still has to be done by token share.

What Stayed the Same

• The four type values are unchanged: request_count, output_tokens, input_cache_hit_tokens, input_cache_miss_tokens.
• request_count rows still leave price empty.
• cost semantics are unchanged (negative values still mean a charge).
• price and amount units are unchanged (per-token CNY prices, token / request counts).

The Date Semantics — Read This Carefully

Every row's start_time_iso is midnight of a day in China Standard Time, e.g. 2026-08-02T00:00:00+08:00, with end_time_iso at the next midnight. The billing day is simply the date part of start_time_iso — 2026-08-02.

Do not convert these timestamps to UTC when bucketing by day. 2026-08-02T00:00:00+08:00 converts to 2026-08-01T16:00:00Z, which would shift every day back by one. Since the timestamps are already localized to +08:00, just take the first 10 characters of start_time_iso and you get the correct Beijing-local day.

Filenames Changed Too

• Old: amount-2026-8.csv / cost-2026-8.csv (month-based).
• New: amount-2026-08-01_2026-08-17.csv / cost-2026-08-01_2026-08-17.csv (date-range based).

If you merge multiple exports, pairing logic that only matches amount-{year}-{month}.csv will silently ignore the new names — update your filename pattern to also accept the date-range form, deriving the month from the start date.

What It Means for Your Existing Tools

Scripts that read raw['utc_date'] will now throw a missing column error on new exports. A quick compatibility fix is to prefer start_time_iso and fall back to utc_date when present, so both old and new files keep working.

Also double-check any logic that slices the date out of a timestamp — if it converts to UTC first, every daily total will be misaligned by one day.

Our Dashboard Already Supports It

Version 0.8.0 of our free DeepSeek API Cost Tracker parses the new export format out of the box: it derives the billing day from start_time_iso, pairs the new date-range filenames, and still fully supports legacy utc_date exports. Just drag the ZIP from the platform onto the page — everything runs locally in your browser, no upload, no signup.

See the changelog for the full v0.8.0 notes.

The Bottom Line

DeepSeek's export format change is easy to miss but easy to trip over: the date column is now an ISO timestamp, and filenames are date-range based. Treat the start_time_iso date part as the billing day, keep accepting legacy utc_date exports, and update your filename pairing. If you would rather not think about any of this, our dashboard already handles both formats for you.