Synthetic.new offers a $30 monthly subscription pack alongside usage-based API billing. A pack gives access within several capacity limits; it is not an unlimited API account. The useful comparison is between your burst workload, weekly demand and need for concurrent requests.
We checked the official pricing and rate-limit pages on 5 October 2026. The comparison below separates capacity limits from token-billed costs so you can choose the route that fits your workload.
Synthetic.new subscription pack pricing
| Item | Publicly documented value for one pack |
|---|---|
| Subscription | $30/month |
| Five-hour capacity | 500 request units |
| Weekly capacity budget | $24 of credit value |
| Concurrency | One concurrent request per model per pack |
Synthetic.new official pricing · checked 5 October 2026.
Synthetic.new official rate limits · checked 5 October 2026.
The pricing page distinguishes subscription access from pay-per-token usage. Before subscribing, identify which mode you intend to use and whether the selected model is included. A compatible API format does not by itself establish the applicable billing mode.
Define the workload before choosing a pack
Start with the job you want the API to complete. An interactive assistant, a background batch and an application serving several users create different pressure on the same subscription. For an interactive assistant, waiting for a queued request may be disruptive. A batch running overnight may tolerate that queue without needing more concurrent capacity.
List the required model, acceptable response delay, maximum simultaneous requests and the number of jobs in a busy week. Then identify which calls are optional: repeated planning, unnecessary context rereads and retries that do not change the approach can all inflate demand. This is workload design advice, not a performance finding about Synthetic.new.
Our existing Synthetic.new invite guide explains the site’s saved referral route. A referral benefit should be considered after choosing an appropriate billing mode. It does not resolve an unsuitable concurrency limit or establish that every model is covered by a subscription.
Request units are not simply a count of calls
The rate-limit documentation weights request units by model. It uses Kimi K3 as a baseline and describes cheaper models consuming a fraction of a unit. The 500-unit figure therefore should not be restated as a guaranteed 500 identical calls for every model.
Two workloads with the same request count can have different capacity needs. Long outputs, expensive models and repeated attempts change the budget. Track the complete job you need to finish rather than only the first successful API response.
How weekly limits and concurrency affect a project
The weekly credit-value budget is another limit alongside the five-hour request budget. The documentation describes gradual replenishment: 5% of request capacity every fifteen minutes and 2% of weekly capacity every 202 minutes. A remaining allowance in one dimension does not remove a limit in another.
Concurrency is described per model per pack. With one pack, a second request to the same model can wait while a request to a different model has a separate concurrency lane. If several workers target one model, check the queueing and pack requirements before assuming all workers can run at once.
For example, an imagined service with four simultaneous requests to one model has a concurrency requirement that one pack’s stated allowance does not cover. That does not automatically prove that four packs are the right purchase: first check the subscription screen, application architecture and whether queued responses are acceptable.
How to estimate usage-based API costs
For a token-priced model, estimate input and output separately: input tokens ÷ 1,000,000 × input rate, plus output tokens ÷ 1,000,000 × output rate. Apply any distinct cache rate only when the provider actually recognises those tokens as cached.
As a purely hypothetical example, rates of $0.50 per million input tokens and $2 per million output tokens would make 100,000 input and 20,000 output tokens cost $0.09: $0.05 plus $0.04. These assumed rates are not a Synthetic.new price quote.
Multiply by the real number of jobs, then add retries and any extra calls your agent makes. One user request can trigger many model calls. For a production workload, record both typical usage and a busy period; a monthly average can conceal a rate-limit problem at the busiest hour.
A break-even calculation without assumed provider prices
Using the hypothetical $0.09 job above, a $30 subscription equals about 333 such jobs in direct token charges: $30 ÷ $0.09. At one hundred jobs, the assumed usage cost would be $9; at one thousand, $90. This is only a comparison of stated assumptions. It cannot prove a Synthetic.new pack is cheaper because the actual model rates, included access and capacity constraints still need to match.
The comparison becomes more useful when you substitute your own totals. Record input, output and recognised cached tokens for each completed job, including failed attempts. Compute the usage-billed total, then check whether the same weekly and burst demand fits the subscription’s documented limits. A financially attractive pack that cannot serve the busy period is not an equivalent option.
Keep purchased API credit, the subscription’s weekly credit-value budget and referral credit in separate rows. The $24 weekly budget is a capacity accounting figure, not $24 of freely transferable money or a discount to subtract from the $30 invoice. Combining those units can make the subscription appear cheaper than it is.
How queued work changes the decision
Suppose a background job submits ten requests to one model. Sending them in sequence creates a different concurrency requirement from launching ten at once. If your task can wait, controlling the queue may be a better first step than buying enough packs for the largest burst. If the task cannot wait, confirm the account’s actual concurrency entitlement before calculating a pack total.
Retries also need a limit. A temporary failure should not trigger an unbounded loop that repeatedly spends capacity. Set a maximum attempt count and preserve the error record so you can distinguish a provider limit from an application mistake. Those are general implementation practices; no new reliability test is claimed here.
Subscription or usage billing?
A subscription pack is a route to compare for recurring work that fits its capacity and supported-model rules. Usage billing deserves comparison for irregular work or requirements that do not fit the pack. Neither route is automatically cheaper: the answer depends on usage you can describe and observe.
Keep the planning questions in order: required model, eligible billing mode, concurrent workload, burst capacity, weekly capacity and total spend. This prevents an attractive monthly price from hiding a throughput limit that matters to your project.
Is there an existing Synthetic.new invite?
Our existing Synthetic.new invite guide preserves the site’s current referral. Benefit eligibility needs checking separately from subscription pricing. For a different coding-only subscription route, see the GLM invite guide; other provider coverage is in AI inference providers.
Check compatibility beyond the endpoint format
Before moving an existing client, confirm support for its required streaming behaviour, tool calls, context length and selected model identifier. An OpenAI-compatible or Anthropic-compatible interface can simplify configuration, but it does not prove that every client feature behaves identically. Check the official setup instructions for that client rather than assuming a base-URL change is the whole migration.
Evidence: This article uses official pricing and rate-limit information checked on 5 October 2026. No completed Synthetic.new latency, reliability or coding-quality test was found in the existing records. Calculations are labelled, and our testing approach explains what a later hands-on evaluation would establish.
Check Synthetic.new plans. Confirm the billing period, final amount and renewal terms before paying.
