labqoat-python

Typed SDK and CLI for the Labqoat starter API. Distribution labqoat, import labqoat, commands lab and labqoat.

Quick start

from labqoat.client import Client

with Client("http://127.0.0.1:4000", "local", "your-password") as client:
    note = client.create_note("First", body="Hello")
    page = client.list_notes(limit=20)
    for item in client.iter_notes():
        print(item.id, item.title)

The CLI defaults to production at https://app.labqoat.com, which uses a publicly trusted certificate. Profiles saved with the old tunnel URL (https://127.0.0.1:4043) should be updated, and SSL_CERT_FILE no longer needs to point at the private installation CA. Log in:

lab auth login --username labqoat
lab status
lab run list

Work is grouped into projects: a named container that owns runs, datasets, dashboards and one research memory. Start in a working directory with:

lab project init my-benchmark
lab project current

init creates the project and pins it as [tool.labqoat] project = "my-benchmark" in ./pyproject.toml, so every command run from there acts on it. --project NAME and LABQOAT_PROJECT override the pin; without any of them the project named default is used. run list, dataset list and dashboard list show the selected project and take --all-projects; lab project move --to NAME --run ID (also --app, --dashboard, --dataset) reorganizes existing work. The SDK stays explicit: Client(..., project="my-benchmark") selects the project, and labqoat.projects.project_selection.ProjectSelection.resolve().name applies the CLI's lookup order in a script.

Use an explicit override for a local instance:

lab --base-url http://127.0.0.1:4000 status

Saved profiles retain their configured endpoints; --base-url overrides the selected profile. Credentials remain scoped to that endpoint. The SDK takes an explicit URL, as in the local example above.

Credentials use HTTP Basic on every request. Plain HTTP is accepted only for explicit loopback destinations.

Every submit command (run, train, eval, and import) accepts --watch to print the submission response and then stream durable run events, just like the corresponding watch command. Evaluations watch their primary run. Without the flag, submission returns immediately.

lab run submit my_package:RUN --watch
lab train submit my_training_job --epochs 10 --watch
lab eval submit my_evaluation --dataset team/data@v1 --model team/model@v1 --watch

Production GPU workloads can select hardware and a minimum per-device memory:

from labqoat.authoring.resources import Resources

resources = Resources(
    cpu_millicores=4000,
    memory_mb=16384,
    gpu_count=1,
    gpu_model="l40s",
    gpu_memory_mb=44 * 1024,
)

Use this resource declaration in the workload's runtime configuration. The legacy GpuResources(cpu=4, memory_gib=16, gpu_count=1, gpu_model="l40s", minimum_gpu_memory_gib=44) form expresses the same requirements. Omit the model or use "any" to choose any GPU meeting the memory floor. Production enforces both constraints for workers and model serving, including scale-from-zero. Memory means MiB per GPU, not combined VRAM or fractional GPU allocation. EC2 reports 22,888 MiB for L4/A10G, 45,776 MiB for L40S, and 81,920 MiB for H100; marketed 24/48 GB sizes should not be used as 24/48 GiB floors. The default production pool offers T4, A10G, L4, L40S and H100; configured pool limits still apply. Unsupported hardware combinations fail capacity admission.

Training submits from source. lab train submit packages the exact working tree, uploads it once, and accepts a run without importing, installing, or executing the workload on the submitting machine; only the CLI and the source files are required. The platform then prepares the run — building the image, compiling the workload contract inside it, resolving dependencies, and freezing the execution manifest — before scheduling training. Preparation stages are visible on the run as preparing status detail, and --watch follows preparation through training. Heavy third-party imports in workload modules are supported because inspection runs inside the built image.

Every logs command accepts --follow to keep printing new log entries. Run, training, evaluation, and import logs use the existing run log stream and stop when the run finishes. Inference, replica, worker, node, and pool logs use one server-sent event (SSE) connection until the server closes it or you press Ctrl-C. Existing time filters, sort order, limit, and starting cursor are sent with the initial streaming request. Following does not poll snapshots. Each log.entry event prints its unchanged JSON data as one line, flushed immediately for pipes; heartbeats are ignored and log.error events report a CLI error. Ctrl-C closes the connection. Without --follow, logs return the same single JSON page as before.

lab run logs RUN_ID --follow
lab train logs RUN_ID --follow
lab eval logs EVALUATION_ID --follow
lab inference logs DEPLOYMENT_ID --follow
lab inference replica logs REPLICA_ID --follow
lab worker logs WORKER_ID --follow

