How the 1.3x Multiplier Interacts With Long Inputs: Estimating Extra USDC Before You Send a 100k-Token Prompt

What the multiplier actually applies to

On this platform, the price you pay is built from the model provider's official price multiplied by 1.3. That multiplier is applied per billed unit, so it scales with whatever the provider charges for.

For most chat and completion models, billing splits into two parts:

• Input (prompt) tokens — everything you send: system prompt, conversation history, retrieved context, the user question.
• Output (completion) tokens — what the model generates in response.

The key point for large prompts: the multiplier is not a one-time fee. It multiplies each component independently, so a 100k-token input multiplies a much larger input subtotal than a short prompt does.

Why long inputs feel the multiplier more

With short prompts, output tokens often dominate your bill, since output is usually priced higher per token than input. As the prompt grows toward six figures, the input subtotal grows roughly linearly with token count and can overtake the output subtotal.

So the "extra" USDC created by the 1.3x factor is proportional to whatever input volume you send. Doubling the context roughly doubles the input-side markup, assuming the same per-token price.

Two consequences:

• Resending a large context on every turn of a chat is the most common way people accumulate markup without noticing.
• Trimming or caching context reduces both the base cost and the multiplied extra, in proportion.

Get the official price inputs first

Before you can estimate the markup, you need the provider's official per-token prices for the exact model you plan to call. These are published by the model provider and can change.

Look up, for that model:

• Official input price per token (or per million tokens, then convert).
• Official output price per token.

Do not guess or reuse numbers from another model; input and output prices differ across models and tiers, which is exactly why a generic rule of thumb is unreliable.

The pre-send estimation formula

Work in consistent units (for example, price per token throughout). The structure is:

1. inputbase = inputtokens × officialinputprice
2. outputbase = expectedoutputtokens × officialoutput_price
3. basetotal = inputbase + output_base
4. markuponinput = input_base × 0.3
5. markuponoutput = output_base × 0.3
6. payableusdc ≈ basetotal × 1.3

Because both components carry the same 1.3 factor, you can also compute (inputbase + outputbase) × 1.3 in one step. Splitting it out is useful because it shows how much of the extra USDC comes from the long input versus the output.

If you want just the extra relative to official pricing:

• extrainputusdc = input_base × 0.3
• extraoutputusdc = output_base × 0.3

A 100k-token walkthrough (structure only)

You supply the numbers; the method stays the same.

1. Count or estimate input tokens. A 100k-token prompt might be a long document, a codebase slice, or accumulated chat history. Use a tokenizer for the target model where possible; otherwise treat your estimate as approximate and leave headroom.
2. Look up the official input and output prices for that exact model.
3. Plug into the formula above. Your input subtotal will be large because 100k tokens is large; the 0.3 extra on that subtotal is the markup attributable to the long context.
4. Add your expected output. If you expect a short answer, the output side may be small; if you expect a long generation, include it.
5. Convert to USDC. Both the base and the markup are settled in USDC when you pay through the platform, so the final figure is what you need in your balance.

Run the calculation once with your realistic output length and once with a generous upper bound, so you know the range before sending.

Practical habits that keep the extra small

• Send only the context you need. Every token you remove from a 100k prompt reduces both the base cost and the 0.3 extra proportionally.
• Avoid resending unchanged large context every turn when the API or your workflow lets you carry it more efficiently.
• Split giant jobs. A huge one-shot prompt and several smaller prompts are billed differently; estimate both shapes before choosing.
• Estimate before you send. A two-line calculation prevents surprises on prompts that are an order of magnitude larger than your usual calls.

Where contributor credit fits in

If you contribute keys and earn credit, the platform credits official price × 1.1 (or × 1.2 for premium) in USDC, while users pay × 1.3. That relationship is separate from how a long prompt is billed, but it is worth separating in your head:

• Payers see the ×1.3 multiplier on the official subtotal.
• Contributors receive ×1.1 or ×1.2 of the official subtotal as credit.

The estimation method above is for payers budgeting a large prompt. It does not change the multiplier or the credit rates; it only lets you predict the payable amount from the official prices you look up.

Checklist before sending a 100k-token prompt

• Model and official input/output prices confirmed.
• Input token count estimated with a tokenizer or conservative approximation.
• Output length bounded (realistic and upper bound).
• Formula applied, with input and output markup shown separately.
• Balance topped up in USDC to cover the estimated payable amount plus a buffer.