Production-grade orchestration is a moving target. Releases, fixes, and policy changes ship from the docs and surface here automatically.
Traverse execution history with cursor pagination
API
Traverse execution history with cursor pagination
GET /v2/executions lists organization-wide execution history in descending creation order with the same filters as V1, a default limit of 20, and a maximum limit of 100. Authenticate with your API key as a Bearer token.
Follow the opaque next_cursor only while has_more is true. Keep the same filters and limit for each page; restart without a cursor to change them.
GET /v1/executions is deprecated but remains available for shallow compatibility. Requests beyond the 1,000-row prefix (offset <= 1000 - appliedLimit) return {"error":"V1 execution pagination is limited to 1000 rows; use GET /v2/executions with cursor pagination"}.
The dashboard now has Activity → Alerts for organization-wide spending alerts.
Create threshold rules for rolling charged spend, enable or disable them, and review the 20 most recent triggers from the same page.
Alert emails are sent to the organization owner and billing managers, with the charged spend, threshold, rolling window, and evaluation time included for reconciliation.
Replay re-runs a sample of successful past executions on a compatible test model, so you can compare outputs and cost on your real inputs before switching.
Pick a time window and sample size, then confirm the suggested field mapping. The preview shows which runs are eligible, explains any skips, and gives you the original sample's baseline cost before you start.
Set a soft cost cap, pause or resume an active test, and inspect the original and replayed inputs and outputs side by side. The final totals show how the test model's actual cost compares with the original runs.
You can also keep the same model and change its mapped inputs to test a parameter variant without changing live traffic.
Direct-model fallback lets an async prediction recover when its primary model fails. Compatible fallback models are tried in the order you choose, and the first success completes the original request; when the primary succeeds, the backups do not run.
Open a model from AI Models and choose Fallbacks to create one or more named chains. Start from a curated recommendation when one is available, or pick compatible models yourself, reorder them, and confirm how the primary model's inputs map to each fallback.
Every chain has a stable request selector. Add "fallback_selector": "your-chain" to an async prediction request to use it. Only enabled, saved chains run, and changes apply to new requests.
GET /v1/models/{slug} and GET /v1/model?slug={slug} include a nullable cost field with a fixed estimate or concise usage-based guidance when a reliable public estimate is available.
Estimates may change with provider rates, promotions, or model configuration. Use metrics.cost on the completed prediction or workflow execution for the settled value.
GET /v1/billing/balance returns your authenticated organization's USD balance as a number, using the same Bearer API key as the rest of each::api.
The route has no organization selector and returns no wallet, credit, organization, or credential details.
Balance reads are eventually consistent after a top-up. Retry with bounded backoff under the process-local 3 requests-per-second, burst-3 limit; a limited request returns 429 with Retry-After: 1, and an unavailable balance returns 503 instead of a fabricated zero.
Build an HTTP step from a cURL command, and decide when it fails
each::workflows
Build an HTTP step from a cURL command, and decide when it fails
Paste a cURL command from a provider's docs into an HTTP request step and it fills itself in — method, URL, headers, query parameters, and body. An import now replaces the form rather than merging into it, so fields the command does not mention stop carrying values from the import before it.
Pick a field out of the response instead of guessing at it. An HTTP step offers its response body and its status_code wherever you choose a reference, so you can feed one field into the next step or branch on a 200 against a 429. The picker learns the shape of a response from the last run, from Send test request, or from a sample response you paste into the step's settings, and pins any media it finds to the top.
A Fail when rule decides what counts as a failure: connection errors only, any non-2xx response, or a list of status codes you name. A 503 from your endpoint no longer reads as a successful step.
An HTTP step can name a second request as its fallback, not just a model. When a response matches the failure rule, the backup request runs instead of the workflow carrying a bad response forward.
A failure raised by the rule names the status it saw and the rule that rejected it, instead of a generic service error.
The step timeout has a five-second floor, so a mistyped value cannot fail every request.
Both editors get all of it: the HTTP card on the canvas and the HTTP step in the step editor.
⌘C on the canvas now copies to your system clipboard, so a copy outlives the tab that made it. Paste those cards into a second tab, or into an entirely different workflow.
Cards pasted into a different workflow arrive with credential parameters stripped. Paste back into the workflow you copied from and they come through untouched.
Canvas Workflows builds a workflow as a graph you draw: drop model, input, HTTP request, choice, and output cards onto a canvas and wire them together, instead of filling in an ordered list of steps. Start one with Create Canvas on your workflow list, and find them under Canvas Workflows in the sidebar.
The wires are the workflow. Connecting two cards is what binds one step's output to the next step's input, so what you draw is what runs — there is no separate mapping screen to keep in sync.
A canvas workflow runs as a dependency graph, so independent branches run at the same time. Run the whole flow, a single card, a group, or everything from one card onward, and open the Playground without leaving the editor.
Canvas Workflows and My Workflows are one library split by editor: workflows you build on the canvas appear in the new list, the ones you already have keep the editor they have today, and both trigger through the same workflow API. The canvas needs a desktop browser; on a phone a workflow opens in the step editor.
It is an open beta, available to every account. Breaking changes may still land as we build. Tell us what you hit: support@eachlabs.ai.
My Workflows now has tags, so you can label your workflows and find your way around a large library.
Filter the list by tag from the toolbar, with a searchable set of checkboxes for narrowing down.
Every tag shows how many workflows carry it — an exact count up to 999, then 999+.
A workflow carries up to three tags. Once you reach the limit the picker shows which rows are locked and why, and the same limit applies over the API. Filtering by tag is not limited.
Tagging a workflow no longer reloads the list: the picker stays open, your scroll position holds, and the counts update on the click.
Partial runs follow the graph, and every output wire comes back
Canvas Workflows
Partial runs follow the graph, and every output wire comes back
Run from here now starts independent branches at the same time, instead of making unrelated work queue behind whatever is in front of it.
A workflow whose output is mapped from more than one step now opens with every one of those wires drawn. Saving after you reopen keeps the whole output mapping rather than trimming it down to a single key.
Deleting a selection undoes in one ⌘Z instead of several.
Run status badges announce each step's status to screen readers.
Twenty new flagship models are listed in the catalog and callable through the LLM Router — among them Kimi K3, Grok 4.6 and 4.5, the Qwen 3.8 family, Meta's Muse models, and ByteDance Seed 2.1 Turbo — bringing a current vision-capable model to nearly every family.
GET /v1/executions now returns execution history for every API key in the
organization that owns the authenticated key. A cost or usage pipeline no
longer needs one request per key, and a newly created key is included
automatically instead of silently dropping out of reporting.
Behavior change: this endpoint previously returned only the executions
created with the authenticated key. There is no way to ask for that narrower
result, so a caller that depended on it now receives its whole organization.
Scope never widens past your own organization. The query parameters and the
response shape are unchanged.
Running one card or a group no longer locks the rest of the editor: each run carries its own progress and its own cancel.
A group or partial run starts every card that is ready at the same time, so unrelated cards in the same run do not queue behind each other.
The Runs rail keeps your recent runs, lets you dismiss the ones you are done with, and stacks results down the panel so you can read them without scrolling sideways.