Modal

Modal runs a Python function on a GPU and hands you a handle to call it. /v1/functions (11 operations) is the same unit: publish a record, invoke it by name, read what it did. The structural difference to know before porting anything is that Modal deploys a graph — an app holding functions holding images, volumes and secrets, all declared in one file and shipped together by modal deploy — where here each of those is a separate record with its own address that a function refers to by name. The org is not one of those names. It comes from the validated key, so there is no workspace and no app namespace to keep in step with the function's.

Start here

Publish a function record, then call it by name — two requests, no deploy step.

# 1. mint a key — sk- belongs on a server, pk- is safe in a browser
curl -sS -X POST https://api.hanzo.ai/v1/account/keys \
  -H "Authorization: Bearer $HANZO_SESSION" \
  -H 'Content-Type: application/json' \
  -d '{"type":"secret"}'

# 2. publish the function — name is the only required field
curl -sS -X POST https://api.hanzo.ai/v1/functions \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name":"render","runtime":"python","code":"import sys; print(sys.stdin.read().strip().upper())"}'

# 3. invoke it — input arrives on stdin, the record comes back
curl -sS -X POST https://api.hanzo.ai/v1/functions/render/invoke \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"input":"abc"}'

Step 2 answers 201 with the stored record; step 3 answers 200 with a real invocation — an id, a duration and how the run ended; what it printed is at GET /v1/functions/{name}/logs. That is modal deploy plus .remote() in two calls, with no app namespace to name and no client whose Python has to match the container's.

Core capabilities

Nouns

The function

Sandboxes and shells

State, schedules and the rest

The call

Modal — a file, a deploy, and a client that looks the function up:

# thumbs.py
import modal

app = modal.App("thumbs")
image = modal.Image.debian_slim().pip_install("pillow")

@app.function(image=image, gpu="H100", timeout=900,
              secrets=[modal.Secret.from_name("s3")])
def render(seed: str) -> str:
    return seed.upper()

# $ modal deploy thumbs.py
# then, from any other process:
#   f = modal.Function.from_name("thumbs", "render")
#   f.remote("abc")

Hanzo — publish the record, then invoke it:

curl -sS -X POST https://api.hanzo.ai/v1/functions \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "render",
    "runtime": "python",
    "target": "fleet",
    "timeoutSec": 900,
    "memoryLimit": "4Gi",
    "envNames": ["S3_KEY"],
    "code": "import sys; print(sys.stdin.read().strip().upper())"
  }'

curl -sS -X POST https://api.hanzo.ai/v1/functions/render/invoke \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"input":"abc"}'

One name, render, and it is org-unique — there is no workspace, no app and no deployment id to keep aligned with it, because which org owns render is decided by the key rather than by a field anyone can write. The argument goes in on stdin and the answer is the invocation record, so nothing is pickled and the caller's Python and library versions never have to match the container's; curl is a first-class client.

The record comes back whatever happened: 200 when your code ran clean, 502 when it ran and failed, 503 when this deployment has no sandbox to run code in. A failed run still has an id, a duration and the status code your own program answered with, instead of an exception on one path and an error envelope on the other. Billing follows the same split — the flat per-invocation fee is authorized against the org's prepaid balance before any compute starts, so an unfunded org gets a 402 and nothing executes, and the GB-seconds debit lands after the run. A sandbox that was unreachable ran no billable compute and is not charged; a program that exited non-zero is, because that is a successful invocation of a failing program.

Reading it back is one call, not a tour of the dashboard:

curl -sS https://api.hanzo.ai/v1/functions/render \
  -H "Authorization: Bearer $HANZO_API_KEY"

That answers the definition, the 7-day rollup, the trigger, the twenty most recent invocations and the names of the secrets it mounts. Rollup fields are absent rather than zero when the function has not run in the window, so a console draws an em dash instead of a fabricated 0.

What does not carry

Arguments are bytes, not Python objects. Modal serializes your call arguments and the function's closure, which is why the client and the container have to agree on versions. input here is opaque to this surface and lands on stdin; structured output is whatever your program prints. A typed signature does not port — write the encode and decode yourself.

.map() and .spawn() have no counterpart. Modal fans a function across an iterable and hands back a FunctionCall you poll. POST /v1/functions/{name}/invoke is synchronous and answers when the run is over. Fan-out is a queue you drive: /v1/mq (15) for the work, one invoke per item, and GET /v1/visor/fleet/jobs to watch what the GPU lanes are holding.

gpu="H100:8" is not a field on a function. target is sandbox or fleet, and fleet means the org's own accelerators — the ones at GET /v1/visor/gpus, added by POST /v1/visor/machines or by a host running hanzo link. You choose the fleet, not the card, and fleet accepts runtime: python only.

No image builder DSL. modal.Image.debian_slim().pip_install(...) builds and caches a layer per method call. image here names an image that already exists, built by POST /v1/platform/runner or by your own CI. Nothing is installed for you at publish time; the image is the environment.

A function mounts no volume. There is no volumes= on the definition and no .commit(). Persistent working state is the sandbox's project disk, and anything a function must read or write goes through /v1/s3 (6) or /v1/kv (6) from inside the code.

Warm pools are a different plane. A function record carries a timeout and a memory limit, and no replica floor — it starts when it is called. An always-on autoscaled service is POST /v1/platform/run, which takes minScale and maxScale and is idempotent by name. Port a Modal function with min_containers there and keep /v1/functions for work that begins on a request.