Estimating a Session's USDC Cost Before You Start: Input, Output and the 1.3x Rule on One Key

Why estimate before you send

A session costs money in proportion to tokens moved. If you can guess the prompt size and the completion size, you can put a USDC figure on the run before you touch your balance. That matters for two reasons: you avoid a half-finished run when a balance runs out mid-session, and you can compare candidate models on cost before committing to one.

The arithmetic is short: official price of the tokens consumed, times the site's 1.3 multiplier. Everything else is bookkeeping.

Step 1: Count the input side

Input tokens are everything the model reads on each call. In an interactive session this includes more than your typed message.

• System and instructions — fixed text you send every turn.
• Conversation history — each new turn usually resends prior turns, so history grows the input side turn after turn.
• Retrieved context — documents, tool outputs, or file excerpts pasted in.
• The current message — usually the smallest part.

A rough way to size text without a tokenizer: short English prose runs a few characters per token, so a page of text is on the order of a few hundred tokens rather than a few dozen. For a precise count, run your exact strings through the tokenizer for the model family you plan to use. Estimates are fine for budgeting; exact counts are what the invoice reflects.

Watch the compounding effect. If each turn resends the whole history, then input tokens per turn grow roughly linearly with turn count. A ten-turn chat does not cost ten times a one-turn chat on the input side — it costs more.

Step 2: Count the output side

Output tokens are what the model writes back, including any reasoning or tool-call text the model emits. To size a session:

• Estimate a typical reply length in tokens, not words.
• Multiply by the number of replies you expect, plus retries and regenerations.
• Add slack for long answers — summaries, code blocks, and structured output all run longer than chat.

If your client streams, you still pay for tokens generated; stopping a stream early only saves the tokens you never generated.

Step 3: Look up the official price for the model

The price per input token and per output token differs by model, and often output costs more per token than input. Get the official rates from the model provider's pricing page and use those numbers. Because this site bills at official price times 1.3, an estimate built on official rates stays valid as long as the official rate does.

Keep input and output rates separate in your sheet. Applying one blended rate is the most common source of a wrong estimate.

Step 4: Apply the 1.3x rule

Once you have a token bill at official rates, multiply by 1.3 to get what the session draws from your USDC balance.

official_cost = input_tokens × input_rate + output_tokens × output_rate
session_cost_usdc = official_cost × 1.3

That is the whole rule. No KYC step and no separate fee line changes it: you top up USDC on Base, and the balance is drawn down at the 1.3x rate for whichever model you call.

Two related facts are worth keeping straight, because they are easy to mix up with your own bill:

• Contributors to the platform are credited at official price times 1.1, or 1.2 for premium contributions, paid in USDC. That is their compensation, not a discount on what you pay.
• Your cost does not shrink to a fraction of official price. The multiplier on your side is 1.3. Do not build a budget on a lower number.

Worked pattern (no invented numbers)

Rather than a fabricated price table, use this template and fill in the real rates for the day:

1. Sum expected input tokens across all turns, including resent history.
2. Sum expected output tokens across all turns.
3. Multiply each by that model's official input and output rates.
4. Add the two products, then multiply by 1.3.
5. Compare the result with your USDC balance, leaving headroom for retries.

Run the same template for a second model to see whether switching changes the picture. Because one key reaches Claude, GPT, DeepSeek, Qwen, GLM and Kimi, you can switch models without opening a new account or moving funds.

Practical habits that keep estimates honest

• Budget for history growth. Recompute after every few turns; early-turn estimates drift low.
• Set a turn or token ceiling per session. Decide in advance how long a run may go.
• Expect overhead. Retries, tool calls, and regenerations consume tokens too.
• Re-check official rates. The 1.3x rule is stable; the underlying rates are not.
• Keep a small buffer. A balance that ends a run mid-answer wastes the input tokens already paid for.

Where this estimate is useful

Before a long drafting session, a batch of summarization calls, or an agent loop with many tool calls, a two-minute token estimate tells you whether the run fits your balance. If it does not, shorten the prompt, cap output length, or pick a cheaper model for exploratory turns and the stronger one for the final pass — all with the same key and the same 1.3x pricing rule.