anex.sh pricing details

Credits and estimates

You buy prepaid credits (1 credit = 1 US cent, USD) and jobs consume them. Each model has its own rates, and a smaller model costs you less.

A price depends on the mode, batch or realtime, and never on which API you call: api.anex.sh and the OpenAI-compatible oai.anex.sh bill the same work at the same price.

Estimates are free, and the credit amount shown at approval is a hard cap: an approved job never consumes more. Unused credits stay on your balance. Your job gets its own estimate based on current prices; the tables below are just representative examples.

Text output models

The next three tables are batch prices: jobs on api.anex.sh and batches on the OpenAI-compatible API. Realtime prices are in the realtime table.

An image costs the price per 1,000 images, or per 1,000 megapixels where it is marked MP (megapixel), its size capped at the largest the model reads.

Cached input is any part of a prompt the server has already processed in the same job - typically a shared instruction prefix repeated across rows. It bills at a quarter of the input rate, automatically: batch jobs with a common prompt prefix routinely see more than half their input tokens at the cached rate, which is why output tokens now carry more of the price than input tokens. There is nothing to configure and no way to lose money by it: a cache miss simply bills at the normal input rate.

Every input token bills at the input rate, the tokens an image or clip becomes included, and each image and each second of audio or video adds its fee: per image on the two Gemma models, per megapixel (MP) on the others, and per second of the clip for audio and video. What each fee counts, with two worked examples, is under how media is billed below. A video's tokens grow with the frames sampled from it, so a higher video_fps costs more per second of clip; the fee per second stays the same. A job that is cancelled or stops part-way pays for the rows that ran.

A job is billed at the prices in force when it was approved, so a job approved before a price change settles at the prices it was quoted.

Embedding output models

An embedding job bills every input token at the input rate, the tokens an image or video becomes included, plus the image or video fee in the table. It has no output or cached-input charges. The two qwen3-vl-embedding models put text, images, and video (up to 4 images or 1 video per row) in one vector space, and every embedding model truncates to a narrower vector via the per-request dimensions parameter. See embedding jobs for the job shape.

Decision output models

A decision model answers typed questions about a text instead of writing a reply: one answer per question, with a probability per option, in a single pass. Its price is per input token, and it reads the text once per question, so a request's billed tokens are the text plus each question's own words, summed over the questions. There are no output tokens. The table is the batch rate; the realtime rate is in the realtime table. See decision jobs for the request shape and the question types.

Realtime prices

A realtime request is answered right away and billed on its own, from the same credit balance as batch jobs, at these prices. Its total is rounded to a millionth of a cent, and there is no minimum price.

The realtime price of the two 8B embedding models can change from day to day; the table shows today's price, which is never less than $0.033 per 1M input tokens.

Realtime chat, and realtime image and video embeddings, are on the OpenAI-compatible API. The realtime API on api.anex.sh embeds text queries, on all three embedding models, and laya answers on both.

How media is billed

A request or batch row with images, audio or video costs its tokens plus a media fee. It is billed the same way in batch and in realtime, on api.anex.sh and on the OpenAI-compatible oai.anex.sh.

• Every input token bills at the input rate, the tokens each image, audio clip and video becomes included: they are all in usage.prompt_tokens (the cached part bills at the cached rate). completion_tokens, reasoning included, bills at the output rate.
• Each image (or each megapixel of it, where the table says MP) and each second of audio or video adds the model's fee. The fee is not in usage: it is the fee per image, per megapixel or per second, times the quantity in the table below.

A clip's header length is checked against its content when the request or row runs. If the two are more than half a second or 2% apart, whichever is larger, the request or row fails with media_length_mismatch and is not billed. A file that cannot be read fails with media_unreadable, also unbilled, and a file whose header states no length is billed on the length of its content.

The rate tables show each fee per 1,000 images, per 1,000 megapixels or per hour, so the figures stay short; a fee is billed pro rata. Batch fees are in the batch tables and realtime fees in the realtime table. A realtime request's total, tokens and fee together, is rounded to a millionth of a cent. A batch job's total is rounded once, to whole credits (1 credit = 1 cent), and is never below the model's minimum job price.

Two worked examples. A 1,600 x 1,200 photo with a one-line question on nemotron-3-nano-omni-30b. usage came back with 1,929 prompt tokens and 27 completion tokens. The photo is 1,920,000 pixels, under the 3,145,728 cap, so it is 1.92 megapixels.

A 10-second video with a one-line question on gemma4-12b. usage came back with 769 prompt tokens, the video's frames included, and 16 completion tokens. The file's header states 10.000 seconds.

Minimum job price

Every job also has a minimum price: qwen3.8-27b $0.12, gemma4-31b $0.29, gemma4-12b $0.05, qwen3-14b $0.07, nemotron-3-nano-omni-30b $0.06, laya $0.05, and $0.02 for each embedding model. A job whose token price is below its model's minimum is billed the minimum; a job whose token price is above it pays its token price and nothing more. It applies to batch jobs on both APIs; a realtime request has no minimum.

Batch pricing rewards volume: once a job's token price clears the minimum, you pay the token price alone, so batching more rows into one larger job is the cheapest way to run them.

What jobs actually cost

Rows sharing a prompt prefix bill its repeat occurrences at the cached input rate, so cache-heavy jobs come in noticeably under these figures.