lab node logs NODE_ID reads /api/v1/nodes/item/logs?ref=NODE_ID once. The server returns logs from active and retained workloads on that node, including completed workers and serving replicas. Entries include node and source metadata and pass through the usual SDK response validation.

With --follow, the CLI reads /api/v1/nodes/item/logs/stream?ref=NODE_ID over one SSE connection and prints raw entry JSONL. The server discovers new workloads and supplies their log entries.

lab node list
lab node logs NODE_ID
lab node logs NODE_ID --follow

lab pool logs POOL_REF reads /api/v1/pools/item/logs?ref=POOL_REF once, with the same semantics as node logs across active and retained workloads in the pool. Entries preserve pool, node, and source attribution through SDK response validation. With --follow, the CLI uses one /api/v1/pools/item/logs/stream?ref=POOL_REF SSE connection and prints raw entry JSONL as the server discovers workloads and supplies their logs. Node and pool logs accept only their required reference and --follow; they do not accept cursor, limit, sort, or timestamp filters.

lab pool list
lab pool logs POOL_REF
lab pool logs POOL_REF --follow

Inference and evaluation

Inference uses ordinary @app.cls() declarations bound to immutable Artifacts. Submit Predictor(weights=weights).predict through client.runs or context.runs; each Run captures its code, image and constructor inputs. See weight-backed inference.

Evaluation functions submit ordinary inference and scoring Runs, retain typed prediction datasets, and return EvaluationReport.complete(...). The report validates exact expected membership, explicit Run attribution, consistent finite metric names and equal-weight means. It is an ordinary typed result with no separate publication or completion lifecycle. Rescoring explicitly passes a previous result and its retained predictions into another function. See NAM and Jev decision training.

Development

Use lab --version, labqoat --version, or bun run cli -- --version to identify the executing installation. Editable installs and direct source execution report the package version, current Git revision, and absolute Python package path, for example:

labqoat 0.1.0+local.g0123456789ab (/path/to/labqoat/packages/labqoat-python)

Tracked changes inside that package add .dirty after the revision. If Git is unavailable or the source has no commit, the revision is unknown and the source path is still shown. Standard wheel installs report only their package version, such as labqoat 0.1.0. Version output works offline without loading profiles or credentials and does not depend on the current directory.

uv sync --locked — reproducible environment (Python 3.13 development; 3.11 minimum supported).
uv run --locked pytest tests -q --testmon — affected class-based unit tests.
ruff format / ruff check / strict mypy — same gates for source, tests, support, and generated code.
src/labqoat/_generated/ is owned by the schema emitter; never hand-edit.

Metadata

Release files for labqoat 0.2.100

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for labqoat 0.2.100
File	Size	Uploaded	Provenance
labqoat-0.2.100.tar.gz	1.2 MB	Oct 20, 2026	Without provenance	Details

Built distribution (wheel)

Table of built distributions (wheels) for labqoat 0.2.100
File	Interpreter	ABI	Platform	Reset
labqoat-0.2.100-py3-none-any.whl 1.3 MB Oct 20, 2026 Without provenance	Python 3	none	any	Details

Total release size: 2.6 MB

Release files / labqoat-0.2.100.tar.gz

Download URL	labqoat-0.2.100.tar.gz
Size	1.2 MB
Tags	Source
SHA-256 checksum How to use checksums	`08051d0a8d1d20e6be83743bbb586b0b477f8f0ccdba199cf43cd02398ebd962`
BLAKE2b-256 checksum How to use checksums	`57bf79b681542799db18831fef06fac30575801675858e3c2f94348f8feea3ff`
Upload date	Oct 20, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	No
Uploaded via	`uv/0.9.2`

Release files / labqoat-0.2.100-py3-none-any.whl

Download URL	labqoat-0.2.100-py3-none-any.whl
Size	1.3 MB
Tags	Python 3
SHA-256 checksum How to use checksums	`417f625473e5c578c2aef80278430d0e3ed5c20cf0d41f7f9acb65043817123f`
BLAKE2b-256 checksum How to use checksums	`716c0251541b962beec76c75bb13d5cc454ee2fbf4f1ab59f3d60750057d9c13`
Upload date	Oct 20, 2026
Uploaded using Trusted Publishing? What is trusted publishing?	No
Uploaded via	`uv/0.9.2`

Security for labqoat 0.2.100

Report project as malware

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.