Qwen3.8-Max Kimi K3 DeepSeek V4 Bill Alignment

Your trial bill shows Credits for one model, input and output tokens for another, and cache discounts for the third, so the cheapest headline price does not identify the cheapest workflow.

Fastest fix: align Qwen3.8-Max, Kimi K3, and DeepSeek V4 by the effective cost of one accepted task, not by subscription price or token price.

Last updated and this week's action

Last updated August 8, 2026. We verified the billing logic against the Alibaba Cloud Model Studio pricing documentation, the Qwen Token Plan documentation, the Kimi K3 pricing page, and the DeepSeek API pricing page.

This week, export seven days of API usage and task outcomes, add the same accounting fields for all three models, and calculate cost per successful task before changing your default model.

This article is for:

• Independent developers building a reusable cost worksheet from trial bills.
• Technical leads responsible for API budgets and procurement.
• AI Agent teams that need to include retries, long outputs, tool calls, and failed runs.

The common denominator

Subscription price, Credits consumed, and price per million tokens answer different questions.

A subscription tells you how much budget you purchased. Credits tell you how much of a shared allowance a request consumed. A token price tells you the marginal charge for a specific input or output category. None of these figures proves that a model is cheaper for your actual workflow.

The comparable unit should be:

Effective cost per successful task
= total task-related cost / number of accepted task outcomes

The denominator must be a defined business result, not a successful HTTP response.

For a code Agent, an accepted task might mean:

• The requested change is applied to the repository.
• Automated tests pass.
• No high-severity regression is introduced.
• The final patch is accepted by a reviewer or an automated gate.

For document extraction, it could mean:

• All required fields are present.
• The output passes schema validation.
• A human review does not reject the result.

For a research workflow, success may require source coverage, citation validation, and a usable final report.

This distinction exposes at least four hidden cost problems:

1. A failed request can still consume budget. A timeout, malformed tool call, or partial output may create usage even when the task produces no usable result.
2. A retry changes the cost denominator. A model that succeeds after three attempts is not equivalent to one that succeeds on the first attempt, even if both final responses look similar.
3. Cached and uncached input are different cost categories. Repeating a large system prompt or repository context can be inexpensive when cached and expensive when the cache is missed.
4. Tool calls can sit outside the model token estimate. Search, scraping, code execution, or external API calls may consume Credits or create separate service charges.

The official Kimi API overview distinguishes API usage from membership products and describes API access as pay-as-you-go. That separation matters because a consumer subscription cannot automatically be treated as an API budget.

Qwen3.8-Max Credits

Qwen3.8-Max must be recorded by its exact billing product and model ID. The official Token Plan documentation identifies the model as qwen3.8-max-preview, not as an interchangeable production model, and states that the preview may later be removed or replaced. It also describes Credits as a shared unit across supported models and tools.

Can Qwen3.8-Max Credits be converted into a per-million-token price?

Not safely unless the official billing system provides both the relevant token usage and the corresponding Credit deduction for the same request. A plan may charge Credits according to model type, token usage, thinking mode, cache state, and tool calls. Without that mapping, dividing the subscription price by an assumed token volume creates a made-up exchange rate.

Use this record instead:

qwen_model_id
plan_name
plan_region
billing_period
credits_before
credits_after
credits_used
input_tokens
cached_input_tokens
output_tokens
tool_calls
request_status
retry_count
task_id
task_success

The plan documentation also describes a limited-time ten-times usage promotion and an off-peak discount window from 22:00 to 08:00 UTC+8. These are budget conditions, not permanent unit prices. Store them in separate columns so a promotional trial cannot be mistaken for a long-term forecast. Check the official Qwen Token Plan rules again before using these conditions in a procurement model.

The same rule applies to model identity. Keep qwen3.8-max-preview, any later production identifier, and other Qwen models as separate rows. Do not combine preview Credits with pay-as-you-go token charges from a different model ID.

A useful Qwen calculation is therefore:

Qwen effective task cost
= Credits consumed by all task requests
  / accepted task outcomes

If the plan price is needed for procurement, add:

Allocated subscription cost per successful task
= subscription cost allocated to the measurement period
  / accepted task outcomes during that period

The second formula captures unused allowance. That is important for low-frequency teams. A plan that looks inexpensive per Credit can still have a high effective cost if most Credits expire unused or if the workflow cannot legally or operationally use the plan for backend automation.

The official Token Plan documentation warns that the Personal Edition is intended for coding and Agent tools rather than unrestricted custom backend automation. Check the permitted usage scope before using a subscription plan as a production API substitute.

For a broader Qwen setup, our guide to Qwen3.8-Max preview quota and cost is useful for separating plan consumption from ordinary API billing.

