Genomic Intelligence

    Returns a handle ({ref, name, length, preview, ...}). Pass the
    `ref` to predict_* tools — the bases stay server-side. For
    expression, use fetch_gene_for_expression instead (it prepares
    the TSS-centred window that model needs).
    

    Resolves the gene's TSS via Ensembl and returns the exact
    TSS-centred window the expression model needs, as a handle to
    pass to predict_expression(sequence_ref=...).
    

    For "find the genes in chr8:127,680,000-127,800,000"-style requests:
    resolves a coordinate range to reference sequence and returns a handle
    ({ref, name, length, ...}) to pass to find_genes / predict_* — the bases
    stay server-side. Plus strand by default, which is what the gene-finder
    expects. For a gene by name use fetch_ensembl_sequence; for expression
    use fetch_gene_for_expression.
    

    Gene-finding: detects transcript boundaries (TSS + PolyA) and returns
    one interval per predicted transcript — start/end, strand, a
    confidence score, and predicted TSS/PolyA positions (BED-style feature
    intervals, not free-text notes). Use this for "what genes are here",
    "find / locate genes", or "annotate this region".

    Each transcript also carries its type (mRNA/lnc_RNA) and internal
    exon/intron/CDS structure in `exons`/`introns`/`cds` arrays, plus a
    browser-ready GFF3 track in `data.formats.gff3`. To get each gene's
    *expression* from a raw region, use find_genes_and_predict_expression
    instead — expression needs a per-gene TSS window, so predict_expression
    cannot run on a whole region.

    Submits an async job internally. With wait=True (default), blocks and
    streams progress, then returns the result {data, meta} — it never
    returns a job_id on this path. (If a generous block ceiling is
    exceeded it returns a timeout error, not a job handle.) With
    wait=False (detached), returns {data: {job_id, status: 'submitted'}}
    immediately — poll it with get_job.
    

    Server-side chaining in ONE call: finds genes (transcript intervals,
    with their TSS) in the sequence, then predicts expression off each
    discovered TSS in the given experimental context. This is the right
    tool whenever you want expression for a raw region or sequence — e.g.
    "find the genes in chr8:… and predict their expression in K562". You
    cannot call predict_expression on a whole region, because it needs a
    single per-gene 9,198 bp TSS window; this tool handles that for you.

    Runs async internally at every size (the annotate stage is slow even
    for small inputs), so progress always streams. With wait=True
    (default), blocks and streams progress, then returns the result
    {data, meta} — it never returns a job_id on this path. With wait=False
    (detached), returns {data: {job_id, status: 'submitted'}} immediately —
    poll it with get_job. Because it ends in expression, `description`
    (cell type / assay context) is REQUIRED.
    

    Use to discover model ids before passing one as the `model`
    argument to a predict tool. The same catalog is also available
    as the resource `gi://models`.
    

    The server ships one curated, task-correct positive control per task
    (list them via the gi://sequences resource) — e.g.
    `expression_hbb_k562` is a ready-to-use K562 expression window for
    predict_expression. Stores the demo and returns a handle to pass to a
    predict_* tool: no Ensembl fetch, no quota. Handy for smoke-testing a
    prediction end-to-end.
    

    Expression is cell-type-specific, so `description` (cell type /
    assay context, e.g. 'K562 cell line') is REQUIRED — the API
    rejects requests without it. Requires exactly 9,198 bp centred on
    the TSS; call fetch_gene_for_expression(gene) to get a
    correctly-prepared handle. For a raw region or whole gene where
    you don't already have that window, use
    find_genes_and_predict_expression (it finds the genes for you).
    

    Returns the {data, meta} envelope: data.regions lists predicted
    promoters with start/end/score.
    

    For a sequence you've already pasted into the conversation, this
    gives back a short handle so you can run several tasks on it
    without re-pasting the bases in each predict_* call. Note that the
    full sequence still passes through the LLM on THIS call — it does
    not save context on its own. For large sequences, prefer
    fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta,
    which acquire the bases server-side and never round-trip them.