Models and Cost

LLM API Cost Guide: Choosing Top-Ups or a Monthly Subscription

Estimate AIFast Link GPT, Claude and Gemini API costs by tracking top-ups, monthly subscriptions, live prices, quotas and actual tokens separately. Do not mix billing data or outdated prices from other sites.

Updated on 2026-10-15Checked on 2026-10-08Estimated reading time: 9 minutesSuitable for LLM API usage and budget management
Configuration fields were checked against public documentation. Models, prices, and capabilities can change; verify current values in the console and live API responses.
Topic: What Is an OpenAI-Compatible API? Scope and Limits

Estimating AIFast Link GPT, Claude and Gemini API costs requires more than one model's rate. In addition to prompt history, output length, failed retries, tool loops and routing, first distinguish whether the account uses top-ups or a monthly subscription. This guide does not hard-code prices; use the Link console, pricing page and checkout terms shown on the test date.

Check before you start

First collect a batch of real business samples, including at least:

  1. General short questions and answers.
  2. Multiple rounds of conversations with history.
  3. Long documents or code input.
  4. Tool call or Agent task.
  5. Failures, timeouts, and retry requests.

The model price, magnification and available range are subject to the real-time display on the AIFast console and price page.

Link currently offers GPT, Claude and Gemini models with top-up and monthly subscription options. Prices, model scope, quotas, validity, renewal and cancellation terms can differ, so check the current terms shown to your account.

Comparison item Pay as you go Monthly subscription
Check first Payment amount, credited balance and balance validity Billing period, available models, included quota or usage limits
Billing records Usage per request, model rate, failed requests and retry charges Monthly fee, requests during the period, extra charges or limits
Suitable cost calculation Calculate from actual request tokens and current rates Confirm what the subscription includes, then assess total usage for the period
Do not assume That the payment amount equals a fixed number of tokens That the monthly fee converts directly to a fixed token rate

If checkout does not clearly state subscription quota, model scope or overage handling, mark the item as unconfirmed; do not assume unlimited use or a fixed discount. Summarize top-up and subscription request results separately.

Monthly plans last 30 days, reset daily and apply only to their specified group. Consult the dated plan comparison. Compare actual usage days; a daily allowance is not a monthly balance available all at once.

When the current input price and output price have been obtained, you can open Token cost calculator and enter actual token usage, planned task count and the additional billed retry percentage to establish a reproducible batch-cost baseline.

Count only additional retries that were actually billed. For 100 planned tasks and 8 extra retries of which only 3 were billed, enter 3%, not 8%. This estimate assumes the same input and output token counts and unit prices for each retry as for the original task. Reconcile different usage, caching and tool fees separately. Zero without logs is provisional, not evidence of zero retry cost.

To reproduce the calculation locally, use the dedicated AIFast Link repository: Cost formula and offline examples in Chinese or English cost formula and examples. The examples require no API key and make no model requests. Their inputs are illustrative, not current offers or records of real calls.

Link's public catalog places Gemini in a separate group outside GPT/Claude monthly plans. If a workflow uses Claude for coding and Gemini to analyze inputs, record their usage separately. Do not assign every request to the Claude plan.

Requests in the workflow Where to account for usage Required checks
GPT or Claude in the plan's specified group That day's plan allowance The model ID, key group and validity period all match the plan
Eligible-group requests exceeding the daily allowance Wallet overage charges or blocked requests Whether both the plan and account billing preference allow wallet fallback
Requests in the separate Gemini group Separate usage-based charges Gemini group access, model prices and actual usage

Record usage day by day instead of dividing monthly token totals by the subscription fee:

eligible_daily_credits = actual daily usage in the plan's specified group
daily_overage = max(0, eligible_daily_credits - daily_plan_allowance)
monthly_cash_cost = plan_payment + sum(actual_wallet_charges)

Wallet charges may include daily overages and requests outside the plan, such as Gemini. Include both without double-counting. If wallet fallback is not allowed, unfinished overage tasks are not covered usage. Do not add Credits directly to CNY amounts.

