Skip to main content

What’s new

Updates that matter when you build

Follow model launches and product changes in one place. Published items are written by the team and tied to real catalogue availability.

Follow the models you use

Log in to mark models and see related announcements highlighted in your private console. This feed is in-product only; it does not claim email delivery.

Open followed models
  1. Product

    Leaderboards, hands-on reviews, a blind arena and a library of 176 tested prompts

    Four new places to decide which model to use, all built from runs on this platform. Leaderboards, reviews and the arena sit under Rankings in the site header; the prompt library sits under Studio.

    • Leaderboards score each model on two separate scales. The Spicy Index (0–100) is preliminary for now: it scores capability only, and output quality joins it once our quality tests and arena votes are in. The Freedom Score (0–100) measures how far each model verifiably goes on our content test ladder. The two never mix, and price, speed and reliability sit beside them as raw measurements. There are boards for video, image, LLM, uncensored, best value and speed; as of 26 September, 53 models are ranked from 1,672 test runs, and scores are recalculated daily.
    • Reviews: eight so far — MiniMax H3, MiniMax H3 Spicy, Seedance 2.5, Seedance 2.5 Spicy, Wan 3.0, Seedream 5.0 Pro, Z-Image Spicy and Grok 4.7. Each shows real outputs, a test report, what a usable result costs and a clear pick.
    • Blind arena: two anonymous image or video results from one prompt. Pick the one you would keep, then see which models made them. Signed-in votes set Bradley–Terry ratings with 95% intervals, refreshed hourly; models whose intervals overlap share a rank. Ranks appear once enough signed-in votes are in; until then the models are listed by maker.
    • Prompt library: 176 prompts for video and image models, each shown with the output it actually produced. Filter by model, task, scene or camera move, then copy the prompt or open it in the playground with every setting filled in.

    The methodology is public and versioned. We sell access to every model we rank, so the method page also explains how that is kept out of the scores.

  2. Product

    Failed runs retry on another route, refusals say what to change, and unseeded runs get a random seed

    Four changes to how tasks behave. Two may need a change on your side: if you rely on identical requests returning identical results, send a seed; if you branch on error codes, handle 40310.

    A failed run is tried again on another route first. Many models here are served on more than one route. Since 23 September, when a run fails after we accept it and another route serves the same model with the same settings, we run it there before reporting a failure, as long as the task has time left. You are charged once, for the result you get. Failures that would repeat anywhere, such as a copyright refusal, are not retried.

    Refusals explain the cause and the fix. When a model blocks a result over possible copyright or a real person's face, errorMessage now says which it was and what to try:

    • Video flagged for copyright is most often the generated soundtrack: set generate_audio: false, drop any reference audio, and leave real songs and artists out of the prompt.
    • Images flagged for copyright usually show a well-known character, logo or artwork, in the prompt or in a reference image.
    • Some models do not accept real people's faces in reference images. The message says so and suggests another model or an illustrated character.

    errorCode stays content_rejected, the charge is refunded, and the message follows your API error language like every other error.

    A random seed when you leave seed out. Since 24 September, on models that take a seed, a request without one is given a random seed, returned in the task's input. Two identical requests no longer return the same result. To keep runs comparable, send the returned seed back; a fixed seed does not guarantee an identical result. A few models vary the seed without returning it. A seed you send is always used as given.

    40310 for accounts whose email is not verified. Keys on such accounts used to get a generic 403. Since 25 September they get business code 40310, with a message saying to open the verification link or send a new one from the Console. The key starts working as soon as the address is verified.

  3. Product

    Official SDKs for TypeScript, Python, Go, Java and PHP

    Five official SDKs are live, alongside a CLI, an MCP server, an Agent Skill and a key-less proxy. All of them implement the same four steps: quote, create with an idempotency key, wait, collect.

    LanguagePackageInstall
    TypeScript@spicyapi/sdknpm install @spicyapi/sdk
    Pythonspicyapipip install spicyapi
    Gogithub.com/Spicy-API/spicy-gogo get github.com/Spicy-API/spicy-go
    Javaai.spicyapi:spicyapi-javaMaven Central, Java 17+
    PHPspicyapi/spicyapicomposer require spicyapi/spicyapi
    • Almost nothing enters your dependency tree. Python and Go use the standard library only, PHP needs no library either, and Java brings exactly one: Jackson.
    • The whole asynchronous flow, not just the HTTP call — a wait budget on task creation, the three-step upload for your own images and video, and webhook signature verification.
    • @spicyapi/cli browses the catalogue, quotes a price before you spend and downloads finished results from a terminal. @spicyapi/mcp gives Claude Code, Codex, Cursor or any MCP client the same abilities, asking you before anything is billed. The Agent Skill installs with npx skills add Spicy-API/spicy-skill and teaches a coding assistant the correct order of operations.
    • @spicyapi/proxy keeps the key on your server. A key compiled into a browser, mobile or desktop app is a public key; this package is the server-side hop that holds it instead.

    All five are MIT-licensed and open source. Guides for each: docs.spicyapi.ai

  4. Product

    Skip the polling loop: a wait budget on createTask, plus account-level webhook endpoints

    Two ways to stop writing polling loops. Both are live.

    A wait budget on task creation. Append ?wait=<seconds> to createTask and we hold the connection open until the task reaches a terminal state, answering with the full task record — the same shape recordInfo returns.

    • Budget runs out: you get the ordinary 202, identical to omitting it, and poll from there.
    • You disconnect: nothing changes for the task. It keeps running and bills as usual.
    • The ceiling is 60 seconds. Larger values are clamped rather than rejected, and a malformed value is ignored rather than rejected — a typo in an optimisation parameter should not fail a generation that would otherwise succeed.

    Use it on endpoints that finish in seconds, which is most image and edit work. Video models routinely run for minutes, so it will simply time out and you end up polling anyway.

    Account-level webhook endpoints. Register a URL once together with the events it wants, and every matching task is delivered to it — you never pass a callback URL on a task again. An account holds up to 16 endpoints, each with its own signing secret. A 410 Gone from your server disables that endpoint immediately rather than retrying an address whose owner has retired it. Endpoints are API-only for now; the console has no screen for them yet.

    Details: tasks · webhooks

  5. Product

    Every model now ships real example runs, with the exact input that produced them

    403 example runs now cover 117 of the 120 callable endpoints. Each one is a job actually run on this platform — not a concept image, not a still borrowed from a model card — and each carries three things:

    • The finished file, served from our own CDN at its original aspect ratio.
    • The complete input object that produced it — prompt, size, duration, every parameter — ready to copy straight into your own call.
    • A note in all ten interface languages explaining why that input was chosen: which aspect ratio the composition was written for, which parameter is doing the work, what to change first.

    They appear on each model page as a wall of results you can scan, and come back from the API on GET /console/v1/catalog/models/{slug} under examples.

    Choosing a model used to mean reading a parameter table and guessing what it would look like. Now you can see what an endpoint actually produces, and start from an input that is known to work on it.

    Browse the catalogue