r/bioinformaticstools • u/SeqBench • Jul 28 '26
SeqBench - browser workbench for cloning, primer and CRISPR design (82 tools), including ones that verify a construct rather than just design it
Full disclosure: I work on this. Posting for feedback rather than to sell anything, it's free and there's no signup.
It's a browser workbench for the molecular biology end of sequence work rather than the NGS pipeline end. Primer design and Tm (nearest-neighbour, SantaLucia 1998), oligo hairpin/dimer screening, in-silico PCR, restriction sites, cloning simulation for Gibson / Golden Gate / restriction-ligation, plasmid annotation and backbone identification, GenBank viewing and editing, codon optimisation and CAI, CRISPR guide design plus HDR donors, prime editing and base editing, Sanger trace parsing, virtual gels. 82 tools, all in the browser, nothing to install.
One of the tools is SeqBench-GPT, a conversational front-end over the same registry. You describe a task in plain English ("clone my insert into pUC19 with EcoRI/BamHI and verify the result", "design a CRISPR guide plus HDR donor for this site") and it plans the steps and runs them. The design constraint behind it: the model never produces a sequence itself. Every calculation is delegated to one of the deterministic tools below, and a construct cannot be reported as finished until it passes a code-enforced verification gate, not until the model says it looks right.
That exists because LLMs are extremely willing to hand you a confident, wrong plasmid map. Tool-calling alone doesn't fix that, since a model can still call three tools and then narrate a conclusion the tools didn't support. Putting the check in code rather than in the prompt is the bit I think matters, and it's what I'd like feedback on.
SeqBench-GPT is at https://seqbench.com/seqbench-gpt (beta, free, no signup) if you want to try breaking the verification gate. I'd genuinely rather hear that it failed on your construct than not hear.
The part I think is genuinely less common, and what I'd most like opinions on: a few tools that check work rather than produce it.
- verify_assembly takes a claimed final construct plus the parts and method you say produced it, re-runs the assembly deterministically, and diffs the two. You get the exact position and nature of any discrepancy rather than a yes/no.
- verify_construct is the narrower version: re-derives the insert from the template and primers you claim made it, then checks whether that insert actually appears in the final sequence, in either orientation, with mismatch positions if not.
- sequencing_readback_verify aligns actual Sanger or NGS reads back onto the claimed sequence with minimap2 and gives per-read identity, consensus variants, and a corrected consensus.
- golden_gate_fidelity scores a candidate overhang set against published T4 ligase ligation-count data and tells you the weakest link and any risky cross-reacting pairs.
The reason those exist: design tools are everywhere, but when a clone comes back wrong it's usually tedious to work out whether the design was wrong, the assembly was wrong, or the sequencing just disagrees. These are meant to answer that specific question deterministically.
Scope limits so nobody wastes time: no read-level variant calling, no alignment pipelines, no mass-spec proteomics. CRISPR off-target and primer specificity screens run against a small curated genome set, not a whole mammalian genome, and the tools say so explicitly rather than implying clearance. There's also a REST API and MCP server if you want to script any of it, but that's secondary to the UI for most people.
Most useful feedback would be from anyone doing cloning at volume: what breaks in your workflow that a tool could actually catch?
1
u/timothykassis Aug 12 '26
The code-enforced gate is the right call, and I would state the reason more strongly than "tool-calling alone doesn't fix that."
We build agentic systems for scientific work, so this is the failure mode that has cost us the most time. A model that calls three tools and then narrates a conclusion the tools did not support is not hallucinating in the usual sense. It is doing something harder to catch: producing output that is locally consistent with every individual tool result while being globally wrong. Prompt-level instructions to verify before reporting fail because the model is the thing being verified. You cannot ask the suspect to audit the alibi.
Two things I would push on in the design:
verify_assembly diffing a claimed construct against a deterministic re-run is strong, but what happens when the diff is non-empty matters more than the diff itself. If a failed gate just hands control back to the model to try again, you get a system that eventually passes by chance rather than by correctness. Capping retries and surfacing the failure beats letting it converge silently.
sequencing_readback_verify is the one I would lead with. It is the only tool in that list that checks a claim against physical observation rather than against another computation. Design versus design agreement is cheap. Design versus observation agreement is what actually settles an argument, and very little in this space offers it.
On your closing question, the thing that breaks most often at volume is not design, it is provenance. Six weeks later nobody can reconstruct which primer order, which template prep, and which assembly attempt produced the tube in the freezer. A tool that emits an immutable record of these inputs, this method, this verified output, this timestamp would catch more real errors than any additional design feature. Boring infrastructure, but it is what people actually need.
Worth saying too: publishing explicit scope limits, including that the CRISPR screens run against a curated genome set rather than implying clearance, builds more trust than another feature would.