For example, suppose Claude tasks consume 24 Credits in a day with a 20-Credit plan allowance, alongside Gemini requests. The daily plan allowance can cover only 20 Claude Credits. Reconcile the remaining 4 Credits and the Gemini requests separately against wallet charges. The values 24 and 20 are illustrative inputs, not plan offers; they do not imply that a Credit buys the same token count for both models.

Compare the same tasks using actual prices for each applicable group, retaining failed retries and unfinished tasks. Enter active days and overage costs in the Link pay-as-you-go vs monthly plan calculator. Calculator examples do not replace billing records.

Configuration steps

If the API returns usage, save at least:

{
  "model": "YOUR_MODEL_ID",
  "prompt_tokens": 0,
  "completion_tokens": 0,
  "total_tokens": 0,
  "retry_count": 0,
  "status": "success"
}

The above uses Chat Completions common prompt_tokens、completion_tokens and total_tokens. The Responses API or other compatible APIs may use different field names, which must be parsed according to the actual response. Account reconciliation is based on console records, and application logs are used to analyze request structure and trends.

2. Use a repeatable cost formula

cost per task
= Enter usage × Enter unit price
+ Output usage × Output unit price
+ Retry request cost
+ Additional request costs incurred by tool loops

Don’t just count the one time you finally succeeded. If content has been previously generated but the client times out, the related request may still generate usage.

3. Find the most common hidden costs

Hidden costs Check method
Send the entire history repeatedly every round Record whether input_tokens continues to grow rapidly in each round
There is no length limit on the output Check if the task requires explicit stopping conditions or output structures
Retry infinitely after failure Record retry_count and final status
Agent tool loop Record the number of model requests for each tool step
All tasks use the same high-cost model Statistics of quality and cost according to task difficulty
Regenerate after streaming interruption Set idempotent status for tasks and retain completed status

4. Routing model by task

First create a small evaluation set by task type, and then decide on the route:

  • Classification, extraction, format conversion: Prioritize evaluation of low-latency, low-cost models.
  • Complex code, long reasoning: focus on comparing success rate and number of reworks.
  • Images, videos, retrieval: separate statistics based on actual input and output units, cannot be directly applied to the text Token formula.
  • Agent: Count the total number of calls required for a complete task to succeed, rather than just looking at a single price.

A model that is cheap but often reworked may cost more for a complete job; a model that is more expensive but is done once and for all may also be better suited for critical processes.

5. Set up budget protection

It is recommended to set both:

  • The maximum output length of a single task.
  • The number of requests per minute for a single user.
  • Maximum number of tool cycles per task.
  • Single day or single project budget reminder.
  • Abnormal retry and usage sudden increase alarms.

FAQ

Why console charges and local estimates don't exactly match

Possible reasons include price multiplier changes, caching or inference usage breakdown, streaming interruptions, retries not being accounted for, missing local fields, or asynchronous accounting delays. Financial reconciliation should be based on the console bill.

Does the shorter the input, the cheaper it must be?

Usually the amount of input required can be reduced without sacrificing information necessary for the task. Excessive compression causes the model to repeatedly query or output errors, which may increase the total number of calls. The total cost of "completing a business task" should be compared.

How to judge whether you should change the model

Also compare success rates, manual rework time, delays, and complete task costs. Sorting only by unit price cannot reflect the real business results.

Next step

Create weekly usage reports grouped by model, API, user, business function and error type. Fix infinite retries, history bloat, and tool loops first before considering more complex routing strategies.

When you need to compare multiple models or portals, useModel API comparison test templateUnifiedly record task completion rates, tokens, delays, errors and manual rework.

Source checked

Reference and Check Sources

Next step

Test the current API before fixing, migrating, or creating a test key

Use a temporary, limited key to inspect model declarations, token fields, SSE, and tool calls. Review current models and pricing only when you need a replacement API.

Model Quality CheckModel PricingCreate Account