Kimi K3 and DeepSeek V4 token records

Kimi K3 and DeepSeek V4 are easier to model mathematically because their official API documentation exposes token categories, but that does not make a simple token multiplication sufficient.

The official Kimi documentation identifies kimi-k3 as the model ID, describes a 1M-token context window, supports automatic context caching, and lists tool calls as an available capability. The Kimi API is also OpenAI-format compatible, which makes integration straightforward but does not remove the need to capture usage fields from each response. Confirm these fields in the official Kimi K3 API documentation when the model or response schema changes.

For Kimi K3, record:

model_id
input_tokens
cached_input_tokens
output_tokens
reasoning_output_if_exposed
tool_calls
request_status
http_error
timeout
retry_count
task_success

Use the live Kimi K3 pricing documentation as the price source at the time of calculation. Do not copy a rate from a third-party gateway or a consumer membership page and label it as the official API rate.

DeepSeek's official pricing documentation separates cache-hit input, cache-miss input, and output tokens. It states that the expense is calculated from token quantity multiplied by the applicable unit price. The current documentation lists deepseek-v4-flash and deepseek-v4-pro, with a 1M context length and different concurrency limits. Use the official DeepSeek pricing and usage rules for the exact model ID and charge categories in the measurement period.

For DeepSeek V4, record:

model_id
input_cache_hit_tokens
input_cache_miss_tokens
output_tokens
tool_calls
request_status
http_status
retry_count
task_success

Do not collapse cache-hit and cache-miss input into one input_tokens field. That destroys the information needed to explain why two identical prompts produced different bills.

How should Kimi K3 and DeepSeek V4 cache costs be compared?

Compare the same task under the same cache condition:

• Cold start: no reusable context.
• Continuous session: stable system prompt and repeated context.
• Changed context: a small portion of the repository, document, or instruction set changes.

Then calculate the cost of each accepted task from the actual usage response. A model with a lower cache-hit rate may be cheaper on short prompts but more expensive on long-running sessions. A model with a strong cache discount may lose that advantage when every request changes enough of the prefix to prevent a hit.

DeepSeek's official update notes on context caching also describe disk-based context caching and direct users to the current pricing page for updated rates. Treat that announcement as a reason to recheck the rate card and cache behavior, not as evidence that every workload receives the same discount.

Long documents and code repositories

Long-context work creates three separate cost variables:

• The amount of historical input repeated on every request.
• The percentage of that input that receives a cache hit.
• The output length required to finish the task.

A document review workflow may send the same policy library across several turns. A code Agent may resend repository instructions, file summaries, tool schemas, and previous edits. The input volume can be large even when the user message is short.

Measure the workflow in three passes.

1. Cold-start pass: create a new session and send the full task context.
2. Continuous-session pass: repeat related tasks without changing the stable prefix.
3. Context-change pass: modify the system prompt, repository state, or document version, then observe which input tokens remain reusable.

For each pass, retain the raw usage response and a task ID. Do not infer cache behavior from latency alone. A fast request is not proof of a cache hit, and a slow request is not proof of a cache miss.

The cost formula should separate the input categories:

Model request cost
= uncached input tokens × uncached input rate
+ cached input tokens × cached input rate
+ output tokens × output rate
+ explicit tool charges

For Qwen3.8-Max, replace the token-rate calculation with actual Credits consumed when the plan does not expose a defensible token-to-Credit conversion. For Kimi K3 and DeepSeek V4, use the provider's documented cache categories and the usage fields returned by the API.

Reminder: Never assume that a 1M-token context window means a 1M-token task is economical. Context capacity is a limit; it is not a discount, a cache guarantee, or a success criterion.

Choose context reuse only when the workflow benefits from it. Stable repository instructions, repeated document sections, and multi-step review sessions are good candidates. One-off prompts, rapidly changing search results, and highly personalized user context may be better served by input compression.

A practical compression policy can include:

• Remove completed tool transcripts after extracting their result.
• Replace unchanged file contents with hashes or summaries.
• Keep the acceptance criteria visible in every task.
• Store large reference material outside the prompt and retrieve only the relevant sections.
• Re-run the cache measurement after changing the system prompt.

Programming Agents and retry cost

A programming Agent does not consume one request per user question. It may call the model, inspect a file, invoke a shell tool, run tests, analyze an error, revise the patch, and repeat the cycle.

That means the unit of accounting must be the complete task trace.

Count:

1. Initial planning request.
2. File inspection or repository search.
3. Code generation or patch request.
4. Tool execution.
5. Test or build execution.
6. Error diagnosis.
7. Retry or continuation.
8. Final validation request.
9. Any external tool or service charge.

A model's one-call price is not its Agent cost.

Why does a programming Agent cost more than the price-page estimate?

The price-page estimate usually assumes a single input and output pair. An Agent budget includes failed tool calls, repeated context, long reasoning output, test-fix loops, timeout recovery, and sub-agent requests. A task that needs four model calls and two tool calls cannot be estimated from the final answer's token count.

Use this formula:

Complete Agent task cost
= sum of all model charges in the trace
+ sum of tool charges
+ external service charges

Then calculate:

Agent effective cost
= complete Agent task cost / accepted repository changes

Separate model charges from external costs. A search API, browser service, code runner, hosted database, or build machine may be billed independently. If those costs are hidden inside a Credits plan, record them as a distinct component whenever the console provides that detail.

DeepSeek's API documentation lists tool calls as supported and shows account-level concurrency limits of 2,500 for V4 Flash and 500 for V4 Pro. Those limits affect throughput planning and can produce 429 retries when an Agent team exceeds its account capacity. They are operational constraints, not direct prices, but they can raise effective task cost when retry logic is poorly controlled.

Kimi's documentation similarly describes tool calls, reasoning controls, and a two-hour request timeout in its official API overview. Capture timeout and retry fields instead of treating every non-success response as free.

A seven-step normalization workflow

Use the following process before selecting a default model.

1. Freeze the task definition. Write the acceptance criteria, expected output format, required tools, and failure conditions.
2. Assign one task ID. Every request, retry, tool call, and continuation must carry the same trace identifier.
3. Run equivalent samples. Use the same prompt, input files, repository snapshot, tool permissions, and stopping rules for each model.
4. Export raw usage. Save the provider response, console usage record, Credit balance change, cache status, and error code.
5. Separate request classes. Keep preview, production, subscription, pay-as-you-go, batch, and promotional traffic in different groups.
6. Mark acceptance independently. A HTTP 200 response is not a successful business task unless the output passes the agreed validation.
7. Calculate the decision metric. Compare total cost per accepted task, then inspect cache, output, retry, and tool components.

Do not fill missing fields with zero. Use unknown for unavailable usage data. A zero retry count means the trace was checked and no retry occurred; it should not mean that retry data was never collected.

Decision branches for model selection

Use these conditions rather than creating a forced overall ranking:

• If the workload is low-frequency and Qwen3.8-Max Credits are regularly unused, choose the plan only after calculating allocated cost per accepted task; otherwise, compare against direct token billing.
• If requests are high-volume and stable, choose Kimi K3 or DeepSeek V4 only after the same task set has measured output length, cache-hit ratio, and failure rate.
• If long documents or repositories repeat a stable prefix, favor the model with the lower measured cached-input cost and a higher accepted-task rate; otherwise, compress context before switching models.
• If an Agent performs many retries, choose the model with the lower end-to-end cost per accepted task, not the lower first-call price.
• If tool charges, data-control requirements, or service continuity exceed the team's tolerance, stop treating API price as the only variable and evaluate open weights with self-hosted compute.
• If the sample is too small to distinguish the models, run them in parallel instead of publishing a three-model ranking.

A small test set can be misleading. One long document may favor caching, while one short coding task may favor lower output cost. Keep the scenario labels visible in the final report.

For deployment planning, our Qwen3.8-Max local runtime and tool guide helps separate API expenditure from local runtime requirements. The two decisions should remain separate until the usage data shows that self-hosting is worth the operational burden.

When API billing becomes a deployment decision

API billing is not the only cost.

The current API-first approach can create:

• Variable monthly spend when Agent retries expand unexpectedly.
• Dependency on provider-side model IDs, cache rules, quotas, and service continuity.
• Limited control over data routing and runtime behavior.
• Extra integration work when a preview model becomes a production model or changes its billing product.

Self-hosting can address some of those issues, but it adds hardware acquisition, model loading, storage, monitoring, power, software updates, and operational responsibility. It is not automatically cheaper for low-volume or irregular workloads.

A cloud Mac can be a useful middle path when the team needs a repeatable Apple Silicon environment for Agent orchestration, local tools, build verification, or self-hosting experiments without purchasing hardware. JexMac's Mac rental options are most relevant when the requirement is temporary compute, a controlled test environment, or a deployment trial rather than permanent high-volume inference.

Before making that move, export one week of usage and task outcomes. If the normalized report shows that retries, environment continuity, or self-hosting validation now dominate the cost, the next step is to compare API-only operation with a controlled Mac-based deployment. If the workload remains low-volume, highly variable, or dependent on physical interfaces, continuing with an API may still be the more honest choice.