Apothic Client API Reference

Reference index for the Apothic Python SDK, including App, Function, Job, Image, storage, stateful resources, coordination primitives, and liv.

Last updated: 4/21/2026
API Version: v0.1.0
apothic-clientapireferencepython

Apothic Client API Reference#

This section is the signature-level reference for apothic-client.

Use the guides when you want workflow examples. Use the pages below when you want to answer questions like:

  • which class or decorator owns this capability
  • what parameters a method accepts
  • what type a method returns
  • which sync and async helpers exist

Reference pages#

Cross-cutting conventions#

Sync and async APIs#

The SDK is sync-first, but several major resources expose async mirrors through .aio.

Common examples:

  • app.aio.deploy()
  • remote.aio.spawn(...)
  • job.aio.wait()
  • queue.aio.get(...)
  • shared.aio.watch(...)

The reference pages below focus on the sync surface and call out async mirrors where that matters.

Client and base URL overrides#

Many lookup and management methods accept:

client: ControlPlaneClient | None = None
base_url: str | None = None

Use those when you want to override the default control-plane target or reuse an existing client instance.

Capacity filters#

Most execution-shaped resources share the same capacity fields:

  • gpu
  • gpu_count
  • min_vram_gb
  • geolocation
  • offer_filters
  • disk_gb
  • max_cost_per_hour_usd
  • related lower-bound capacity fields such as CPU, bandwidth, and network thresholds

Use the named fields for the common case. Use offer_filters when you need structured comparisons such as ranges or inclusion checks.

Storage mounts#

Mounted storage is expressed as either:

  • Volume
  • CloudBucketMount

and passed to resources through:

volumes: dict[str, StorageMount] | list[StorageMount] | None

List form is usually the most readable. Mapping form is useful when you want mount paths declared inline.

Handles and lookups#

Stateful resources can usually be recovered either by name lookup or by serialized handle:

  • RemoteFunction.from_name(...)
  • Cls.from_name(...)
  • Sandbox.from_name(...)
  • Cls.from_handle(...)
  • sandbox.attach(...)

That split is intentional:

  • name lookup is good for app-defined resources
  • handles are good for specific persistent instances or sessions

Workflow guides#

If you want tutorials rather than signatures, start with: