Fallback Chains
fal introduced Fallback Chains, allowing requests to configure a primary model and up to two fallback models that trigger automatically on specified errors.
fal introduced Fallback Chains, allowing requests to configure a primary model and up to two fallback models that trigger automatically on specified errors.
fal now limits how often you can list, inspect, shell into, stop, and kill apps and runners. The limits apply to the CLI, the Python SDK, and the REST API. When you exceed a limit, the REST API returns 429 Too Many Requests , and the CLI and SDK return the gRPC status RESOURCE_EXHAUSTED . Learn more about the limits
Keys now use permission presets instead of the ADMIN and API scopes. When you create a key, select one of seven presets: API , SERVERLESS , DEPLOY , COMPUTE , BILLING , READONLY , or FULL . If no preset matches your case, select the exact permissions the key needs. You can also limit a key to specific models and set it to expire.
Shared WebSocket endpoints can now declare billing on their 101 upgrade response. Set x-fal-billable-units when the unit count is known at connect time. Set x-fal-billable-units-webhook to 1 when the count is only known at the end of the session. Then report the total with POST /requests/billable-units/{request_id} .
Deployed Serverless apps now include Testing > Playground in the app dashboard. Select an available endpoint, fill in its generated input form, and run a request without leaving the app. Multi-endpoint apps have one place to test their endpoints, using the existing Playground authentication and billing behavior. Open the guide
fal's second MCP server , the Platform API MCP , is now available at https://api.fal.ai/v1/mcp/platform . Where the Run MCP lets your AI assistant build with models , this one lets it operate your fal account : connect Claude Code, Cursor, or any MCP-compatible client with your API key and ask "why did my last request to my-app fail?" , your assistant walks...
Runner telemetry now includes a dedicated GPU Utilization chart alongside the existing CPU, memory, and VRAM charts, so you can see how much compute your GPUs are actually doing -- not just how much memory they hold.
You can now attach a freeform message and custom annotations to each revision when deploying: Messages and annotations are set at deploy time and stay with the revision. View and search them on the app's Versions page in the dashboard, or fetch them via the revisions API .
Apps can now register a default per-condition retry budget at deploy time with the new retry_config deployment option, using the same format as the X-Fal-Retry-Config request header. Set it as a class attribute on fal.App or under the app's table in pyproject.toml .
The new Serverless Usage page (Serverless → Usage) provides attributable, dimensioned reporting of serverless compute spend in the dashboard. Compute reported in machine-seconds , broken down per app, environment, and machine type. Spend is split by price category: Reserve, Burst, On-Demand, and List.
The Usage & Billing page has been rebuilt to support usage attribution (the Settings "Overview" tab is now "Usage"). Filter by auth method, API key, and login username to attribute consumption to a specific credential or user. Normalized app names and revised charts improve readability and export.
- New GET /v1/serverless/usage endpoint reports your own serverless compute usage , the machine-seconds each of your deployed apps consumed, priced with your machine rates and net of discounts Break usage down per app, environment, and machine type, with time_series and summary views over any date range and timeframe Filter by app name with app (exact, one...
The new Capacity page (Serverless → Capacity) reports GPU consumption against your account limit, providing visibility into available headroom before requests begin queuing. Account-wide GPU usage over time, plotted against your limit , with baseline and burst reference lines indicating utilization relative to reserved capacity.
The new X-Fal-Retry-Config request header replaces all-or-nothing retry behavior with a separate retry budget per failure condition, allowing retry policy to be tuned independently for each failure mode.
Managing a large number of serverless apps is now easier with new filtering and sorting controls directly on the apps page . Filter by machine type to instantly isolate apps running on specific hardware (e.g., H100, A100, L40) and monitor targeted resource allocation.
The GET /v1/models/analytics and GET /v1/serverless/analytics endpoints now support fourteen additional metrics via the expand parameter, matching the metric families the dashboard surfaces: Error type breakdown , startup_error_count , connection_error_count , timeout_error_count , runtime_error_count for finer-grained failure attribution beyond the...
| Release-notes page | Site | Feed |
|---|---|---|
| Product Changelog fal.ai | fal.ai | None |