If you are searching for the cheapest ChatGPT API, the first problem is that “price per million tokens” is rarely the complete price.
Different API services may count:
- input tokens;
- output tokens;
- cached input tokens;
- reasoning tokens;
- minimum request charges;
- failed or partially completed requests;
- streaming usage.
A service that looks cheap on a pricing table may become expensive for your actual workload. The right comparison is not the headline price. It is the final cost of a representative request.
What does “ChatGPT API” mean?
ChatGPT and the OpenAI API are related products, but they are not the same thing.
For developers, “ChatGPT API” usually means either:
- The official OpenAI API.
- An OpenAI-compatible API gateway that accepts the same SDKs and request formats.
This article focuses on the second category: APIs that support standard OpenAI-compatible clients such as the Responses API, Chat Completions and OpenAI SDKs.
You should always verify the current official contract and pricing:
An OpenAI-compatible endpoint is not automatically affiliated with OpenAI. Compatibility describes the request format, not ownership or model origin.
The real API cost formula
For a simple request, the effective cost can be represented as:
total_cost =
input_tokens × input_rate
+ cached_tokens × cached_rate
+ output_tokens × output_rate
+ reasoning_tokens × reasoning_rate
Then apply the minimum request charge:
total_cost = max(calculated_cost, minimum_request_charge)
Some services use separate input and output prices. Others use one blended price for all charged tokens.
Neither approach is automatically better. A split tariff can be cheaper for input-heavy workloads, while a blended prepaid price can be easier to understand for small applications.
Example: the same model can have different effective prices
Consider this illustrative workload:
900,000 input tokens
50,000 cached tokens
50,000 output tokens
Assume the official tariff is:
Input: $5.00 / 1M tokens
Cached input: $0.50 / 1M tokens
Output: $30.00 / 1M tokens
The estimated cost would be:
0.90 × $5.00 = $4.50
0.05 × $0.50 = $0.025
0.05 × $30.00 = $1.50
Total: $6.025
A blended provider might charge:
1,000,000 charged tokens × $6.00 / 1M = $6.00
For this workload, the two prices are almost identical.
For an output-heavy workload, the result could be very different. This is why any serious comparison should include workload assumptions.
Three common API pricing models
Direct official API
You pay the model provider directly.
Advantages:
- official documentation;
- direct account controls;
- detailed usage reporting;
- predictable model availability.
Possible disadvantages:
- separate billing for different models;
- multiple API keys;
- more complicated cost tracking;
- account verification requirements in some regions.
Multi-model aggregator
An aggregator provides access to models from several sources through one API.
Advantages:
- one integration;
- many model IDs;
- easy experimentation;
- optional routing features.
Before using one in production, check:
- whether commercial use is allowed;
- whether prompts are retained;
- how usage is calculated;
- whether requests are silently retried;
- whether the service changes models automatically;
- how model-specific errors are returned.
Prepaid compatibility gateway
A prepaid gateway lets you add funds to one wallet and use a compatible API endpoint.
Advantages:
- no monthly subscription;
- one API key;
- simple budget control;
- easy testing;
- one billing ledger for multiple models.
The important question is transparency. A prepaid service should show the model, charged tokens, request status, minimum charge and final settlement.
How Model.sale works
Model.sale is a prepaid API gateway for developers who want to test current AI models without creating a separate billing workflow for every experiment.
The basic flow is:
Create an account
↓
Create an API key
↓
Add prepaid balance
↓
Choose a model
↓
Send an API request
↓
Check usage and final charge
The API supports standard endpoints:
GET /v1/models
POST /v1/responses
POST /v1/chat/completions
Example request:
curl https://api.model.sale/v1/responses \
-H "Authorization: Bearer ms_live_your_key" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-luna",
"input": "Explain optimistic locking in one paragraph."
}'
Use your own API key and keep it in an environment variable:
export MODEL_SALE_API_KEY="ms_live_your_key"
Never put API keys in URLs, Git repositories, screenshots, client-side JavaScript, shell history, installer arguments or public issue trackers.
Python example
The standard OpenAI Python client can be configured with a compatible base URL:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MODEL_SALE_API_KEY"],
base_url="https://api.model.sale/v1",
)
response = client.responses.create(
model="gpt-5.6-luna",
input="Give me three practical PostgreSQL backup tips."
)
print(response.output_text)
Always check the live catalog before using a model because model availability and capabilities can change.
Why streaming performance matters
For coding agents and interactive applications, time to first token can be more important than total request time.
Measure:
- time to first byte;
- time to first token;
- total latency;
- stream completion rate;
- disconnect behavior;
- terminal usage;
- 429 frequency;
- 5xx frequency.
A cheaper API with unreliable streaming may cost more in engineering time than a slightly more expensive but stable endpoint.
Example streaming request:
curl https://api.model.sale/v1/chat/completions \
-H "Authorization: Bearer $MODEL_SALE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-luna",
"messages": [
{
"role": "user",
"content": "Write a small Go HTTP handler."
}
],
"stream": true
}'
Do not evaluate streaming only by checking whether the HTTP request returned status 200. The client should verify that data arrives quickly and that the stream ends with a valid terminal event.
API cost comparison checklist
Pricing
- Is pricing split between input and output?
- Are cached tokens discounted?
- Are reasoning tokens counted separately?
- Is there a minimum request charge?
- Does the provider round each request?
Reliability
- What is the recent success rate?
- What is the P95 time to first token?
- How often do streams fail?
- How frequently do 429 responses occur?
- Is model-level health visible?
Compatibility
- Does
/v1/modelsreturn the model ID? - Does the Responses API work?
- Does Chat Completions work?
- Are streaming events compatible with your SDK?
- Are errors returned consistently?
Billing
- Is balance reserved before a request?
- Is the final charge based on terminal usage?
- What happens when a client disconnects?
- Are failed requests charged?
- Can usage records be inspected?
Privacy and security
- Are prompts retained?
- Are responses logged?
- Are API keys displayed only once?
- Can individual keys be revoked?
- Are secrets excluded from analytics and logs?
The cheapest API is the cheapest successful workload
The best price is not always the lowest number shown in a table.
For a production decision, compare:
effective cost
+ reliability cost
+ integration cost
+ operational risk
For a prototype, a prepaid gateway can reduce financial exposure. You can add a small balance, run representative requests and inspect the actual charges before committing to a larger plan.
For production, validate the same model with your own prompts, token mix, concurrency and streaming requirements.
Final recommendation
Use this process:
- Choose two or three models for your workload.
- Define a fixed test set.
- Run short, input-heavy and output-heavy requests.
- Test JSON and streaming.
- Record actual usage and final charges.
- Measure latency and errors.
- Compare the results with the official pricing formula.
- Start with a small prepaid balance.
- Increase usage only after the numbers are consistent.
The phrase “lowest price” is meaningful only when billing units, model behavior and workload are comparable.
A transparent prepaid API should make that comparison easy: one key, clear limits, visible usage and no hidden model substitution.
Browse the Model.sale model catalog or read the pricing methodology.
Top comments (0)