Pricing

AkashML has two billing modes, depending on the model. Both expose their pricing on the /v1/models response, so you never have to guess what a request will cost.

Token-based pricing (chat, completion, embeddings)

Most LLM-style models charge per token in + per token out, plus an optional flat per-request fee:

cost = input_tokens × input_price_per_token
     + output_tokens × output_price_per_token
     + request_price

You'll see these prices under pricing on /v1/models:

{
  "id": "meta-llama/Llama-3.3-70B-Instruct",
  "pricing": {
    "input":   "0.00000023",
    "output":  "0.00000040",
    "request": "0"
  }
}

That's it for token-priced models. The math is fixed; what varies is the number of tokens.

Dynamic pricing (per-request)

Some models aren't priced per token — tokens don't fit them. Instead, cost is computed dynamically from the request-level inputs that actually drive it, via a typed pricing config published on the model's /v1/models entry. One engine handles every modality; only the factors differ:

• Image generation / editing — priced by image size (megapixels) and number of images. Live today (FLUX.2 klein 4B, below).
• Text-to-speech — priced by characters of input text. (coming)
• Speech-to-text — priced by seconds of audio. (coming)

When a model has dynamic pricing, two extra fields appear alongside pricing:

{
  "id": "black-forest-labs/FLUX.2-klein-4B",
  "pricing": {
    "input":   "0",
    "output":  "0",
    "request": "0"
  },
  "pricing_config": { "..." },
  "example":        { "..." }
}

You get two views of the same formula — pick whichever is most convenient for your use case.

Reading the cost the easy way: example

The fastest answer to "what does a standard request cost?" is the example block:

"example": {
  "inputs":   { "size": "1024x1024", "n": 1 },
  "cost_usd": 0.01
}

This is computed by the same engine that actually bills your request, so it's accurate to the cent. Use it as a baseline; non-default inputs scale according to the rules in pricing_config.

Reading the raw rule: pricing_config

If you need to compute cost client-side (e.g. to show a real-time price estimate before submitting), pricing_config is the full machine-readable formula:

"pricing_config": {
  "parts": {
    "per_image": { "base": 0.01 }
  },
  "factors": [
    { "param": "size", "source": "request", "applies_to": "per_image",
      "op": "add",      "transform": "megapixels_over", "threshold": 1, "rate": 0.001, "max": 4 },
    { "param": "n",    "source": "request", "applies_to": "per_image",
      "op": "multiply", "transform": "linear",          "default": 1,   "max": 10 }
  ],
  "total": "per_image",
  "min_cost": 0.01
}

How the engine evaluates a config

1. Start with each named part initialised to its base. Most models have a single part called per_image.
2. Apply each factor in order:
   • Read the parameter from your request (or use its default if missing).
   • If the factor has a max, requests exceeding it are rejected.
   • Compute a number via the transform (see below).
   • For op: "add", add transformed × rate to the part it applies_to.
   • For op: "multiply", multiply the part by transformed.
3. Return the value of the part named in total.
4. If the config sets an optional min_cost, the final total is clamped up to that floor.

All math is done with arbitrary-precision Decimal — no float drift, no surprise rounding.

Transforms

Sources

The source field on a factor tells the engine where to read the parameter from. Today, all image factors read from request (your request body). Other modes are response and usage (values reported by the backend post-completion — used by audio / video / streaming models) and derived (values the gateway computes before pricing) — same engine, just a different bag.

Worked example — Flux Klein

One megapixel is 1024×1024 px (so 2048×2048 = exactly 4 MP). Using the config above — a $0.01 minimum (covers images up to 1 megapixel), plus $0.001 per megapixel above 1 MP, capped at 4 MP, times n:

cost = (0.01 + max(0, megapixels − 1) × $0.001) × n

Try it yourself — the calculator reads each model's published pricing_config, so it adapts to whichever dynamically-priced model you select (image today, audio as it ships):

Limits and safety caps

Each factor can carry a max to cap user-controllable parameters. For Flux Klein, size is capped at 4 megapixels and n is capped at 10. Requests above these caps return:

{ "error": { "message": "Pricing param \"size\" exceeds max (6.25 > 4)" } }

These caps protect both you (from surprise bills) and us (from runaway compute). They're advertised in pricing_config so you can validate client-side before sending.

A config may also set a min_cost floor, which guarantees a minimum charge per request regardless of inputs. When present it's applied last, after all factors.

Cost transparency on each request

Every billed request writes a usage_records row with both the final cost and a billing_context JSON snapshot of the inputs that produced it (size, num_inference_steps, n, pixels, etc.). If you ever need to reconcile or dispute a charge, that row alone has everything needed to re-derive the math.

Quick reference