Workflow
Run a batch
One design is a question. Fifty designs run the same way is an experiment. Batch mode queues an analysis across a whole set and returns results you can actually compare.
1,000
catalog constructs
65
organisms
1
manifest per batch
CSV
result export
01
The goal
Comparative questions need comparative runs. Which of the 65 hosts can support a Tier 3 target? Which of these forty enzyme homologs tolerate the substitution that worked in the first one? Does codon adaptation shift predicted expression the same way across a whole series? None of those are answerable one job at a time without the comparison quietly drifting as settings change between runs.
A batch pins the parameters once and applies them to every member of the set. What comes back varies because the inputs varied, not because the method did.
02
Stage by stage
Assemble the set
Build the input list from a catalog filter, a project's sequences, or an uploaded FASTA or CSV. The set is saved with the batch, so the question of exactly what was included never becomes archaeology.
Pin the parameters
Choose the engine and fix its settings once. Every job in the batch inherits them, and the batch record stores them alongside the engine version used.
Estimate before committing
For GPU engines the queue reports an expected credit cost for the whole batch before anything runs. A fifty-member variant scan is a different proposition from a fifty-member structure prediction, and you see that first.
Watch it resolve
Jobs run asynchronously with live status. Individual failures are isolated and reported rather than killing the batch, and a failed member can be retried on its own.
Collect the table
Results arrive as one table with a row per input and columns for the engine's outputs. Sort it, filter it, export it as CSV, or push the survivors straight into a new batch.
Keep the manifest
Every batch keeps a manifest naming the inputs, the parameters, the engine versions and the timestamps — the thing you need when someone asks six months later how the table was produced.
03
Worked example
- Batch
- Host feasibility sweep
- Input set
- 48 organisms from the catalog
- Engine
- Flux balance analysis (COBRApy)
- Fixed target
- Tier 2, 2,500 SHU, fruit tissue
- Engine class
- CPU — no credits
- Output
- Feasibility verdict, flux ceiling, bottleneck per host
- Export
- CSV plus per-host Escher maps
Forty-eight hosts, one target, one method. The table that came back sorted cleanly into three groups: hosts with comfortable headroom, hosts that could reach the target only with the amine branch substantially reinforced, and hosts where the budget simply was not there. That is a week of individual runs compressed into an afternoon, and more importantly it is a week of runs that are actually comparable.
The same shape of batch works for variant scanning across homologs, codon adaptation across a series, or off-target sweeps across a guide set — the engine changes, the structure does not.
04
What you get
A batch is a first-class object, not a loose collection of jobs. It keeps its inputs, its parameters, its results table and its manifest together, and it can be cloned with one input swapped when you want the obvious follow-up.
CPU batches are free however large they get. GPU batches draw on prepaid credits — $25 for 250 credits, one credit for roughly one Standard job — with Performance and Max classes for work that needs them. Enterprise workspaces can point batches at reserved GPU capacity so a large sweep does not wait behind the shared queue.
Ready to run it
Try this in the Splice Platform.
CPU engines are free to run. GPU engines run on prepaid credits.
Related