INFRO Studio: image, video and audio on your own providers

Text models have converged on one shape: tokens in, tokens out, priced per million. Image, video and audio models have not. Each vendor bills in its own unit, some answer in seconds and some in minutes, and many delete what they made within hours or days. A team that makes media with more than one model ends up maintaining a small translation layer in people's heads: what this render will cost, whether this model takes a last frame, where last week's take went.

This guide covers those differences first, because they apply whichever tools you use. The second half describes INFRO Studio, the creative workspace INFRO released on 12 October 2026, and how it handles each one on the provider accounts you already have.

Four billing units, not one

Look at one vendor's price page and you find at least three units. On Google's Gemini API, an image from Nano Banana 2.1 is priced per image by resolution tier, with 4K costing more than three times 1K; Veo 3.1 video is priced per second of output by resolution, from $0.05 a second for Lite at 720p to $0.60 a second for the standard model at 4K, with audio included; and Lyria music is priced per song¹. Google also notes that a Veo video is charged only if it is generated successfully¹.

Hosts add their own layer. Runway's API prices every generation in its own unit worth one cent: gen4.5 video comes to $0.12 a second, Veo 3.1 through Runway to $0.40 a second with audio and $0.20 without, an image from gen4_image to $0.05 or $0.08 depending on resolution, and speech from eleven_v4 is priced per thousand characters². Replicate bills its public models by the time the hardware spends actively processing your request, with setup and idle time free; private models and deployments bill for all the time an instance is online³.

Three consequences follow for anyone planning media work:

• The price of a request depends on its settings. Duration, resolution, audio and quality change the cost of a video more than the prompt does. An estimate has to read the settings, not only the model name.
• The same model costs different amounts on different providers. Veo 3.1 is a Google model, but it is billed one way on the Gemini API and another way through Runway¹². The provider, not the model, decides the invoice.
• Retries and takes multiply. Creative work makes several takes per shot. A per-second price that looks small for one clip becomes a real number across a storyboard.

Async jobs, polling and webhooks

An image usually comes back in the same HTTP request. Video does not. Google's Veo documentation describes the call as starting a long-running job that immediately returns an operation, which you poll until it is done, and gives generation latency as 11 seconds at minimum and up to 6 minutes during peak hours⁴. fal puts requests on a durable queue: the submit call returns a request_id and URLs for status, result and cancel; statuses move through IN_QUEUE, IN_PROGRESS and COMPLETED; and a fal_webhook URL makes fal post the result to your server instead⁵. fal may retry a webhook delivery, so it advises using the request_id for idempotency⁵. Replicate sends webhooks when a prediction is created, updated and finished⁶.

Polling or webhooks is the visible choice. The less visible problem is what happens after the job finishes:

Replicate deletes API inputs and outputs after an hour, which is one of the reasons it gives for using webhooks: to copy results to your own storage in time⁶. Veo videos stay on Google's server for two days⁴. Any pipeline that keeps a link instead of a file will eventually show a broken thumbnail in a review, and re-rendering is not the same as recovering: the provider bills the render again, and the new take is not the one that was approved.

The same model takes different settings on different providers

A model name does not tell you what a request may contain. Veo 3.1 on the Gemini API accepts up to three reference images, but not on Veo 3.1 Lite; it takes a lastFrame only together with a first image; and it extends Veo-made videos by 7 seconds at a time, up to 20 times, only for 720p input in 9:16 or 16:9, and not on Lite⁴. Hosts that serve the same model expose their own subset, with their own field names and their own limits.

When a setting does not fit, two things can happen, both bad: the provider refuses after a queue wait, or it quietly substitutes its default and bills a render nobody asked for. A creative tool that offers settings per model, not per provider, invites both. The fix is to keep a record of what each model takes on each provider and to check every request against it before any call.

Why media needs an estimate before every run

Text workloads are often budgeted after the fact: tokens are cheap per call, and a dashboard catches the drift. Media turns that around. A single storyboard run can mean dozens of video renders at a per-second rate, each with retries, and the cost is decided by settings a creator picks in a form. An estimate shown before the run, computed from the same settings the request will send, is the only point at which someone can still choose a shorter clip, a lower resolution or a faster model tier.

Three rules make an estimate trustworthy:

1. Use the rate that will be billed. A negotiated rate where the organization has one; the vendor's published list rate otherwise.
2. Read the settings. Seconds, resolution tier, quality, number of images, characters of script.
3. Say "unpriced" when no rate is known. An unpriced step shown as $0 is worse than no estimate, because it reads as free.

INFRO Studio: a workspace on your own provider connections

INFRO is a control plane that sits between an organization's applications and the AI providers it already pays. Studio, at studio.infro.io, is its workspace for image, video and audio work, and it is part of every INFRO plan with no add-on. It runs on the same organization, members, roles, provider connections, budgets and plan as the INFRO console. Every generation it makes is a gateway request on one of your organization's own provider connections, so the provider bills your account directly, under your contract. INFRO charges its subscription only, with 0% markup on model spend.

Inside Studio, the work is organized the way a production is:

• Projects and the Library. Uploaded and generated files, organized in projects, each item showing the date it is kept until.
• Create. Studio's home: the medium, the task (edit, animate an image, extend, upscale, lip-sync, voice, music and more), the model, then the provider that runs it, inputs dropped in or picked from the Library, the settings that model takes on that provider, and its estimate.
• Storyboard. Scenes and shots; each shot has versions, takes and a pick. Play sequence shows every shot in order before anything is exported.
• Cast. Characters, locations, styles, props and voices reused across shots and models, with the references each model takes chosen for it. A character built from photos of a real person needs its creator's attestation that they have that person's permission, and a run without it is refused.
• Director. Turns a written brief into a cast, shots and prompts, on a text model served by one of your own connections.
• Recipes and Flow. Multi-step recipes and Flow, a canvas of nodes and wires where you run a node, a branch or everything. A run that stops can be resumed, reusing the results it already made.
• Compare. Up to eight takes side by side: videos play and scrub together, two images get an A/B wipe, and every tile names its model, provider and cost.
• Review and Export. Comments at a moment in a video or on a region of an image, approve or request changes per shot, view-only share links that expire within 30 days, and an export package with timelines for Final Cut Pro, DaVinci Resolve and Premiere Pro.

Each shot moves through four stages, and each stage is a step on one of your providers:

What happens when you press Generate

Studio's choices come from GET /studio/v1/capabilities: only models a connected provider serves, and only the settings that model takes on that provider. Before a run starts, POST /studio/v1/runs with dry_run returns the plan: every step, the estimated provider cost of each, and how many steps are reused from identical earlier work. Studio shows it beside what is left of the member's own monthly limit and the organization's budget.

The run itself goes through the same /v1 implementations an application would call with a gateway key, so the model allowlists, guardrails, budgets, routing and failover the organization has configured apply to Studio too. Each request runs as the signed-in member, not as a key in the browser, and is recorded with feature set to studio, the run id as its trace and the Studio project as a tag. When a provider fails a step, the organization's default decides what happens per condition: retry, try the next provider, or stop; a creator can change that for one generation in the composer. The run queue shows every run in flight with its progress where the provider reports it, an ETA from the organization's own typical time for the model, and its estimated cost.

The estimate is the same one the gateway records afterwards. Your negotiated rate is used where you have entered one, otherwise the vendor's list rate; a step with no known rate is shown as unpriced, never as $0. Budgets and member limits are enforced on Studio's requests exactly as on any other request. Your provider's invoice remains authoritative.

Settings, references and the newer media tasks

Studio needed media capabilities the gateway did not have, and they are on /v1 for every application: reference images with roles on images and video, last_frame, negative_prompt, extend of an earlier job's video, video-to-video, image and video upscaling, lip-sync, sound effects and music. Each is checked against what the model takes on each of your providers before any call. A setting a target cannot take is never sent: the next target in the route is tried, and when none can take it the request is a 400 invalid_request_error naming what the model accepts. No provider is called and nothing is charged.

The records are per pair, which matters in practice. Wan 3.0 takes a last frame on fal but not on Replicate. Veo 3.1 takes up to three references on the Gemini API, fal and Replicate, matching Google's own limit on the Gemini API⁴. Sync's lip-sync models are served on a Sync connection, fal or Replicate. Music endpoints carry their own constraints, such as MiniMax singing only the lyrics it is given; INFRO's documentation also points out that music licences are the provider's own and can be narrower than "commercial use" on some plans, so read them before you publish.

The estimate is available to an application as well. POST /v1/estimates takes a model, optionally a provider, and the quantities (n, size or resolution and quality for images, duration_seconds for video, characters for speech, tokens for text) and answers with estimated_cost, price_source and the rate with its tiers, or null with an unpriced_reason:

curl https://api.infro.io/v1/estimates \
  -H "Authorization: Bearer $INFRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "google/veo-3.1", "duration_seconds": 8, "resolution": "1080p" }'

For long renders outside Studio, /v1/videos returns 202 with a job, which you poll at GET /v1/jobs/{id} or receive as a job.succeeded or job.failed webhook, signed when it goes to an endpoint configured for your account. Studio's own runs do not send webhooks; the run queue shows their progress.

Storage, consent and retention

Studio stores nothing until an owner or admin of the organization turns its storage on, and Studio cannot run without it, because every output is persisted the moment it exists. Who turned it on and when is recorded in the audit log. Studio storage is separate from the gateway's request payload logging: turning one on never turns on the other. Generated media is stored as the provider returned it, so provenance marks the provider adds, such as the SynthID watermark Google applies to Veo videos⁴, stay in the file.

How long work is kept is set by the plan: 30 days on Developer, Startup and Team, 90 days on Business, and a year on an Enterprise agreement. An organization can choose a shorter window. Every item shows the date it is kept until, the people who made items leaving within a week get one email listing them, deleted items stay in Trash for 7 days before they are purged, and turning storage off either deletes everything now or lets items expire on schedule. Downloads and exports work while an item is kept. Compare that with the vendor windows above: an hour on Replicate, two days for Veo on Google's server⁶⁴.

Who can do what

Owners, admins and developers make, upload and export in Studio. Analysts and finance members can open it to see work and its cost, comment and review, but not generate. A member confined to some projects in the console is refused, because Studio is organization-wide in this first version. Each member sees their own monthly limit and the organization's beside every large run, so a run that would stop at a limit says so before it starts.

When a model goes away

Media models retire quickly. OpenAI's deprecations page lists the Videos API, sora-2 and sora-2-pro as shut down on 24 September 2026, with no replacement listed⁷. Work that depends on a single vendor's model id inherits that schedule. A workspace that names the model, provider and settings of every take, keeps the files, and can run the same shot on another model from another of your providers turns a shutdown into a choice of model rather than a lost project. The deprecation playbook covers the general method; the video model comparison covers the options.