Changelog

Nodes can now render on the GPU. Ask support to turn on GPU graphics for your organization. Then each new GPU node of your organization starts on a machine that carries the driver's graphics and video libraries. The container gets Vulkan, OpenGL through EGL, and NVDEC beside CUDA. Unreal Engine, SAPIEN, and the EGL renderers in MuJoCo and Genesis run on the H100. get_node reports environment.gpu_graphics, and node_doctor checks the libraries inside the node.

A node that waits for a machine with the libraries reports blocked_on.resource: gpu_graphics. New machines install the libraries when they start, so keep the node queued. A node that stopped on a machine without them cannot wake there while GPU graphics is on; create a new node instead. The robotics section of the docs lists the client libraries your image needs and what stays software-only.

An org admin can now ask for a higher limit with request_limit_increase, or autor limits request. Pass the limit's name, the value in its own unit, and a reason. When list_limits shows a raisable_to for the row, a value at or under it applies at once, and the answer says when. Otherwise the request goes on a support ticket, and an operator decides. The answer names the org and the ticket.

Refusals that used to say that support can raise a limit now name the tool. The disk warning at job submit states the model's bytes, the bytes it needs, and job_scratch_bytes. That quota covers the container's writable layer only. $GMN_CHECKPOINT_DIR, $GMN_OUTPUT_DIR, and the hf_cache mount are outside it. See Ask for a higher limit and Job disk.

get_job, list_jobs, submit_job, and submit_jobs now report queue.position as the job's place in the fair dispatch order, the same number the console shows. Before, they reported a plain count of every job submitted earlier, across every organization. Fairness makes that count meaningless: a job from a less-served organization starts ahead of yours, and the count did not know. The answer also carries queue.queued_gpu_minutes_ahead, the committed GPU minutes ahead of the job. Position and estimated_wait_seconds are null until the scheduler first computes them, seconds after submit, and while the job is held. When they are null, queue.position_note says why.

A job that was preempted, or that lost its machine, no longer expires while it waits to run again. A job holds its place for queue_ttl_minutes, 3 days by default. That clock now counts only the wait before the job starts for the first time. Before, a requeued job could expire because its original submit time was older than the hold.

Stopping a queued node is now recorded as a cancel, not as an expired hold. get_node on a create you stopped while it waited answers canceled with the reason, yours or the policy that stopped it, such as a spend cap or an empty balance. Before, it said the hold had expired with no capacity free, which was false, and a re-create within 15 minutes inherited the queue place you gave up. Only a hold that lapses hands its place to a re-create. Your own delete or cancel starts fresh. A canceled queued wake reports the stop, never a lapsed hold. See the docs.

Each task in a task set uploads its result before it reports done. When the set drains, we now put every accepted result into one artifact on the job. The artifact is a tar. Each output is at outputs/<task_id>, and manifest.json lists every done task and where its output is.

The artifact shows on get_job as tasks.outputs, with a download link, a few minutes after the last machine on the set stops. Task sets that drained before this release also get an artifact.

get_job also shows drained for a task set. The job state is the result of your own container. Other machines can still hold tasks after your container exits. drained: true means that the set is sealed and every task is done or failed.

Autoresearch now runs on prepaid credit. Your organization's balance is the limit at every door that starts compute. When the balance reaches zero, running work stops and every disk, snapshot, and sandbox is kept. Buy credit and it starts again on the next command. Your card is charged for credit you buy, never for usage after the fact.

Automatic top-up keeps a long run going. When the balance falls below a threshold, the card on file is charged an amount you choose, at most 25 times a day and within a daily limit you can set. Your agent can turn it on from a chat session, and /billing shows the balance, the runway at the current burn rate, and the rule. New accounts set this up in onboarding. Accounts that paid by monthly invoice move to prepaid credit on October 1, 2026; usage before that date is invoiced as before. The details are in the docs.

Every queued answer now carries arrival_note. It says the four things an agent needs while it waits. Set a boot command now, and the work starts the moment the node is ready, even when nobody is polling. Otherwise poll get_node and send a command inside the idle window, because a ready node with no command bills that window and then stops. Once the node runs, hold_node keeps it awake between turns. Do not delete and re-create a queued node. The new node waits from zero, and the delete withdraws the demand that starts the next machine.

Boot commands have existed since August. An agent that set one while its node was queued had no gap between ready and working. An agent that did not set one paid for arrivals it never used, and gave up queue places it had waited for. The queued answer only mentioned a boot command once one was registered, so the agents that needed the hint never saw it. The server instructions, the tool descriptions, the manual at /llms.txt, and the Queue section of the docs now say the same thing.

/billing now lists each part of your credit balance with the date it expires, soonest first. Credit that never expires says so. The /usage page names the part that expires first beside the balance, and get_billing returns the same list as credit_expiries. Before, the first notice of an expiry was the email two weeks out. Admin and billing roles see these figures.

A card now counts as a payment method only when it passes CVC verification at the moment you add it. A card that does not pass the check stays on file, but nodes cannot start on it. The create refusal, /billing, and the onboarding steps all say so, and the fix is a different card. A card you add through Apple Pay or Google Pay passes on the wallet's verification. A card you save through Link must pass the check.

The first charge on a new account also reads the payment provider's verdict. If the card is declined as high risk, the running nodes stop at once instead of when usage reaches the limit. Your files are kept, and paying with a different card restores the account.

get_job answers with a download link for a finished job's output and for its preview. Each link is a credential for that one file (7 days for the output, 15 minutes for the preview), and it goes into every transcript and log that prints the answer. Pass links: false to leave both links out. Every other field stays, so your agent polls artifact.state the same way and asks get_artifact, from the job's workspace, for a link only when it downloads. Over HTTP it is GET /jobs/{id}?links=false, and in the CLI it is autor job get <job> --no-links. The flag arrives with autor 0.24.0, so run autor upgrade first.

The HTTP API also forwards attempt now. GET /jobs/{id}?stream=run&attempt=1 returns the first attempt's log after a preemption, as get_job over MCP already did. Before this the parameter was dropped and the latest attempt came back.

Every successful answer your agent gets from a tool now carries timing_ms. server is the time we spent on the call, in milliseconds, from the request reaching us to the answer leaving. Tools that run something on a node, such as run_command and write_file, add exec for that leg. Time beyond server is in your client or on the network, and your agent can now say which.

{written: true, part_index: 3, bytes_written: 2200, sha256: "...", timing_ms: {exec: 290, server: 340}}

The report behind this was an upload in parts that took about a minute per part in a chat. Our side handled each part in a third of a second. The agent writes the content of each part as text in the call, and that is where the minute went. The docs for parts now say so, with two ways to spend less of it. Send text files as utf8 instead of base64. Use the largest part your client accepts.

The HTTP API has carried the same number since August, in the Server-Timing header. MCP clients do not show headers to the agent, so over MCP the number rides in the answer.

A new account starts with a spending limit set by its signup address: $1,000 for a company or university address, $100 for a personal address such as gmail. A disposable address gets no limit and buys credit first. When your spend for the month reaches 80% of the limit, we charge your card for the usage so far. Credit on your account pays first, and the card pays the rest. A payment that goes through raises the limit to the next step, $100 to $1,000 to $10,000, and an account that has paid $1,000 is on the ordinary monthly cap.

If the payment fails, new nodes are refused at once and running nodes stop the moment usage reaches the limit. Your files are kept, and paying restores the account. get_billing now carries a trust block with the limit, the charge point, and the next step, and /billing shows the same numbers.

A file over the single-call upload cap now goes onto a node in parts. Your agent sends each part with write_file_part, then calls commit_file_parts once. The node joins the parts in order, checks the size and the sha256 you give, moves the file into place, and removes the parts. Each part is at most max_write_file_bytes, and the whole file at most max_chunked_write_bytes, which starts at 256 MiB. Both values are in autor limits.

autor cp ./corpus.zip tulip:~/data/corpus.zip

autor cp takes this path by itself when the file is over the cap, and checks the digest of every part and of the whole file. A part sent again with the same index replaces the earlier part, so a retry after a lost answer is safe. A commit with a part missing refuses and names the missing parts. This ships in autor 0.23.0, so run autor upgrade first.

Before this, an agent that reaches a node only through the MCP connector could not put a file over 4 MiB on the node. Now it can, with two tools that work like write_file.

curl -fsSL https://autoresearch.sfcompute.com/cli.sh | bash
autor login
autor node create --name tulip --chip h100 --wait

The command-line tool installs as autor, the short form of Autoresearch. gman, its name until today, still works: the installer creates gman as a link to the same binary, and autor upgrade (or gman upgrade) on an existing install adds autor beside it. Nothing you have written needs to change, and one upgrade updates both names.

Help text, messages, and the docs now say autor. Your stored credentials, the configuration directory, and the GMAN_ environment variables do not move.

When you accept a compute grant into an organization you already have, and that organization has no payment method on file, it now runs on the grant alone - the same as a new organization created for the grant. Before, the credits landed but nodes would not start until a card was added.

Nothing else changes. Organizations with a card keep it: the grant is spent first, and the card covers only what goes past it. An organization on the grant alone stops when the grant is used up; add a card at any time to keep going on your own account. Organizations that were already in this position are unblocked today. One exception: an organization with billing history that no longer has a card still needs one, and the consent page says so before you choose.

Givemeanode is now Autoresearch, a product of San Francisco Compute. The website is autoresearch.sfcompute.com.

Your account, organizations, credits, and running work stay the same. Use your existing login. Your saved MCP connections, tokens, and CLI installs keep working. The CLI command is still gman.

New MCP connections can use https://mcp.autoresearch.sfcompute.com. The existing mcp.givemeanode.com endpoint remains available.

Most jobs start in seconds. The slow ones waited in two places with nothing to read: for a build slot, and for GPUs. Both now speak, and both got faster.

Builds. Your org can run 4 image builds at once, up from 2, and each machine takes more than one build. When a build must wait for a slot, submit_job says so in build_note and get_job repeats it while the wait lasts. A build whose machine stops reporting progress for 15 minutes is rebuilt elsewhere instead of waiting out its timeout. Identical contexts still share one build, and a prebuilt image skips the build.

Capacity. A job backlog that persists for 5 minutes now raises the fleet's buy target (it was 15), and the target is sized to drain the backlog in about 4 hours (it was a day). Queue the whole shape of your work and give it tens of minutes, not an hour.

Resume. Once one job has checkpointed in your org, later jobs with the same image and command inherit resume: "checkpoint" and can start in shorter capacity windows. get_job shows resume_source: "inferred" and the job it learned from. Pass resume: "none" to run a job as one attempt. gman job submit takes --resume checkpoint and --resume none.

When you stop a node, billing ends at once. The disk parks a moment later, after the node saves its last writes to durable storage. After a large write that takes some minutes. Until now the node read stopped through that time, and a snapshot you asked for then failed as superseded, because the disk was not parked yet.

The node now reads stopping until the disk is parked, then stopped. stop_node answers stopping when the disk has not parked within 20 seconds, and the call no longer waits for the whole save. snapshot_node on a stopping node tells you to poll get_node for stopped and try again. A run_command on a stopping node wakes it without waiting: the save is cut short and continues while the node runs.

A wake that restores a node from its snapshot now downloads the snapshot as eight parallel ranged requests instead of one stream. One stream moved about 17 MB/s; the snapshot of the same node uploaded at 110 MB/s through eight parallel parts. A 32 GB restore that took 31 minutes should take about 5.

While a restore runs, get_node estimates the time to ready from the bytes that have landed, not from past restores of other sizes, and reports the measured download rate. A note that the control-plane connection dropped during a restore now says the download continues and that stopping the node would restart it from zero.

A session opened in an organization now creates, arms, and deletes connections and secrets in that organization. Before, these commands used your active organization while gman connection ls, gman import, and the node itself used the session's. A teammate with two organizations could create a connection, see it in gman connection get, and not find it in ls or in an import.

Every connection and secret answer now names the organization it acted in, and gman connection ls and gman secret ls print it above the rows. That ships in gman 0.19.10. A lookup that misses tells you when the name exists in another of your organizations. A member who is not an admin gets a refusal that says so, never a copy in the wrong place. The docs name the environment-variables path for a run that cannot wait for a connection.

The Data Use Policy is now version v2026-09.1. It adds an “Advertising measurement” section. When an account confirms a payment method and starts to use the service, we may report that fact to the advertising platform that showed the ad. The report identifies the account only by a one-way SHA-256 hash of its signup or contact email address, and it contains no customer content. The training commitment is unchanged.

The CLI now prints its own reference. One page carries every command, every flag and every exit code, and it is generated from the CLI itself, so it says exactly what your gman accepts.

gman reference          # the whole syntax, offline
gman node create --help # one command's entry

Your agent gets the same page without an install. The agent manual at givemeanode.com/llms.txt now carries a CLI section, and it names the URL that serves the reference in one fetch, with no sign-in. So an agent can read the syntax before it runs anything.

Two commands the docs described are real commands now. gman hold tulip --until 2h keeps a node awake while you work on it by hand, and gman hold tulip --release ends the hold. gman run takes --on-wake with --max-duration to start a command the instant a queued node is ready, --hold-on-failure to keep a failed run's data on disk, and --max-wait to size the queue hold a wake takes. Every CLI example in the docs is now checked against the CLI's own parser, and the examples that did not survive that check are fixed.

All of it ships in gman 0.19.9. Run gman upgrade to pick it up.

The pricing table and the docs called the idle window a “per-session minimum”. It never was one. A node that goes idle keeps running for its idle window, and it bills while it runs. If you stop the node, billing ends at the stop. A session that ran two minutes pays two minutes.

The pricing table now reads “15 min idle window ($0.90 at most)” on a 1x node, and the docs say the same. Nothing about billing changed. rate.minimum_minutes and rate.session_minimum_usd keep their names in the API. They report the length of the idle window and what the whole window costs if you let it run out. See the docs.

Every environment variable this platform reads starts with GMN_. The service token was the one exception. It was GMAN_TOKEN, so wiring up CI meant reading one prefix on the Team page and a different one in a client library's README. The variable is now GMN_TOKEN in every place we name it. That covers the docs, the Team page, the line gman token create prints, and the config gman mcp install writes for your agent.

gman token create --name ci-deploy --workspace protein-lab
# prints GMN_TOKEN=gmnt_... once

A pipeline you already run does not stop working. The CLI still reads GMAN_TOKEN, and a pipeline that sets both names uses GMN_TOKEN. Rename yours when it suits you. The new name ships in gman 0.19.7, so run gman upgrade to pick it up.

A grant program invited people one at a time, and each person who accepted got an organization and a grant of their own. That is the right shape for a residency. It is the wrong shape for a professor with a class: a course wants one organization, everyone in it, and one pool of compute they all draw from.

Your program's page now has Invite a group. Name the organization, list its admins (the professor) and its members (the students), and set one shared grant. Every person still gets their own invitation, bound to their own email address, and every one of them lands in the same organization: the first to accept creates it and receives the grant, the rest join it as they accept, and nobody is offered an organization of their own. Admins manage the organization and see all of its usage; members run their own nodes and see their own.

The group reserves its shared grant once, not once per person, so inviting thirty students to a $600 pool holds $600 of escrow, and an invite nobody accepts releases it the same way a personal one does. The program's page shows each group, how many have joined, and the organization once it exists; revoking a group's grant also withdraws any invitation still out. You can add people to a group later, and inviting one of its members again as an admin makes them one when they accept, so a mistyped professor's address is a correction, not a dead end.

Occasionally the machine under a running node stops answering the platform, most often for under a minute during one of our own deploys. Commands into the node fail fast with “host isn't responding” while it lasts, but until now get_node kept reporting the node as running with its disk intact, so an agent polling it had no way to tell a brief blip from a machine that was gone for good.

get_node now carries a host section for as long as the silence lasts: responding: false, when the host was last heard from, and a silent_seconds counter. The note in it says what to do - retry first, because most silences end in about a minute; if the host is really gone the node is marked lost after a few minutes of silence, billing closes back at the last heartbeat, and the loss is credited automatically. A stop_node during the silence still works and ends billing right away. When the host answers again, the section disappears. The “host isn't responding” errors now point at it too.

A job can now carry checks. A success check runs one time, when the job stops, over the job's outputs. The job gets the succeeded state only if the check passes, so a downstream reader cannot take an unusable file from a job that reported success. A health check runs on an interval while the job is live, and you choose what a failure does.

gman job submit --chip h100 --image my-registry/eval:v3 --command 'python eval.py' \
  --checks '{"success":{"check":{"all_of":[
    {"type":"file_exists","path":"/output/rows.jsonl"},
    {"type":"jsonl_field","path":"/output/rows.jsonl","field":"logprob_mean","require":"nonnull"}]}}}'

A check is configuration, not a script. The types are file_exists, file_grows, file_size, jsonl_field, jsonl_rate, heartbeat, gpu_util, gemm_sane, http, tensor_changed and exec, combined with all_of and any_of. The platform validates your declaration when you submit and evaluates it from outside your container, so you install nothing in your image and a check works when your job's own environment is the part that is broken.

A health check finds the failure a loss curve hides. Set on_fail to record to write the failure to the job record, kill to stop the job and close the meter, or reschedule to run the job again on different hardware. Before a kill or a reschedule the platform captures your checkpoint slot, so write your state to $GMN_CHECKPOINT_DIR and pass resume: "checkpoint". A check that fires then costs you the time to resume.

{"health": {"check": {"type": "heartbeat", "path": "/output/heartbeat"},
            "interval_s": 600, "grace_period_s": 900,
            "fail_threshold": 2, "on_fail": "kill"}}

Every submission also runs preflight, which is free and adds about two seconds. If the job's worst-case cost is more than the money that remains under your cap, we refuse the job and show the arithmetic, because otherwise the cap stops the same job in the middle of the run. If the model your job downloads is larger than the node's disk, we warn. Both checks stay quiet when the data is not sufficient. Run them without submitting with gman job validate.

Jobs on the MCP interface must declare at least one check. The docs carry every type and the full contract. The CLI half, --checks, --force, --no-preflight and gman job validate, ships in gman 0.19.8, so run gman upgrade to pick it up.

A finished job now carries a receipt. image_digest is the manifest digest we resolved and pinned for the run. Beside it are billed_seconds, charged_usd_micros, and one row per billed attempt with the rate it billed at. These come from the same billing records your invoice totals to, so you get a result and its price in one lookup. The digest was not available before this, and the cost was only in a usage report for a date range.

gman job get job-8x2mf
→ ... "receipt": {"image_digest": "sha256:70d6845739d5...",
                  "billed_seconds": 10650, "billed_attempts": 1,
                  "charged_usd_micros": 8866, "attempts": [...]}

Billed seconds are the seconds for one GPU. The charge is seconds x gpu_count x rate / 60. An attempt we cut short, such as a preemption, bills only the progress that survived. It bills nothing unless it had checkpointed. A shorter list is the free attempts rather than a gap.

A billing fix ships with it. A job we ended at its max_duration closed its attempt at the instant that attempt began. A run of hours then billed the one-minute minimum and read as zero length. The attempt now closes at the deadline you bought, and never later. You do not pay for our own enforcement running late. The deadline also survives an agent restart on the machine, which is what let one job run past its cap. See the docs.

The queue now has its own page in the sidebar. Jobs first, then interactive nodes, each in the order the scheduler will serve them, with your own entries named and everyone else's reduced to a position and a size: how long a queued node has waited, and how long a queued job may run. Positions are the scheduler's own, so the number you see is the number it acts on. The page updates on its own while you watch, and a row opens to show the details behind it.

Your standing sits in the top bar: your best position, your priority tier, and either how many priority boosts you have left this hour or the head start every account's first node gets.

That works now, in both directions. A snapshot taken on a cpu-2 or cpu-8 node restores onto an H100 shape. A snapshot from an H100 node restores onto a CPU shape. You can prepare data on cheap cores, and then start a GPU node from the result.

We refused this restore on 2026-08-31 because the volume image did not survive the move. Our two host types each derived the volume key in a different way. An image written on one type therefore decrypted to nothing on the other. The restore now finds the method that the source image was written with. It also checks that the image holds a filesystem before it copies anything. A damaged snapshot now fails at once, instead of after the whole transfer.

Org storage is still the better choice when more than one node needs the same data. Call export_data on the first node and import_data on each of the others.

A sandbox can now serve to the internet. expose_sandbox_port takes a sandbox and a port and returns a public HTTPS URL that reaches whatever is listening there, so the page your agent just wrote is something you can look at. Until today a sandbox could only reach out, and a workload that had to be reachable belonged on a node.

gman sandbox exec sbx-0a1b2c3d4e5f -- sh -c 'cd app && (npm run dev > /tmp/dev.log 2>&1 &)'
gman sandbox expose sbx-0a1b2c3d4e5f 3000
→ https://sbe-9k2fq-vx7t3m8dk4qwrz2n.givemeanode.io

The server has to be listening on the sandbox's own 127.0.0.1, which is where a dev server listens by default, and it has to outlive the command that started it. An exec waits for its command's output to finish, so redirect the output as in the example and the exec returns straight away. This works on a sandbox baked with no network at all, because nothing inside it has to reach out for the URL to work.

Anyone holding the URL can reach the port, so treat it like a password, or pass auth: "bearer" for a token on top. Asking for the same port again returns the same URL with a fresh expiry. The URL dies with the sandbox, and a fork does not inherit it. Streaming responses, server-sent events and WebSocket connections all pass through. The docs carry the full contract. The CLI half, gman sandbox expose and unexpose, ships in gman 0.19.5, so run gman upgrade to pick it up. In the ComputeSDK provider, getUrl calls the same thing.

A rollout is one episode of a policy in an environment. It starts from a state, runs under a judge, and ends in a verdict. You bring the environment and one spec for each episode. We record three things for each rollout. We record its identity, computed from what it is. We record its lineage, when it starts from a state that another rollout declared. We record its verdict, with a stamp that says who declared it and from where. We do not read your spec or your state. Rollouts run on the task sets and sandboxes you already use. Both work as they did before.

There are two kinds of environment. A task environment is a container that serves the environment. It leases episodes in batches and declares their verdicts from inside. We ship mjx-rollout for MuJoCo on a GPU and openenv-rollout for an OpenEnv image at a digest. A sandbox environment is a snapshot that you baked. We fork it once for each rollout, and your harness grades the fork from outside. Nothing inside a sandbox can declare a verdict. No setting allows it. The code under test does not grade itself.

Under the eval profile, a rollout with an identity that already ran returns its stored verdict. It is not billed, and the response names the original. A rollout can declare states. You can fork children from a state, and we attest a group of children that started from one state. An evaluation collects rollouts under one judge and reports on them. When you supply real outcomes, the report adds the correlation with them. A rollout that failed on our side is void. It is not billed and it is not in the report. Your bill has no new line. Episodes cost what their jobs and sandboxes cost. States cost what snapshots and storage cost.

Rollouts are on for every organization since 2026-09-04. If your agent's tool list does not show the rollout tools, reconnect it, then ask with file_ticket. From a terminal, use gman rollout and gman evaluation. They ship in gman 0.19.6. Run gman upgrade to get them. The docs carry the whole contract.

Nodes used to run curated catalog images only, so a framework distributed as a Docker image could run only as a batch job. Now create_node's image also takes a registry ref, and the node runs your image under the platform's supervision. A tag resolves once at create to a manifest digest and every start runs exactly that build, so a moved tag never changes an existing node. Your persistent disk mounts at the home path you declare, with the image's WORKDIR as the default, and only that path survives stops.

Private refs pull through the org's registry connection whose scope pin admits them, the same resolution batch jobs already use, and credentials never ride the create call. After the first start, get_node reports what the image carries, such as python3, sudo, and nvcc, so a missing tool is a fact you can read. The docs carry the full contract. The catalog remains the recommended path where it fits: those images are pre-pulled on every host, and their CUDA contract is checked in CI. The CLI half, a --home flag and the ref-aware --image help, ships in gman 0.19.4, so run gman upgrade to pick it up.

Scratch space on the two largest shapes now lives in RAM rather than on the virtio disk. Writing to /tmp is faster and deleting from it is much faster - unlinking a large build tree from memory is nearly free, and that turns out to be a bigger share of a build's wall clock than the writing.

Capacity is half the shape's memory: 16 GiB on sandbox-lg, 32 GiB on sandbox-xl. At least what the disk gave you, so nothing that fitted before stops fitting.

One trade worth knowing: /tmp now competes with your own process for that memory, so a job that fills both can be OOM-killed where it would previously have got “no space left on device”. If you write tens of GiB of scratch, keep it under your working directory instead. sandbox-sm and sandbox-md are unchanged.

get_node now reports device memory per GPU on a running GPU node. Until today the only way to read headroom was to run nvidia-smi on the node yourself, which meant a shell round trip to reach a number we had already measured seconds earlier.

gman node get tulip
→ "gpu_memory": { "as_of": "2026-09-01T12:00:04Z", "free_mib_min": 18842,
    "gpus": [ { "uuid": "GPU-db99...", "used_mib": 62717,
                "total_mib": 81559, "free_mib": 18842 }, ... ] }

Size a second workload against free_mib_min, the tightest card on the node, rather than against a node-wide total: co-located jobs run out of memory on one device, not on the sum of all of them. The UUIDs are the same ones nvidia-smi -L lists inside the node.

The numbers come from the node's newest heartbeat, and as_of says when that was. A card that went unsampled on that heartbeat carries no numbers, which means unknown rather than empty, and the whole block is absent when the newest reading is too old to publish. A missing block never means plenty of room.

A storage/<name> connection already names one of your buckets, so a source on it can now be a plain key. train/ means the same as s3://corpus/train/, which is the way gman storage ls and list_storage_objects already print keys. Writing the full url still works exactly as before, and the same two spellings work for an export_data destination and for a job's output_to. The CLI half ships in gman 0.19.3, so run gman upgrade to get the updated --help.

Before this, the short form was refused with “train/ is not an s3:// url”, which was also the form our own docs example used. Connections to a bucket somewhere else (kind s3-keys) still need the full url, because there the bucket is not implied, and that refusal now names the url to write instead of only saying what was wrong.

A cold dependency install is mostly wire time: about 792 MB for a large monorepo, and almost none of it CPU. Every sandbox host now runs a pull-through cache of the public registry, shared by everything on that machine, so a package somebody else pulled recently arrives without crossing the internet.

Your install is still a real, cold download of every package your lockfile names. Nothing is pre-seeded and nothing is skipped - the bytes just travel a shorter path.

There is nothing to configure. We set the default registry only, and only by writing ~/.npmrc when there is no file there already, so a home-directory .npmrc of your own is never touched and scoped registries keep working. If the cache is unavailable the sandbox talks to registry.npmjs.org directly. One case needs a line of your own: an auth-only project .npmrc for private npmjs.org packages should carry an explicit registry= line, because npm keys its token to the registry it resolves.

Getting a single small file onto a node used to mean a bucket round trip or a hand-written API call. There is a verb for it now, and it uses the same grammar as scp.

gman cp ./run.sh tulip:~/run.sh --executable
gman cp tulip:~/out/metrics.json ./
gman cp tulip:~/prep/app oak:~/app

The side that names a node is written node:path, and the other side is a path on your own machine. Two node sides copy between the nodes without going through your machine at all, and the command waits for the copy to land. Every direction verifies the file's digest for you, and a download that does not match is discarded rather than left under the name you asked for.

An upload carries the file in the request, so it is meant for configs and entry scripts. The cap is the max_write_file_bytes limit that gman limits reports, and past it the command tells you to send the file through object storage instead, which streams. Downloading a directory gives you a tar of its contents. This ships in gman 0.19.0, so run gman upgrade first.

get_node now reports recent GPU utilization on a running GPU node, so your agent can answer that from the call it is already polling.

gman node get tulip
→ "utilization": { "gpu_pct_max": 3, "gpu_pct_latest": 2,
                   "window_minutes": 10, "sampled_minutes": 10, ... }

You get the busiest GPU on the node for the last ten minutes, both as the maximum over the whole window and as the newest minute. A maximum near zero across the window means nothing has touched the GPU, which is worth a look before you keep paying for it.

Utilization is sampled once a minute, and sampled_minutes tells you how much of the window actually carries a sample. If it is lower than window_minutes, the rest of the window is unknown rather than idle. If nothing was sampled at all, there is no utilization block, so a missing block means no measurement rather than zero.

What we called rollout sandboxes is now just sandboxes, in the docs, in the pricing table on the front page, on your usage page, and on your invoice. A rollout is one thing you can run in a sandbox. Plenty of you run agent tool calls, builds, and untrusted code in them instead, and the shorter name covers all of it.

Nothing else moved. Every call, parameter, and id is unchanged, the rates are the same, and the docs section keeps its address. Three labels read differently. The two pricing rows are now Sandboxes (active) and Sandboxes (parked), and the line on your usage page and your invoice is Sandboxes. If a script of yours matches on those strings, that is the one thing to update.

The renamed gman sandbox --help text ships in gman 0.19.1, so run gman upgrade to pick it up.

That restore now refuses immediately, and tells you what to do instead. A volume snapshot taken on a CPU node does not currently survive being restored onto a GPU node, or the reverse: the copy lands, the node then fails to mount it, and you have paid for the whole transfer before finding out. On a corpus that is hours.

So create_node checks the snapshot's shape against the one you asked for and refuses the mismatch before any bytes move. Restoring within a family is untouched: a cpu-2 snapshot still restores onto cpu-2 or cpu-8, and an H100 snapshot onto any H100 shape.

To move data between the two, use your org storage instead - export_data from the node that has it, import_data onto the node that needs it, with no egress fee on either leg. We are still chasing why the volume itself does not travel; this is the part we can stop charging you for today.

The dashboard's sidebar listed twelve pages, and five of them were settings screens: Settings, Team, Spend limits, Programs, and the Audit log each had a row of their own. Finding the one that holds what you want to change meant reading the whole list.

Now one Settings entry holds all five, and you switch between them with tabs at the top of the page. Nothing moved underneath: every page keeps its address, so bookmarks and links still land where they did, and the find palette still jumps to each page by its own name.

A node with a trainer running on it no longer stops when its idle window lapses. Until now “idle” meant no command session was attached, which missed every way of starting work that outlives the command that started it. If you launched a trainer with nohup, or inside tmux, the command returned, the node reported running (idle), and fifteen minutes later we stopped it while the GPUs were at 100%.

Now we look at what the node is doing. Sustained GPU or CPU use pushes the idle deadline forward for as long as the work lasts, so the run survives. When the work finishes, the ordinary window runs from that moment and the node parks with files intact, as it always did.

The utilization section of get_node now carries the verdict we act on, alongside the GPU numbers it already reported. busy is true when we can see the node working, which is exactly when we will not stop it. cpu_pct joins it as percent of one core, so 300 means three cores are busy, and the section now appears on CPU nodes as well. A field is absent when nothing was sampled, which means unknown rather than zero. Build your own guards on those numbers rather than on the status label.

A process that is alive but doing nothing still reads as idle, because from outside it is. Use hold_node to keep a node like that awake. The workspace idle-burn alert now defers on measured CPU too, so a dataset download or a dependency install no longer looks like an idle GPU to it.

It was us, and the honest answer is that we could not tell. A GPU can fail in a way where everything we checked stayed green: the driver reported it healthy, containers started on it, and even a small test matmul passed - while every real workload placed on it died a couple of minutes in with CUBLAS_STATUS_EXECUTION_FAILED. The board was answering questions and not doing arithmetic. Work kept landing on it, and because each run exited with an error of its own, each one billed as your job failing.

Every GPU host now proves the harder thing on a cadence: a sustained bf16 matrix multiply on the devices nothing is using, with the answer checked against what it should be. A device that fails it twice stops taking work immediately, and any run already on it is cut as a fault on our side - which means it does not bill and it re-places on a healthy host, instead of coming back to you as a failure you paid for.

While a run is live, get_job reports its host under host_gpu_health if there is anything wrong with it - the same field get_node already carried - so an agent polling a job can see the difference between its own bug and our hardware without asking.

Snapshotting a node's prepared disk and cloning it was an agent-only feature. It now has HTTP routes and CLI verbs, so a shell script or a CI step can bake an environment once and start machines from it.

gman node stop tulip
gman node snapshot tulip          # → snap-8k2mp
gman node snapshots               # poll until STATUS is ready
gman node create --name tulip-2 --chip h100 --from-snapshot snap-8k2mp --wait

gman node rm-snapshot deletes one and gman node snapshot-expiry gives it a self-cleaning timer. The docs have the whole surface under Snapshots.

The same gap existed for holds, mission charts, the log, metric and trace queries, metrics scraping, alert settings, and the two organization identity settings. All of them answer on the HTTP API now. We said everything an agent can do over MCP a script can do over plain HTTP, and it was not quite true. A test checks it every build now, so it stays true.

The CLI verbs ship in gman 0.17.0, so run gman upgrade first.

Waking a stopped node whose disk lives in our object store means downloading that disk onto a fresh machine, and a large one can take an hour. If our connection to that machine blinked during the download - a second, sometimes less - we used to treat the download as lost, move your node to another machine, and start it again from zero. The machine we walked away from carried on downloading regardless, and finished into nothing.

Now a blink is just a blink. Your node stays with the machine that is already doing the work, and we pick the answer back up when the connection returns. A machine that actually fails your wake still hands it straight to another one, as before.

While a wake is downloading, gman node get reports the bytes so far and the total under restore_progress - that is the number to watch, and the honest way to tell a slow wake from a stuck one. None of it is billed: a node costs money only once it is running.

A wake that has bounced now says so in the list, too, instead of reading as a plain unexplained restoring.

$ gman node ls
NAME  CHIP  STATE                       CREATED               LAST FAILURE
gen5  h100  restoring (from snapshot)   2026-08-27T13:33:42Z  the control-plane connection to the host dro...
gen6  h100  running                     2026-08-28T00:25:56Z

The full text is on gman node get. A node that is up and running does not carry the column - whatever went wrong on the way there is history by then. The list half ships in gman 0.17.1, so run gman upgrade first.

The best thing you can do for wake times is keep the node's disk small: the download scales with it, so pushing finished checkpoints off to your own storage turns an hour into a couple of minutes.

There is a new page at /settings/data with six switches on it: command output, command lines, declared results, logs, traces, and job logs and artifacts. Turn one off and that data is never written - not written and deleted later. Turn all six off and no content from your workloads reaches our systems at all.

Each switch says what it costs before you flip it, because every one of them pays for something. Off, get_command returns no output after a command exits. Off, mission receipts carry no answer. Off, query_logs and the Logs tab return nothing and your log-ingest bill goes to zero. Nothing here is free, and the page would be dishonest if it pretended otherwise.

Your agents can read the policy too, so they stop polling for an output that is never coming. When a capture is off, get_command says so in a retention field rather than leaving an agent to guess whether the result has simply not been written yet.

If your retention posture belongs in a repo beside everything else you configure, it can be set from a script. Only what you name changes, so a line that turns logs off never quietly re-enables something else.

gman retention                              # what we keep today
gman retention set --logs off --yes         # stop shipping logs
gman retention set --zero --yes             # every optional capture off

Some things are not switches. Command output and stored command lines now age off their records after 90 days for every account, whatever else you set - changeable from 1 to 365 days. The record itself survives, because it is what proves the work ran and what it cost. And a snapshot is yours rather than something we retain about you, so it never expires unless you say so; turning captures off never touches one. You can set a default expiry for new snapshots if you want one.

Logs and traces have windows of their own, and you can set them. They are kept 31 and 14 days by default, and either can go as low as a day. These two are applied by the log and trace stores rather than at capture, so a change reaches them within a few minutes instead of instantly, and shortening a window deletes what is already past it.

gman retention set --logs-days 7 --yes     # keep logs, but only a week
gman retention set --traces-days 3 --yes   # and spans for three days

What no setting turns off is written down beside the switches, because a retention promise is only checkable against what it does not cover: the audit log for 24 months (decisions and money, never workload bytes - including the record of changes to this policy), billing records, routing metadata, support tickets you opened, and your volume's contents until you delete the volume. Turn everything off and that is exactly what remains - the fact that a machine ran, what it cost, and who asked for it.

One caveat worth stating plainly: turning a capture off also purges what it already holds - an hourly sweep drains the history - and turning it back on recovers nothing. Content we declined was never written, purged content is gone, and neither can be restored by changing your mind. This ships in gman 0.18.0, so run gman upgrade first.

gman node ls lists one workspace, and it now says which one before the table.

$ gman node ls
workspace: default - these are its nodes only. Another workspace's nodes are not listed here (select one with --workspace <slug> or GMAN_WORKSPACE).
NAME    CHIP  STATE                       CREATED
sutro3  h100  stopped (disk snapshotted)  2026-08-11T18:03:59Z

The table used to be the whole output, so a teammate's node in another workspace was invisible with nothing to suggest another workspace existed. The header names the room, and when other members have nodes in your list, the count of them prints under the table. Both go to the error stream, so piping gman node ls into something still gives you exactly the rows.

gman whoami now reports the workspace your CLI lands in by default, and gman workspace ls lists the workspaces your org has, so a node you expected and cannot find has somewhere to look next. Any member can run both.

$ gman workspace ls
WORKSPACE  DEFAULT  CAP
default    yes      $8000
osteosarc  -        $200
materials  -        $50

This ships in gman 0.16.1, so run gman upgrade first.

Friday is now the cheapest day of the week to run a node, and Saturday and Sunday are cheaper than a weekday. On H100 that is 33% off list on Fridays and 20% off on weekends. The days are counted on the US Pacific calendar.

The discount applies to the minutes that actually run on those days. If you start a node on Thursday and leave it up, its Friday minutes are discounted. If you start one on Friday and leave it up, its Monday minutes are back at the ordinary rate. A calendar day only ever lowers your rate, so the rate quoted when your session opened is still the most you will ever pay for it.

Every response that carries a rate now carries rate.calendar as well, with today's percent off, the schedule, and the next cheaper day and what it would cost. Batch jobs are already discounted below the interactive rate, and a calendar day reaches them only when that day is cheaper still, which today means Friday moves a job and the weekend does not.

gman mcp install now finds every coding agent you have and wires each one, instead of only Claude Code. Claude Code, Codex, Cursor, opencode, Amp, oh my pi, and Zed are all handled, each in its own config shape.

gman mcp install

It tells you what it found and what it did with each, so you can see it worked. Agents with their own command get driven through it, plain JSON configs are merged into with every other server you had left alone, and anything we would have to reformat to write gets printed for you to paste, with the reason. A config file we cannot read is never rewritten. If the machine has no coding agent at all, it says so and names what it looked for, rather than leaving you to guess.

Use --client cursor to wire one agent instead of all of them, and --print to see the config without writing anything. This ships in gman 0.16.0, so run gman upgrade first.

If your agent runs on a dev box or a cloud machine, adding givemeanode used to end at a browser page saying localhost refused to connect. The approval opens on your laptop and redirects to a localhost that is not the machine your agent is on, so it never arrives. Two lines fix that now.

curl -fsSL https://givemeanode.com/cli.sh | bash
gman mcp install

gman mcp install signs you in with a code you approve on any other device, then points your client at gman mcp serve, which reaches givemeanode on its behalf. No browser opens on either machine, and you do not need a token or an admin to mint one for you. It also replaces the entry an earlier attempt left behind, so it is worth running even if you already tried. Claude Code is wired for you, and --print --client codex prints the block for other clients.

On a machine that is rebuilt for every task, approving a code each time is not practical. Set GMAN_TOKEN to a service token and the same command writes the header form instead. This ships in gman 0.15.0, so run gman upgrade first if you already have the CLI.

create_sandbox_env now takes from_image, a container image of your own, instead of one of the three curated names. If the environment you want already exists as a Docker image, you can boot it rather than rebuilding its setup as a warm script.

gman sandbox bake --from-image ghcr.io/acme/task@sha256:8f43...c21a
gman sandbox fork env-7fa2 --count 64

We convert the image to a root filesystem the first time you name it, which for a large image takes a few minutes. Every later bake of the same image reuses that work. The env behaves like any other one after that, so forking it is free and sandbox_exec works the same way.

Name the image by digest rather than by tag, because a tag can be moved to point at different bytes later. A public image needs nothing else. For a private one, create a registry connection covering the reference and we use it for the pull. This ships in gman 0.14.0, so run gman upgrade first, and gman sandbox bake --help has the rest.

Creating a sandbox is now fast, even your first one. For the default image, we keep sandboxes running before you ask. Your create claims one and returns it. Nothing boots and nothing forks. The response says pooled: true, and in a ten-create check against production on August 28, the pool served every one.

When the pool has nothing that matches the image, memory, and network you asked for, your create forks a base we keep warm instead of booting. The response then says shared_base: true. Either way, a new workspace gets the same speed as one that has made a thousand sandboxes. A create that names another image, more memory, or a setup command takes the old path at the old price.

The measurement is one hundred creates at once. On August 27 the median create took 5.4 seconds, because everything waited on one boot. It now takes 229 ms to 249 ms, measured from our test rig over connections that were already open. Our own share of each answer is under 90 ms, and most of the rest is the network between the rig and us. The fleet also grew between the two readings, so the gap is not from this change alone.

Billing starts when you receive a pooled sandbox. The time it ran before you asked is free. You get the default image with 2 GiB of RAM, exactly what a fork would have given you. Sandboxes with no network are kept as their own stock: a create with egress: "none" only gets one that never had a network, and a default create never gets one of those.

The rest of the RL loop is unchanged. Bake your environment once with create_sandbox_env. Fork one sandbox per sample, up to a thousand at once (256 per call); forks are free and take about 50 ms. Snapshot a running sandbox in about 150 ms, without stopping it, and fork from that branch point.

Idle sandboxes park themselves after 1.5 seconds and wake in tens of milliseconds. Parked time bills about 330x cheaper than running time, so a sandbox that waits on your agent costs close to nothing while it waits.

The whole loop is in the docs under sandboxes.

gman storage cp corpus/items/ ./items
downloading 6431 objects (16.2 MiB) from corpus/items/ - 32 at a time
downloaded 6431/6431 objects (16.2 MiB)

gman storage cp corpus/ ./corpus.zip

Getting data out of a bucket used to mean one object at a time. gman storage cp took a single key, so a corpus of a few thousand small files was either a shell loop that spent an hour waiting on rate limits, or a detour through the S3 endpoint with an access key you had to mint first.

Now a source that ends in a slash means everything underneath it, and a bare bucket name means the whole bucket. The objects land in the directory you name, with the layout they have in the bucket, and they transfer in parallel under the same --concurrency the upload side uses. The same six thousand objects come down in about as long as their bytes take.

Give the destination a .zip name and you get one archive instead of a directory, which is what most people were building by hand after the download anyway.

Without the trailing slash the source is still a single object, so a one-file download never turns into a whole bucket by accident. If you ask for a name that has objects under it, the error hands you the command with the slash. If an object is deleted while a download is running, the command names it and exits nonzero rather than reporting a corpus that is missing a file.

This ships in gman 0.13.0. Run gman upgrade, then gman storage cp --help. Object storage is written out under object storage in the docs.

Cards live in Stripe's hosted billing page, and ours had a tax ID field on it. On the card and Link paths that field was never shown and never filled, but it was still sent - empty - and Stripe refused the whole thing: you passed an empty string for ‘billing_details[tax_id]’. Adding a card failed, with a message about a field that was not on the screen. Reloading the page sometimes got past it.

The field is gone. Nothing else about that page changed - the same card entry, invoice history, receipts, and billing address. A card never carried a tax ID anyway: Stripe rejects one on a card whether it is empty or filled in. If you need a tax ID on your invoices, ask us and we will put it on your account.

Importing a “/”-terminated prefix of more than a few hundred objects failed the moment it started, with “Argument list too long” - and the error advised a retry that could never work, because the failure was deterministic: the handoff that carried every object's download URL rode a channel with a fixed size cap, and a few hundred objects overflowed it. That handoff now streams, so a prefix import carries as many objects as the listing allows, regardless of how long their names are.

That listing allowance was a fixed five thousand objects, which put a 5,254-file dataset totalling 6.2 MB out of reach entirely. It is now max_import_files, a limit like any other: twenty thousand by default, shown by list_limits alongside where you stand, and raisable for your org without waiting for a release.

Past that cap, a flat prefix - thousands of objects side by side, no sub-directories - used to be a wall: the refusal said to import a narrower source, and for that layout no narrower source existed. On storage buckets, a source that does not end in “/” and names no exact object now imports every key it prefixes. .../items/a, then .../items/b, and so on splits any flat prefix into chunks you size yourself; an exact object key still imports just that object, as before. The over-cap refusal now spells out that split, instead of pointing at a narrower source that may not exist.

A job may capture its checkpoint at most once every 5 minutes (one accepted POST /v1/checkpoint per job per 300 seconds - checkpoint_min_interval_secs in list_limits). Declaring faster than that has always answered 429, but the refusal named the interval only in prose, and a checkpoint request on an attempt that was already ending answered 429 too - so a training script could not tell “slow down” from “stop” without parsing sentences.

Now every pacing 429 from the in-container metadata service - /v1/checkpoint, /v1/preview, /v1/sample, /v1/yield - carries a Retry-After header with the seconds until the next declare is allowed, and the same number as retry_after_secs in the JSON body. Refusals that are not about pacing stopped wearing 429: a checkpoint request for an attempt that is not running or already ending answers 409. A refused declare never costs you anything - your last committed capture stands. The cadence is also documented where agents read, in llms.txt.

Every node has a ceiling on how many processes and threads can exist inside it at once - it is what keeps a runaway fork loop on a shared machine from taking the neighbors down. Until now it was fixed at 4096. That is plenty for almost everything, but a serving stack that runs many inference engines side by side - eight SGLang engines under Ray Serve pass four thousand threads before the first request arrives - hits the wall, and past it every new thread fails with “Resource temporarily unavailable”.

The ceiling is now the node_pids_max limit. It shows up in list_limits with everything else, the default stays 4096, and support can raise it for your organization up to 65536. A raise applies the next time a node starts or wakes, so a stop and start picks it up. Inside the container the live value is readable at /sys/fs/cgroup/pids.max.

Until now an agent could name your storage buckets and pull a prefix out of one, but it could not see what was in them. It had to guess a path and import blind, or ask you to run gman storage ls and paste the answer back.

list_storage_objects is now one of the tools an agent has. It returns the keys under a prefix with their sizes, and with delimiter: "/" it answers one directory at a time instead, folding everything below the next slash into a list of prefixes. A bucket with a million objects in it is a handful of calls to walk that way. Long listings come back a page at a time and say so, so nothing stops short without telling you.

Listing reads the index of the bucket, so it costs no node time and no transfer, and there does not need to be a node running to do it. Uploading, deleting, and creating buckets are unchanged and still yours to do from a terminal or CI. gman storage ls also stopped stopping at the first thousand objects.

Written out under object storage in the docs.

No. Queue them. How much work is queued is one of the inputs that decides how many machines we start, so a queue is not a sign that capacity has run out - it is the thing that makes more of it arrive. A queued node's GPUs count toward the fleet's machine target on the next pass, and a job backlog that persists for a shape raises the same target for that shape.

None of that was written down anywhere an agent would read it, and the result was agents surveying a busy fleet, concluding there was no capacity, and quietly shrinking the work - which withdrew the only signal that would have answered them. So every queued answer now carries demand_note next to the position and the estimate, saying it plainly, and the tools that withdraw a queued entry - cancel_job, delete_node - say it before you do.

The practical version: queued time is free, your place is held (to expires_at for a node, three days by default for a job), and cancelling because a wait looks long makes the next wait longer rather than shorter. Cancel when you no longer want the result. It is a direction rather than a promise - spend ceilings and a quiet market can still mean no machine is coming right this minute, which is what capacity_inbound tells you for your own node - but a queue nobody joins starts nothing.

Written out under waiting for capacity in the docs, and in the manual agents read at /llms.txt.

When the fleet is full, requests wait in a queue, and the queue is not purely first-come-first-served: folks who buy priority are ordered as if they had been waiting a while already. Every account has also always carried a bit of that for its first node - the one you ask for while you are holding nothing - but it was a middling amount, so a big customer expanding their fleet could still be served ahead of somebody starting their first node.

That is now reversed. Your first node carries the largest head start there is, above every paid tier. Nobody can buy their way in front of somebody who holds nothing, so starting work is the fastest thing in the queue and what priority buys is a faster second, tenth, and hundredth node.

Nothing changes about how you ask for a node, and it costs nothing extra. It applies to one request at a time: a second node queued while the first is still waiting waits its turn normally, and once a node of yours is up, further requests are expansion. A queued node tells you which case it is in - it reports the head start it carries, and when it does not carry one, why. A returning owner waking a node they already parked is still served before every new request, at any price.

Events on your audit page (and in the events API and CSV export) now carry the request id and the caller's IP address alongside who acted and from which surface. The columns existed; they were always empty. The request id is the same request-id header the API returns on every response - which now rides every endpoint, not just the /preview API - so an event, a support ticket, and our own logs all point at the same moment with the same key.

Addresses appear on events your own account's people and agents authored. Actions taken by givemeanode staff still show as staff actions without personal detail, as before.

gman storage cp ./icons corpus/icons/
uploading 5254 files (21.4 MiB) to corpus/icons/ - 32 at a time
uploaded 5254/5254 files (21.4 MiB)

Uploading a directory used to walk it one file at a time, and every file cost its own round trip to us before its bytes went anywhere. That made file count, not size, the thing that decided how long an upload took. A folder of five thousand small icons totalling twenty megabytes took hours, while the same twenty megabytes as one archive took seconds.

Now the whole directory is planned up front and uploaded in parallel, so that same folder lands in a couple of minutes. Use --concurrency to change how many files are in flight at once. It defaults to 32 and goes up to 256. Progress prints once per batch instead of once per file, so a big tree no longer buries whatever else your shell is saying.

A file with no bytes in it now uploads like any other, as a zero-byte object. It used to be refused, which was a surprising way for an otherwise fine directory to fail.

Nothing about the objects themselves changed. A directory is still one object per file, listed and downloaded exactly as before, so an upload you already did needs nothing done to it. If an object fails to land, the upload stops and names that file rather than reporting a tree as complete when it is not.

This ships in gman 0.11.0. Run gman upgrade, then gman storage cp --help. Object storage is written out under platform storage in the docs.

A sandbox now has a network. Code running inside one can git clone, pip install, npm install, and call an API, and DNS works. Until today a sandbox had no network device at all, so a task that fetched anything failed with “Network is unreachable” and the only way to get a package in was to bake it. Nothing about your existing sandboxes changes except that the network is there.

Loopback works now too. A server your code starts inside a sandbox is reachable at 127.0.0.1 and at localhost from another command in the same sandbox, which it was not before.

What a sandbox still cannot reach is anything private. Your nodes, your private networks, and this API are all unreachable from inside one, and so is every other sandbox, including your own. That is what keeps a sandbox safe to run code your model wrote in. Each sandbox gets up to a gigabit per second.

If you want the old behavior, you can ask for it. Pass egress: "none" to create_sandbox_env or create_sandbox (or --egress none from the CLI) and the sandbox has no network device at all, so nothing inside it can reach anything. Use that when a rollout has to be hermetic, or when you want code your model wrote to have no way out whatsoever. The choice is made when the env is baked and every fork inherits it, so bake a second env if you want both.

Baking is still the cheaper way to get anything every sample needs. One bake pays for a package install once and every fork inherits it, so a hundred rollouts that all need the same dependencies should not download them a hundred times. Work that pulls a model or a large dataset per sample is slow wherever it runs, and that still belongs on a node or in a batch job with the sandbox grading what comes back.

Three changes to sandbox snapshots, all about keeping them.

Every snapshot now has a durable copy off its host. Until today a snapshot lived only on the machine that made it, so losing that machine lost the snapshot. Now every snapshot is copied off the machine automatically, encrypted, at no extra charge. If the machine dies, your next fork fetches the copy and carries on.

Idle snapshots move to cold storage. A snapshot you have not forked in a while can leave its machine and bill $0.05 per GiB-month in cold storage instead of the $0.10 stored rate. A snapshot bills exactly one of those two rates at a time, never both. The next fork brings it back on its own, and that one response carries rehydrate_ms so you can see what the wait was. Forks after it are fast again, and a snapshot you forked recently never moves.

You can give a snapshot an expiry. Snapshots still live until you delete them by default. Pass expires_after when you bake or snapshot, with a value like "24h" or "7d", or set one later with set_sandbox_snapshot_expiry. At the deadline the snapshot deletes itself exactly as if you had deleted it, and sandboxes already forked from it keep running.

get_sandbox_stats now says which tier each snapshot is in and when it expires, and gman sandbox ls shows the same. The details are in the docs.

Two changes to sandboxes, both about the first thirty seconds of using one.

There is a new default image. sbx-base carries python3 and pip, Node.js 24 and npm, git, curl, and a C compiler, and it is what you get when you create a sandbox without naming an image. Before today the default was bash and coreutils, so an agent harness that checks for a runtime before it starts work found neither python nor node and had nothing to tell you about why. sbx-min and sbx-task are unchanged and still available by name, and naming an image we do not have now lists the ones we do.

Creating a sandbox mostly stops booting one. The first sandbox you create for an image boots it, as before. After that, creating another one of the same image and size forks the snapshot the first one left, which takes tens of milliseconds instead of a couple of seconds. Nothing about it changes what you get: it is your own snapshot, in your own workspace, and the response still names it so you can fork it yourself. The response now also says which happened, in reused_snapshot.

Passing a setup command still boots every time, because the snapshot has to carry your setup. And for more than one sandbox, one create_sandbox_env plus one fork call for all of them is still far better than a create per sample - the round trips cost more than the sandboxes do.

The gman half of this ships in 0.8.1: the new default image, and a gman sandbox create that says whether it booted or forked. Run gman upgrade.

An organization can have a lot of spending limits at once: one on the organization as a whole, one on the workspace new nodes land in, and one on any other workspace you have set a budget for. Until today each of those lived on a different page, and none of the pages named more than one of them. If a limit stopped your work, finding out which one it was, and where to change it, was a puzzle.

There is now a spend limits page. It lists every limit in force, organization cap first, then the workspaces closest to their own limit, with what each has spent this month, what its ceiling is, and how much is left. The share of the ceiling used is drawn on one scale across every row, so the limit about to bite is the longest bar rather than something you work out. You set a workspace limit in place, in the same row you read it in, and clearing the field removes the limit.

The page is built for accounts with a great many workspaces, so it does not try to list them. It ranks the budgets nearest their threshold, finds any one workspace by the start of its name, and counts the rest. Every limit notice we send now links straight to it.

The organization cap is still ours to move: it is shown here with everything else, and you ask us to raise it. Workspace limits are yours, and every change to one is recorded in your audit log.

Every sandbox capability is now a gman subcommand, so a shell script or a CI job runs the same loop your agent runs. You bake an environment once, fork one sandbox per sample, run the batch, and delete it, without hand writing an API call for any of it.

gman sandbox bake --image sbx-task --warm-file ./setup.sh
gman sandbox fork env-1f4c2ab90d3e --count 8
gman sandbox exec --batch rollouts.jsonl
gman sandbox rm sbx-0a1b2c3d4e5f sbx-6a7b8c9d0e1f

The batch shapes survive the trip. One exec call fans a command across every sandbox you name, and --batch reads a file that gives each sandbox its own command when the samples differ by a seed. One rm call deletes the whole fan. Exit codes carry what a script needs to branch on. A single exec exits with the remote command's own code, a fan-out exits zero only when every result exited zero, and rm exits non-zero when any sandbox came back undeleted, because that one is still running and still billing. A result that comes back void, meaning something broke on our side, also exits non-zero and says so, so a script never scores our failure as your model's.

This ships in gman 0.8.0. Run gman upgrade, then gman sandbox --help. The whole loop is written out under sandboxes in the docs.

A sandbox is a small isolated virtual machine that runs shell commands for your agent, and it is now available to every account. You bake your setup into a snapshot once, then fork that snapshot into one sandbox per sample. A fork resumes the snapshot exactly as it was, with its memory, running processes, and warm caches intact, in a few tens of milliseconds, and forking is free. Sixty-four rollouts are one bake, one fork call, one exec call across all sixty-four sandboxes, and sixty-four deletes.

This is the piece our post-training guide used to send you elsewhere for. Code your model wrote can now run and fail next to the GPUs that produced it, on one bill, with no second vendor in the critical path of every rollout. A sandbox has no network at all, which is what makes it safe to run that code in, so everything a run needs arrives in the commands you send and downloads stay on a node or in a job.

You pay for the RAM a sandbox holds, per minute, while it is running. A sandbox that goes a second and a half without a command parks itself: it hands back the memory it is not using, so you stop paying the RAM rate on that and pay a much cheaper per-GiB-month rate on the disk it holds. A park only ever takes spare memory, so processes you left running keep running, and your next command wakes it in tens of milliseconds. There is nothing to call. How much you save depends on how much the sandbox was holding. Forking is free, baking bills as ordinary sandbox time, and a stored snapshot bills per GiB-month of its deduplicated bytes. When a command fails because something broke on our side, the result says so and that time is excluded from your bill in the hour it is recorded, so an infrastructure blip never teaches your model that its answer was wrong. The rates are in the pricing table on the front page, the month to date is the sandboxes line in get_usage, and the loop is written out under sandboxes in the docs.

A batch job can now run an image from a private Docker registry. An org admin stores the pull credential once from their own terminal as a registry connection, and after that jobs name the image the way they always have. We match the image against your connections and authenticate the pull, so no credential goes near the job, the agent, or the chat.

gman connection create acme-images --kind registry \
  --scope 'ghcr.io/acme/*' --username acme-ci --material-stdin < token.txt

The scope is written like the image refs it admits, without a tag. Pin one repository, an owner with ghcr.io/acme/*, or a whole registry with ghcr.io/*. The credential is checked against your registry before it is saved, so a wrong token fails at your terminal instead of hours later inside a queued job. GHCR, Docker Hub, Quay, Harbor, Artifact Registry, and Azure Container Registry all work. Amazon ECR does not, because it only issues tokens that expire after twelve hours. The details are under private images for jobs in the docs.

An agent holding delegated spend authority, a Stripe shared payment token minted against a card its principal controls, can now buy prepaid credit for your org on its own. It posts an amount to /pay/v1/topups with an org service token, receives an HTTP 402 payment challenge, pays it with the token, and the credits are live on the retry of the same request. No card is stored with us, and nobody has to get up to open the billing portal.

For an org that pays by card but has not saved one yet, the first settled machine payment switches billing to prepaid. Work runs against the credit balance, stops when it reaches zero, and resumes when the agent buys more. A refusal for a missing payment method or an exhausted balance now names the endpoint, so an agent with spend authority can cure the refusal and carry on. The full protocol is under machine payments in the docs.

A batch job can now carry a list of tasks instead of doing one thing. Pass tasks when you submit, and your command runs once per machine and asks for work as it goes, leasing tasks from a local endpoint inside the container with no credential to manage. One container start and one image pull cover thousands of tasks, and losing a machine costs the tasks it had in flight rather than a whole shard of the run.

The point is stragglers. Splitting 5,000 prompts across eight jobs by hand ends when the slowest eighth ends, which on work whose items vary tenfold in duration means most of your machines idle while one finishes. With leasing, a machine that finishes a task takes another, so the run ends when the work does. A task that fails is tried up to three times and then recorded with its reason - a failed task never fails the job - and get_job answers with the counts (done, failed, leased, pending), so checking on a run is one call.

We run a set on more than one machine when the backlog warrants it and stop them as it drains, up to a ceiling you set (task_max_runners, 4 by default, up to 32). You still submit one job and watch one job, and you pay job rates for the minutes each machine runs; if we cut a run short, the tasks that were in flight are not billed. If you do not know every task up front, submit with tasks_open, feed the set with add_tasks, and seal_tasks when the list is complete. The task sets section of the docs has the runner loop to drop into your container, and the rules that keep a result from being written twice.

A grant invite travels by email, and some university mail systems quarantine that email without a bounce: the researcher never sees it, nothing reports a failure, and the sponsor is left asking whether it was ever sent. A whole cohort hit exactly that last week.

Each pending invite on your program's page now carries copy claim link. Send the link over any channel you like - the claim is bound to the invited email address, and accepting still requires signing in with that address, so the link claims nothing in anyone else's hands. Revoking the invite still kills it. And invite sends are now fully logged on our side, so “never sent” and “sent but swallowed” are distinguishable the moment you ask us.

copy_file moves a file or directory from one of your running nodes to another in a single call. The nodes do not need to share a private network. Until now the options were re-uploading every file from your agent's own context, relaying archives through the chat, or standing up an ad hoc server between the nodes, and all three were the wrong tool the moment the payload grew past a few files.

A file lands exactly at the destination path you name. A directory's contents land extracted under the destination directory, merged file by file over whatever is already there, so the prepare-edit-copy-again loop just overwrites the files that changed. The call returns as soon as the source has been read, along with a checksum and an artifact id that serves as your durable receipt, and your agent polls get_import on the destination node until the write reports complete.

Stopping a node parks its disk, and waking it can queue behind other wakes when the shape is busy. Until now the only way to learn that queue's price was to attempt the wake: stop, come back later, ask for a file, and discover the estimate says hours. If the parked disk held the only copy of something you needed, the gamble was already taken.

Now every stop_node response, and every check on a stopped node, carries a wake_estimate: the number of wakes already waiting for the same shape, and the measured time-to-ready a wake requested right now would be quoted, with its p90. It reads the queue as it stands - it reserves nothing, and a wake when capacity is free is still near-immediate - but the tradeoff is visible when you park the disk, not first when you ask for it back. When the number is long and the files matter, keep a durable copy instead: snapshot the node, or export the results before stopping.

Your agent can now answer that by reading instead of guessing. From inside any node or job container, the metadata service serves the network policy:

curl -s -H 'Metadata-Flavor: givemeanode' http://169.254.42.1/v1/egress

The default is open internet. The response lists the few blocked destinations, which are outbound SMTP on port 25, a handful of mining pool ports, and the cloud metadata IP. The blocked ports fail fast with a connection error. The metadata IP is dropped silently, so a connect to it hangs.

The response also states what the policy never does. DNS is unfiltered and TLS is never intercepted. So when a download fails with a certificate error or a name that will not resolve, the origin is the problem, and the fastest fix is a mirror. Your agent can read the boundary up front instead of discovering it one failed download at a time.

The CPU-only nodes have always had names you could say out loud, cpu-2 and cpu-8. The GPU nodes had a spelling rule instead. Now they have names too. h100-1 is one H100 and h100-8 is a whole eight-GPU machine, and you can pass either name as chip anywhere you ask for a node.

The pricing table on the front page is now a list of those names, one row per type. What each type actually comes with, meaning the GPUs, the cores, and the RAM, is on the docs page under what a node gets.

Nothing you run today needs to change. h100 and 8xh100 still work everywhere, and they are still what the API sends back.

A sample declares what it is, and the mission page has always promised to show it that way. Images did. Audio, video, text, and json got a download link, which is a strange thing to hand someone who is watching a run.

Now every kind renders. Video plays in the grid at its own shape, audio plays in a strip you can scrub, and text and json are readable where they sit, indented if they parse, with the whole file one click away when there is more than the tile shows. Nothing else about samples changed. Your job declares them the same way, and the same 64 MiB and 256 capture limits apply.

If a sample cannot be shown, the tile says so and offers the download. That covers a link that has gone stale, which refreshes on its own, and a video in a container your browser will not play.

Machines retire on a schedule, and a node on one has a deadline. Until now the only way to hear about it was to be attached to a live session, where a countdown appeared in the terminal, or to read the deadline from inside the container. An agent working through the tools, which is most long runs, found out when the node stopped.

get_node now carries machine_retires_at as soon as a retirement is scheduled, which is normally hours ahead, together with a note saying what happens to the node at that moment and how to keep your files. Stopped nodes carry it too, because a parked disk goes away with its machine exactly like a running node's does. This is the field to poll for on a long unattended run.

The note tells you which of two things happens, because that depends on the machine. Some hosts upload your parked disk before they go, and the note says the next command restores your node from that copy. On the rest the disk does not survive, so the note points you at writing your results out or at stopping the node and snapshotting it before the deadline.

Money you put into a grant program's escrow could only go one way: out to the researchers you invited. A program that ended with money left over, or one you funded generously before the cohort came in smaller, held that money until someone asked us to move it.

The program page now has Withdraw to credit beside the funding controls. It moves escrow back to your organization's credit balance, where it pays your own bills or funds another program. Nothing is charged and nothing is refunded: the money was already ours to hold for you, and now it is ordinary credit that expires a year from the day you withdraw it. Closed programs can be withdrawn from too, which is usually when you want to.

One thing stays put. Invites that are still out keep the money reserved behind them, so you can only withdraw what is available - a researcher who is holding a claim link will always find the grant there when they accept it.

Nodes now come in two CPU-only sizes. A cpu-2 gives you 2 reserved physical cores and 8 GiB of RAM. A cpu-8 gives you 8 reserved physical cores on one NUMA node and 32 GiB of RAM, for parallel CPU work. The cores are exclusively yours, with hyperthread siblings kept idle rather than sold to a neighbor, and neither shape ever has a GPU.

Everything else works like the node you already know. The disk is persistent and encrypted, stopping parks it with files intact, the next command wakes it, and snapshots and contexts move data to and from your GPU nodes. Downloads, ingest, and preprocessing are the work these are for. That work is bounded by the origin and the disk rather than by cores, so you stop paying GPU rates to run curl.

A CPU node may be placed far from your GPU nodes, in a different region, so move data with snapshots and contexts rather than assuming a LAN. Rates are on the front page, and every create_node response quotes the locked rate before billing starts.

Checking a stopped node used to answer stopped (disk intact) and nothing more, leaving your agent to guess whether the idle window ran out, someone stopped it, a spend cap hit, or the container died. Now the same check carries a stopped section: reason (a stable token like idle_grace_expired), at, a note naming the cause and the next move, and ran_seconds, how long that session billed from ready to the stop.

The case that prompted this: a queued node arrives while your agent is busy elsewhere, sits through its idle window unused, and auto-stops at the session minimum. That outcome is now legible in one call - the reason says the grace expired with no command landed, and ran_seconds shows the session was exactly the minimum. The same section covers every other ending too, including stops you did not initiate.

Saving a setting, inviting a teammate, funding a program, or buying credits used to look like nothing had happened: the button sat there unchanged for as long as the change took, and the page eventually refreshed. On a slow one it was reasonable to think the press had missed, press again, and send the change twice.

Every button that changes something now says so while it runs - “Saving…”, “Sending…”, “Charging…” - and refuses further presses until the answer lands, so a second press cannot become a second change. When the page comes back, it tells you what it did, which matters most for the changes that leave the page looking exactly as it was: a saved role, a saved spend cap, a switched organization.

Asking for a job's run log while the job was still building its image or starting its container used to answer with the message meant for an attempt that had died before running - “never ran, has no log and never will, stop polling” - about a perfectly healthy job. An agent taking that at face value would cancel and resubmit, and pay for a duplicate.

The read now answers attempt_state: not_started when the job simply has not reached running yet, says where the job actually is (building, queued, or starting) and to keep polling, and keeps eof false because output is still coming. never_ran now only ever describes an attempt that is genuinely over, so when you do see it, you can trust it.

A grant program's escrow could only be filled by charging the card on file. If you had already paid us - a wire, a contract invoice, credit we issued against a payment - that money was sitting in your balance and the only way to start a program was to pay a second time.

The programs page now offers Fund from credit beside the card button, whenever your balance holds credit a program can use. It moves the money from your balance into the program's escrow and charges nothing, in any amount your balance covers - a $100,000 prepayment funds a $100,000 program in one press. Organizations billed by invoice, which had no self-serve way to fund a program at all, can now run one.

Two rules bound it, and the page says both. Credit that is covering usage you have not been invoiced for yet is not fundable, so funding a program can never turn into a surprise charge or stop your own nodes. And only credit you paid for or that was issued against a payment can fund a program: promotional credit, referral earnings, and credit from a program that supports you stay where they are.

A job's run-log read now tells you what state that attempt is in, so a polling loop knows when to stop. attempt_state is live while the attempt is executing, complete once it has ended and the stored output is everything there will ever be, and never_ran for an attempt that ended before its container started. eof becomes true once a read reaches the end of a stream that nothing is still writing.

The never_ran case is the one worth knowing about. When a job is preempted and requeued, an attempt can fail during startup and never execute at all. Reading that attempt's log used to give you an empty response that looked exactly like a running attempt which had not printed anything yet, so an agent following the cursor could poll it forever. Now the read says the attempt never ran and says why, and the cursor holds still instead of drifting. An attempt that never ran has no log, and asking for its number never returns some other attempt's output.

Every page of the dashboard, the landing page, and the changelog now fit a phone screen. Before this, most signed-in pages ran wider than the viewport and you had to scroll sideways to read a page you had just opened; the changelog was almost twice the width of the screen.

Tables come with it. A ledger that cannot fit its columns on a narrow screen now holds back the ones you do not scan first, such as a creation timestamp or a workspace slug, so the node name, the state, and the money stay readable; the full table returns as soon as the screen is wide enough, and the CSV export was always complete. Long identifiers and email addresses wrap instead of forcing the page sideways, and the navigation rail's rows are big enough to hit with a thumb.

Nothing moved on a desktop screen.

Restoring a node from a snapshot used to choose the image the way an empty create does: the catalog default unless you named one. A volume prepared on a PyTorch image could restore onto the plain CUDA default with every file intact and every import broken, because virtualenvs and compiled packages depend on the image they were built under. The node reported running, the disk reported intact, and nothing said why Python could no longer find torch.

A restore that names no image now runs the image its snapshot was taken on, so the environment comes back working. Naming a different image still works, and the response now says plainly that packages built on the original image may fail to import, instead of leaving you to discover it at import time. list_snapshots also shows each snapshot's image, including for snapshots taken before today.

Your agent, the CLI, and the dashboard now render the same words for the same node. The dashboard used to print raw internal state names - idle_grace where every other surface said running (idle) - and its “Active nodes” tile counted queued and provisioning nodes, which are free, as if they were costing money. The tile now counts only nodes actually billing (running or idling on the grace window), with waiting nodes shown separately as what they are: free until ready. The dashboard's stop button also works on a node stuck waking or restoring - it used to claim success and do nothing, while the same abort worked over MCP.

Billing got one honesty fix in the same pass: an idle node's meter now closes at its grace deadline exactly. It used to close when our sweeper noticed the deadline had passed, which billed you for our lag - usually seconds, but they were our seconds, not yours.

Queue wait estimates were sometimes off by 10x, in both directions, and we traced both. For nodes, a burst of placements (one freed machine serving many waiters at once) read as a fast queue, quoting seconds for waits of hours; estimates now measure over the period the queue was actually served through, never quote less than what recent waiters actually experienced, and answer null (unknown) rather than extrapolate from a single data point. For jobs, the estimate divided worst-case queue backlog by actual delivered minutes - so generous max_duration ceilings inflated the quote by exactly their slack - and a fully busy fleet could quote “1 second” to the head of the queue because busy GPUs were counted as free capacity. Both sides of that division now use the same units, and a full fleet quotes the measured rhythm of jobs actually finishing. Null still means unknown, not long: when there is no evidence, we say so instead of guessing.

Very rarely, a GPU drops off a host mid-run - the device simply vanishes and CUDA calls start failing with no explanation. Until now the platform noticed the missing GPU but told no one: new work quietly avoided the device and your run was left to discover the loss on its own.

Now the moment a host reports fewer healthy GPUs than it should have, everyone who needs to know hears about it. If you have a live session on the node, a notice line tells you a GPU was lost and suggests checkpointing what you can. get_node reports it under host_gpu_health, so a polling agent sees it too. Our operators are paged, and if customers are affected the status page says so.

We also fixed the most common cause. GPU hosts now boot with the driver's power-saving teardown disabled (persistence mode on, and PCIe power management off for the GPU links) - a well-known reason GPUs fall off the bus in the first place. Fewer disappearing GPUs, and no silence when one disappears anyway.

Our rates are quoted per GPU, so a full 8-GPU node bills eight times the per-GPU figure. Several places showed the per-GPU number without saying so. The CLI answered a create with “rate $0.06/min” for a node that bills $0.48/min, and the usage page did the same in its per-node rows. Every surface now leads with what the whole node costs. Node responses carry both numbers: rate.node_per_min is your node's rate, and rate.per_min is the per-GPU rate behind it. On the usage page, hours times rate now matches what a row was charged, and the current-rates table lists 1x and 8x shapes separately.

One heads-up if you script against the usage CSV: the rate_per_min column is now node_rate_per_min, renamed together with the unit change so a parser looking for the old column fails loudly instead of quietly reading node rates as per-GPU ones.

The dashboard's credit balance also stopped lagging. Credits settle against your balance when an invoice is issued, and the tile used to show the raw balance, which meant days of spend could pass without the number moving. It now shows the same “available to spend” figure as the usage page, with the subtraction spelled out underneath, so the two pages always tell the same story.

A synchronous run_command takes a timeout budget, and over MCP we used to accept anything up to 300 seconds. But agent harnesses enforce a deadline of their own on every tool call, commonly 60 seconds, and nothing streams back until the command finishes. So a 90 second budget was accepted, the command ran and completed on the node, and the call still died in your agent as a timeout that lost all the output. It read like a slow or wedged node; the truth was a budget that could never be delivered.

run_command over MCP now refuses budgets above 60 seconds at call time, before anything runs, and the refusal says what to do instead: run it detached (detach: true) and poll get_command, which has no deadline at all. The HTTP API (POST /preview/nodes/{name}/commands) still honors up to 300 seconds; a shell holding a curl has no such deadline.

The dashboard has a settings page. Connecting Hugging Face, switching sponsor programs on or off, and your sign-in policy (single sign-on, verified domains, and their two switches) were scattered across the team page; they now live together under Settings in the sidebar. The team page keeps what it was about all along: members and their roles, invites, workspaces and their spend caps, running nodes, and service tokens.

Every control is the same one it was, behind the same permissions, and changes land in your audit log as before. There is nothing to reconfigure - the controls simply have one address now.

export_data could already push a file or a directory from a running node into your own S3 bucket or a Hugging Face repo. It now takes your givemeanode storage buckets as a destination too. Give it an object key and the bytes land as one object, the same way the S3 destination works. Give it a prefix ending in a slash and a directory lands as a mirrored tree of objects, one per file, so you can list and fetch a single file instead of unpacking a tar to find it.

A tree export commits objects as they land and reports how many files are done out of how many total, so a long push shows its progress instead of going quiet. Re-running one resumes rather than starting over. Objects already there with a matching size are skipped and never sent a second time.

Batch jobs got the same destination. output_to now accepts a storage/<bucket> connection, so a generation sweep can write straight into your dataset bucket, and no credential ever reaches your container. Bytes you land count against your storage quota and bill as stored bytes.

A long training run can leave thousands of samples behind, and the mission page's Samples tab now keeps up. Samples tile edge to edge in a dense grid, newest first, and the page keeps loading older ones as you scroll - no button to press.

When you stop a node, its files stay parked on the machine it ran on, and waking needs GPUs on that same machine. If other work held that machine, your wake could wait indefinitely while identical GPUs sat free elsewhere. Now a wake that stays stuck for about twenty minutes stops waiting for that one machine: your files move to durable storage in the background, and the same queue entry (your place in line is kept) starts the node on the first machine with the GPUs free, restoring your files onto it. The restore makes that one wake slower, and it is disclosed as it happens; the wait for a machine is never billed, and your files are intact either way. If the original machine frees up before the move completes, you land there instantly, exactly as before.

The usage page used to lead with your credit balance. That is rarely the number people are looking for. If your account runs on credits, the page now leads with what is available to spend and shows the arithmetic instead of leaving you to do it. An $815 credit balance with $118.31 of usage that has not settled yet reads as $696.69 available, with that sentence printed under the figure. Usage settles against your credits when your invoice is issued, and anything past your credits is charged to your card.

The month figure is now a complete receipt. It sums every stream your invoice bills, which means node minutes, job attempts, build minutes, snapshot storage, and observability, and it itemizes the nonzero lines above the total. The tables further down the page now visibly add up to the headline above them. The old month figure left out job, build, and observability spend, so it could disagree with your own invoice.

Charges round to whole cents everywhere on the page, while rates keep their full precision, because a rate really is a five-decimal number and a charge is measured in cents. The CSV export still carries exact amounts for reconciliation. The mission table columns now say what they actually measure, and a note under Current rates explains that a node's rate is locked when it is created, so a row above can show an older rate than the table after a price change.

A job whose image we have already built, which is what a resubmit with new settings or the next variant of a sweep is, now starts in a few seconds. In our measurements the time from submit to running dropped from a median of about 18 seconds to about 7 for those jobs, and jobs that do build an image start sooner after the build finishes too.

Three changes add up to it. Every stage of a job's path to running now begins the moment the stage before it finishes, where each handoff used to wait for the next periodic sweep. A machine that already holds your job's image skips downloading it again, and when machines are otherwise equally good we now place the job on one that has it. And machines fetch the images of jobs waiting in the queue ahead of time, so when a job's turn comes its image is often already where it needs to be.

There is nothing to change on your side, and the billing rules are what they were. Queued time is still free, and the meter still starts only when your job runs. The seconds this removes were seconds you were waiting, never seconds you were paying for.

A running job can now append small evidence files - a sample grid, an audio clip, a text dump - to its mission's timeline, and the new Samples tab on the mission page shows them over time, newest first, images rendered right in the grid. Your agent picks what to save and how it should be viewed; you just open the mission and look.

Samples are a peek at progress, not the output path: your results still arrive the usual ways. Each job can save up to 256 samples of up to 64 MiB each, they stay viewable for 30 days, and your agent can pull any of them back down with fresh download links at any time.

Exposing a port opens a public door. A private network is the other direction, where your own nodes reach each other over stable private addresses with nothing of it visible from the internet. Name a network when you create a node and you are done. A network that does not exist yet is created for you, so the common case is one flag. Existing nodes join a running network in seconds with no restart, and leave it just as live.

Names work inside a network. From one member, worker1 resolves to that peer's addresses, so you can write MASTER_ADDR=head and mean it. If you would rather discover peers than hard-code them, the metadata service inside the node serves the whole roster in one curl.

The addresses are stable for the node's whole life. A member keeps its IPv4 and IPv6 across stop and wake, across recreate, and across repair, so a config that names a peer stays correct. A stopped member keeps its place in the network and drops traffic until you wake it. Traffic from a peer never wakes a node, because a wake is always an explicit command you pay for.

One network is one trust zone. Every port a member listens on is reachable by every other member, and there are no per-port rules inside a network, so joining one is trusting the nodes already in it. That is the whole security model, and it is why membership is opt-in for each node. A node you never attach keeps exactly the isolation it has today. Members get no internet transit through each other and no route into another network, and nothing on a private network is reachable from the public internet. Exposing a port remains the only public door.

Networks are free. Deleting one needs it empty, and an address that has been detached sits in a seven-day quarantine before it can belong to anything else, so stale peers and copied configs get time to drain before an address changes meaning.

Signing in now lands you on a page that answers the three questions you came with, in one row at the top: what you have left to spend, what this month has cost so far (with last month beside it for scale), and how many of your nodes are live right now. Your credit or grant balance keeps the same figure and label as the usage page, so the two never tell different stories.

Everything the page already did is still there below: the node list with its stop buttons, your recent missions, and the payment-method prompt when one is actually needed. The sidebar entry is now called Home.

A node that arrives while you are thinking now tells you its deadline. While a node idles unclaimed, its status reads running (idle) with a new idle_stops_at timestamp: the moment it stops unless a command lands first. That window - 15 minutes on 1x shapes, 20 on 8x - is quoted on every response, and its cost with it (session_minimum_usd), including while you are still queued. On 8x shapes the quote previously said 15 minutes when the real window was 20; it now always matches what actually happens. The docs spell out the two clocks of a wait, and the poll cadence they imply: anything comfortably inside the grace window catches your node. No thirty-second loop needed.

And the loop does not have to live in your agent at all. The same status is one curl on the HTTP API, so a shell script or CI step can hold the wait with a service token - gman node create --wait is that loop prepackaged, and it now exits 0 the moment your node is ready (it used to misread a fresh, idling node as a failure).

Nodes and jobs now start with PIP_INDEX_URL and UV_DEFAULT_INDEX pointing at a pull-through mirror of the Python Package Index running on the machine itself. It serves the same public packages, so most installs simply get faster, and they keep working when the route out to the public index is congested. There is nothing to turn on.

If you use your own package index, set PIP_INDEX_URL yourself, either in your environment or on the pip command line, and your choice always wins. If you would rather we did not set it at all, tell us and we will turn the steering off for your workspace.

Image generation is now a first-class workload. The pytorch-2.13-cuda12.9 image carries torchvision, ffmpeg, and libgl1 alongside the torch stack, so diffusers pipelines, ComfyUI, and anything that imports cv2 work without setup time coming out of your billed minutes. Base checkpoints ride the shared model cache, so a sweep pulls an SDXL-class or Flux-class base once per machine instead of once per job.

Community models and LoRA adapters published on Civitai now import like any other private data. An admin creates a civitai connection once, optionally pinned to specific model or version ids, and from then on your agent pulls adapters by naming those same ids. The token never appears in the chat, in the agent, or on the node. gman 0.7.9 carries the new connection kind.

The docs gained a guide that walks the whole loop. It covers where adapters come from and how to carry a library of them into a sweep, how to land every variant's images in your own bucket, how to check a sample grid mid-run and cancel a batch whose settings are wrong, and how to run ComfyUI interactively on a node.

If your account holds unspent compute-grant credit, the dashboard no longer opens with a banner asking you to add a payment method. Your balance and who supports you are the standing that matters there, and that line stays. The banner returns if the grant runs out or ends.

One rule is unchanged: an organization billed by card still needs a payment method on file before nodes can start, even while grant credits would pay the bill. If that applies to you, node creation says so at the moment you try, with the link to fix it - grant credits are always spent before the card either way.

The catalog gains pytorch-2.13-robotics-cuda12.9: torch plus the video and vision toolchain robot-learning stacks load at import (ffmpeg, torchcodec, OpenCV, the headless EGL and Vulkan loaders), present before your first command instead of installed on billed time. The docs gain a robot learning section covering images, datasets, fine-tunes, evals, and serving a policy to a real robot.

Three batch-job limits that were fixed platform knobs are now ordinary limits with per-organization overrides: checkpoint_slot_bytes (default 50 GiB), job_scratch_bytes (default 100 GiB), and job_max_duration_ceiling_minutes (default 12 hours). If a fine-tune needs a bigger checkpoint slot or a longer run, ask - list_limits shows your organization's effective values.

A running job can now show you its work before it finishes. Your process writes something small and lookable into $GMN_OUTPUT_DIR, a sample grid or a metrics file, and declares it with one credential-free call to POST /v1/preview on the in-container metadata service. get_job then carries the peek back with a download link. Look at it and decide whether to keep going, resubmit with new settings, or cancel_job now and pay only for the minutes that taught you something. Until now the first artifact arrived when the attempt ended, so a 2,000-image batch whose LoRA strength was wrong at image 50 cost its full duration instead of minutes.

Each job has one preview slot, and a new capture replaces the last, up to 1 GiB per capture. Previews are free, and the download stays available for 30 days after the last capture, including after the job ends. The preview names the attempt that took it, so after a preemption you are never judging the current attempt by an earlier one's peek. A capture that fails reports its reason on get_job, and the run keeps going either way. The real outputs still arrive the usual ways, through the attempt-end capture and output_to. The docs have the four-line version to drop into a training or generation script.

Set hf_cache: true on a batch job (or once in a sweep's shared settings) and the job runs with HF_HUB_CACHE pointing at a cache shared by your organization's jobs on the same machine. The first job on each machine downloads the weights; the rest load them from local disk. You pay for job time as usual, so the minutes that used to go to repeat downloads simply come off the bill.

The cache belongs to your organization alone, is encrypted at rest, and is bounded per machine (100 GiB by default). It is best-effort by design: when a machine runs low on disk the coldest caches are cleared first, and a cold cache just downloads as usual. Jobs that do not set the flag are unchanged - they still leave nothing behind.

If your account runs on credits or a compute grant, the usage page now leads with the number you actually check: how much is left. Grant accounts also see who supports them and when the grant expires, plus a usage meter under the figure when the whole balance is a single grant. For a grant account with no card on file, the page quotes the same figure node creation checks against - one number, both places. The dashboard shows the same standing in one line, next to your nodes.

Also fixed: accounts whose compute grant created a new organization for it saw an “add a payment method” banner on the dashboard. Nodes on such an account start without a card - the banner was wrong there, and it is gone. Invoice-billed organizations saw the same wrong banner; same fix. A grant accepted into an existing organization keeps that organization's own billing - a card-billed organization still needs its payment method before nodes start, the dashboard now explains that your grant credits are spent before the card, and the consent page says all of this up front.

The catalog now spans CUDA 12.4 through 13.3, with PyTorch 2.13 variants on the current toolkits and a pinned vllm-0.26-cuda12.9 for serving. The default moved from cuda-12.4 (March 2024) to cuda-12.9: a node that names no image now gets a toolkit current inference wheels compile against.

The reason, plainly: recent flashinfer wheels reference CUDA headers newer than 12.4 carried, so on a hybrid or linear-attention model vLLM's JIT died in nvcc before the first token - after megabytes of log that looked like your install was broken. Every image except the legacy 12.4 lineage is now checked for exactly those symbols at build time, so a too-old toolkit cannot reach the catalog. Existing nodes keep the image they were created with, as always; this changes what new ones get.

Adding an image is a one-line change on our side now, so if the version you need is not there, ask for it. Note that the newest entries need newer host drivers and so run on a narrower slice of the fleet - if a node on cuda-13.3 queues longer than you like, the default places anywhere.

Three changes so a session that has already waited keeps what it waited for. A wake is served before a new create: coming back to a node you already own is not the same as asking for a new one, so a stopped node waking up sorts ahead of the create queue rather than behind every allocation filed since. It is FIFO within each class, and it draws no line between customers - only between re-attaching to something you own and acquiring something new.

A re-queue keeps the place it already waited for. When a queued hold lapses, re-calling create_node with the same name and shape within 15 minutes now inherits the original position instead of starting from the back. That was the sharp bug: an agent renewing its hold correctly went to the end of the line every time, so on a contended shape it never arrived. Deleting a node still starts fresh - deleting is not waiting.

And max_wait now goes up to 12 hours (was 1). A long wait can be one patient hold rather than a polling loop that re-enters the queue every hour. Queued nodes hold no GPUs and cost nothing, and re-calling create_node with a longer max_wait extends an existing hold, forward-only - a shorter re-ask never cuts one short. gman 0.7.7 carries the new ceiling.

An agent's rhythm is bursty: run for twenty minutes, spend ten reading the output and composing the next step, burst again. Every one of those gaps looked like abandonment to the idle timer, and the 8x window was the shortest in the book (10 minutes) sitting on the shape with the longest queue - so it punished thinking exactly where losing the node costs the most. Waking a parked 8x disk needs its whole machine free again, which on a scarce shape is hours, not a cold start. The window is now 20 minutes.

The grace window is billed - it is the per-session minimum - so this raises the 8x minimum from $4.80 to $9.60 at list. Every create_node response quotes that number as session_minimum_usd before you commit, and stop_node (or an in-container self-stop) still ends the tail early when your workload knows it is done. The 1x window stays at 15 minutes: a 1x wake needs one slot, not a whole machine.

When your agent files a ticket, you can now read the thread yourself. /tickets lists your org's tickets, newest activity first, with a filter row by status and a mark on any thread carrying a reply from us you have not read. Open one and you get the whole conversation oldest-first, what the filing pointed at, where it stands and whose move it is - plus a box to reply, and a button to close it when you are satisfied.

Until now a ticket was an id in an email and an instruction to ask your agent for the thread, which is no answer for the person on the account. Every notification email now links straight to the ticket, and the sidebar carries an unread count. Filing is still file_ticket through your agent, and reading a thread on the web marks it read for get_ticket too - one conversation, two doors.

Fixed: CompleteMultipartUpload assembles and promotes your parts server-side before it answers, and on a multi-GB object that could take longer than S3 clients wait - so the SDK timed out, retried, and hit the same wall again. Now, like S3 itself, we hold the connection open and deliver the outcome, success or an error, in the body of a 200, which is exactly what the AWS SDKs expect. There is no client timeout to raise.

If the connection does drop before the answer arrives, that Complete is cancelled wherever it had got to, so it may or may not have committed - HeadObject the key to find out. Your parts are still there either way, and re-issuing the Complete assembles them again.

Nodes can now carry an ephemeral scratch disk: ask for scratch_gib when the node is created and fast local disk is mounted at /scratch, destroyed when the node stops and never snapshotted. It is for bytes you can re-derive at will - streaming-dataset shard caches, Hugging Face hub caches, decompressed archives - never the only copy of anything. Until now those bytes had to live on the persistent volume, paying for a survival contract that is pure waste on data you would rather re-stream.

Scratch is free: you pay only node time, and the space is claimed up front, so it cannot vanish under you mid-run. The size is set once at creation and immutable, like clock_lock. You get up to 250 GiB by default, and support can raise it for your org (list_limits shows your number). A large ask narrows placement to machines with that much disk free right now; when none has it, the refusal names the numbers. And when a stop clears the disk, the stop's note says /scratch was cleared, so nothing disappears silently.

A customer asked for “a view only terminal - I am able to see the things that claude is doing in machine terminal.” That is now a tab. Every mission's page has Commands: a live feed of the commands your agent runs on the mission's nodes - the command line itself, which node, when it started and finished, and how it exited - updating as it happens. Logs already showed the output; this is the intent half, and together they read like a terminal you can watch but not touch. View-only is the point: there is no input path, so watching can never become steering.

The feed shows work your agent attributes to a mission, from today forward - commands that predate the tab were deliberately never recorded. Anyone in your org with access to the mission's workspace can watch; command lines still never echo back over MCP, so they cannot compound into an agent's transcript. And since a command line is now something your teammates can read, the rule the platform already teaches matters twice: secrets ride env, never the command string. Env values never appear anywhere, names only.

Ask for a whole machine with profiling: true (CLI: gman node create --chip 8xh100 --profiling) and the GPU performance counters a profiler needs are open on it: ncu reads occupancy, memory throughput and stall reasons on your own kernels, in your own container, with nothing to configure. Jobs take the same flag, so a kernel sweep can profile every variant it tries. It is free - you pay in shape, not in a surcharge.

Counters are whole-machine only, deliberately: they can report on whatever else is sharing those GPUs, so on a shared machine they are never for sale - on a machine that is entirely yours they can only tell you about yourself. Ask for profiling on a single-GPU shape and you get a refusal that names the fix instead of a node that quietly cannot profile.

The other half is the profiler itself, and we stopped leaving it to chance. A node created with profiling: true and no image named now lands on an image whose ncu is new enough to work on current drivers - the plain default's is not, and it fails with an opaque “failed to prepare kernel for profiling” that no unlocked machine can fix. Name an image that cannot profile and the request is refused rather than silently swapped, and when a snapshot restore is what pulled the newer toolchain in, the reply says so out loud. Jobs run your image, so bring your own: base on CUDA 12.9 or newer, or install cuda-nsight-compute.

Profiling-capable machines are a small pool today, so a profiling request may wait for one - the queue tells you that rather than failing. Pair it with clock_lock when you are comparing timings across runs; kernel-search work usually wants both.

Your agent can now answer from a table instead of a refusal: list_limits (CLI: gman limits, REST: GET /limits) returns every limit's effective value for you in your org - node counts, object sizes, storage footprint, job knobs, all the numbers the refusal messages quote - with one line on what each bounds, whether support can change it for your org, and whether your org already carries an adjusted value. Plan the 40-node sweep or the 12 GB upload before hitting the wall, not after.

Fixed: a multipart upload whose parts totaled more than 5 GiB used to upload every part and then fail at CompleteMultipartUpload. The commit now assembles and promotes objects of any size (bounded by your org's storage footprint, not a per-object cap), and a Complete whose response you lost is safe to retry - it converges on the assembled object instead of erroring. One PUT and one part still cap at 5 GiB each; every S3 client handles that automatically.

A node that is materializing a snapshot, whether it is waking with its disk or being cloned from one, now reports what it is doing. get_node carries a restore_progress field with the phase it is in - waiting for its turn, downloading, extracting - and the bytes moved so far, straight from the machine doing the work. Waiting behind other restores reads differently from downloading, and both read differently from wedged: a restore with no recent report from its host says exactly that, rather than showing nothing at all.

And you can end one yourself. stop_node now aborts a restore or a wake in flight and parks the disk, files intact, and the next run_command starts a fresh attempt. Until now a wedged restore had no customer-side exit: stopping and deleting both refused while the node was provisioning, so the only ways out were waiting or asking us. Provisioning has never been billed, so an abort costs nothing but the time already spent.

The same release stops a sick machine from hiding. If the host your node is running on is failing our own container GPU health check, get_node says so and names the move - stop_node, then run_command, which starts your container fresh. New work is already steered away from a machine in that state; this is for the session that was already there.

A job that has committed a checkpoint can now end its own attempt and get it back: POST /v1/yield on the in-container metadata service stops the attempt with the same contractual shutdown a planned interruption gets, requeues the job without touching its restart budget, and restores the slot into $GMN_CHECKPOINT_DIR before the next attempt starts. Print a hash before yielding, verify it on resume, and the byte-identical proof is in your own logs - the supported way to qualify restoration before a long run depends on it.

The economics are stated plainly: a yielded attempt bills its full span to the kill - a yield buys a restore, never a discount - and yields are budgeted (two per job) and refused without a committed capture, so the interruption-recovery machinery cannot be farmed. Attempts we interrupt keep billing only to your last checkpoint, exactly as before.

Jobs take a destination now: pass output_to with one of your write-enabled connections and a prefix, and what a job writes to its output directory is captured to your own storage instead of coming back as a download link from us. Each attempt lands at <prefix><job id>-<attempt>.tar, so a 256-variant sweep becomes one folder of results that cannot collide, and a requeued attempt cannot overwrite the one before it. A sweep names the destination once, for the whole batch, not once per variant.

The credential is never on the job. We resolve the connection when the output is captured, which can be hours after you submitted: a key you rotate in between simply works, and one you revoke fails the capture honestly rather than holding a stale secret. If the connection is read-only or the prefix falls outside what it is scoped to, the whole batch is refused at submit and told why. Today the destination is an S3-compatible connection (AWS, R2, MinIO and friends); leave output_to off and jobs return download links exactly as before.

One organization can now have 64 job GPUs running at once, up from 16, and queued jobs are allowed to fill more of the fleet before the scheduler holds any back. A 40-run sweep that used to trickle through two machines' worth of GPUs at a time now spreads across eight, so the morning table arrives a lot sooner.

Nothing about the bargain changes. Waiting in the queue is still free, your spend limit and workspace caps still bound what the sweep can cost, and asking for a node still outranks batch work: a job can be stopped to hand its GPUs to an interactive request, and a job that checkpoints picks up where it left off. If your queue is long enough to hit the new ceiling, get_job still tells you your position and the wait.

If your organization runs several workspaces, the sidebar now has a picker for them. Choose one and the workspace-scoped views - your nodes, your missions - show only that workspace's work; the default, “all workspaces,” is every workspace you can see. A long list is searchable, so a lab with thirty of them is one keystroke away from the one that matters.

The choice is a view, not a mode. It lives in your browser alone, so it changes nothing for your teammates and nothing about what work bills to, which caps apply, or where a new node lands. If the workspace you picked is renamed, or your access to it changes, pages quietly fall back to showing everything instead of dead-ending on a name that no longer resolves.

An image build gets 30 minutes by default, which is plenty for almost everything and not enough for a few real cases: a large dependency tree pulled from a slow or flaky upstream, or heavy ahead-of-time compilation. You can now say so. submit_job and submit_jobs take build_timeout_minutes, anything up to two hours, and the terminal has gman job submit --build-timeout 45m. Until now the 30 minutes was fixed, so a build that ran out of time was told to raise a limit that nobody could raise.

You are billed for metered build time only; queued and idle time never counts, so a longer ceiling costs nothing unless a build actually uses it. The timeout is fixed when you submit, like the rest of a job's build settings, and a build with a raised ceiling now runs to its own deadline rather than the default one.

Connecting your Hugging Face account used to be a terminal errand for an admin. Now it is a button: the Connections section of your team page offers it, and so does the wizard on your way in. You approve it once on Hugging Face's own site and come back connected. There is no token to create, copy, or paste, and we hold no secret afterwards - access is minted fresh for each use, and every use is recorded in your audit log.

You choose the grant while you are approving it. Pull models only, or pull models and push checkpoints back; and, if you want, a list of repositories it is allowed to touch, like my-org/*. Leave that empty and the connection reaches whatever the grant reaches. The team page then shows what you granted, in those terms, and lets an admin disconnect it. Connections made from the command line stay managed from the command line, and the page says which is which.

The spend limit you set when you signed up, the hard monthly ceiling on what your account can spend, now lives on /billing too, next to everything else about your money. See the current number, change it, or remove it; a new value takes effect within about a minute. Nodes still stop before the limit is crossed, files kept, nothing deleted.

It is the same limit the onboarding wizard sets and the team page edits per workspace: one number, three doors, no way for them to disagree.

Same object, new name: the named grouping that collects the nodes, jobs, and artifacts behind one question, with its cost, verdict, and outputs on one page, is now a mission. Every mission you already opened keeps its name, its history, and its page; only the word changed. “Project” means a dozen things across dev tools; a mission is what you actually hand an agent: a bounded question, opened, worked, and finished with an answer.

Nothing breaks today: old links redirect permanently, and agents calling the old tool names or passing project: keep working until August 29, 2026; each such call answers with a note saying what to call it now. Agents pick up the new names automatically the next time they connect. If you export usage.csv, the project column is now mission, and dashboards querying the project telemetry label should switch to mission (series recorded before today keep the old label).

A job that never declared checkpointing only starts on a machine whose remaining reserved time covers its whole run - that rule protects the run from being cut off with nothing saved. Until now, the wait message named the gap (“needs 12h30m contiguous; longest available 8h”) but not the way out. It now does: if your command can resume from $GMN_CHECKPOINT_DIR, resubmit with resume: "checkpoint" and the job may start in any window of about an hour and a half - when the window closes, it is stopped on purpose and resumed in the next one. Checking on any queued job that hasn't declared checkpointing now says the same thing, so the option finds you while you wait, not after.

We also fixed the machinery behind the message: a brief worker reconnect could erase the wait note for a pass, and with it the signal that tells our capacity buyer a job is waiting on a longer window. The note - and the buying it drives - now survives those blips.

Store a value once from your own terminal (gman secret create wandb-prod --material-stdin) and your agent can hand it to any command or batch job by name: the value is sealed on arrival, never shown by any listing, and never appears in your chat. Before this, the only way to pass a recurring key was pasting it into the conversation, which is recorded and outlives the task.

Honest limits, stated plainly: the program you run still sees the value, exactly like any environment variable, so code on the node can read or print it. We scrub stored values out of captured logs as a courtesy, not a guarantee. For reading private datasets, a connection is still the stronger tool: with a connection the credential never enters the node at all.

Connections can now carry write access. Create one with gman connection create ... --verbs read,write and your agent can push a file or folder from a node directly to your own S3-compatible storage (AWS, R2, MinIO, and friends): a folder lands as one tar file, the upload is signed on our side, and your key never enters the chat, the agent, or the node. Every push is recorded in your audit log with the connection, the node, and the destination.

Reads are unchanged, and existing connections stay read-only until you create one that says otherwise. For a one-off download link instead of a push, export a file the usual way.

The new Audit log page lists every decision that changed your organization, newest first: nodes created and stopped, jobs submitted, members invited, roles changed, caps set, credits applied. Each event shows who did it, from which surface (the dashboard, an agent over MCP, the CLI), and when, with the details one click away. Filter by event type, person, or time window.

Agents can ask the same question: the list_audit_events tool returns the log as events with cursor paging, and gman audit prints it in the terminal (--json for scripts). Admin and billing roles see the whole organization; members see their own decisions. Download the filtered view as CSV for the grant report, or pass order=asc to stream events oldest-first into your own tooling. Routine machinery (heartbeats, meter ticks, state transitions) is never in the log, so every line is a decision someone made.

Running givemeanode from CI used to mean lending it a human login. Now an org admin can mint a service token scoped to one workspace: on the Team page, or with gman token create --name ci-deploy --workspace protein-lab. Drop it into your pipeline as GMAN_TOKEN and CI creates nodes, runs commands, and queues jobs as its own machine member, billed to that workspace under its cap, never touching anything outside it.

The token is shown once when you mint it, so store it as a CI secret right away. It carries only the access you grant (compute by default; read-only and org-read variants are there if you want them), it expires in 90 days unless you choose otherwise, and revoking it on the Team page cuts access immediately. Every action it takes is named after the token in your audit log, so the record shows the pipeline, not a colleague who was asleep. Agents can never mint one: minting is an admin action from your own terminal or the dashboard.

Your team page has a single sign-on section. Configure the connection to your identity provider and verify the email domains you own, both through setup links that open the provider's own configuration and expire after a few minutes. Then two switches. Require SSO means members must sign in through that connection; admins keep password sign-in deliberately, so a misconfigured provider is always fixable from inside (protect those accounts accordingly). Domain auto-join means anyone with a verified email at one of your verified domains joins as a member on their way in, bounded by your workspace and organization spending caps like every other member.

Both switches are also yours to ask for in words: your agent can read and set them, and each change lands in your audit log with who made it. Membership stays in step in both directions that matter: someone your provider adds to the organization is picked up here on their way in, and removing a member from your team page removes their membership at the provider too.

Every card payment now emails a receipt: the exact amount collected, the payment date, the line items, and links to the hosted invoice and its PDF - the facts an expense tool matches against the card transaction. Receipts go to your organization's admin and billing members automatically, and a payment fully covered by credits charges nothing and mails nothing.

New on /billing: a finance email. Point it at an inbox that holds no account here - your AP alias, or the address your expense tool (Ramp, Expensify) watches - and receipts and billing notices land there too. Clear the field to stop. And if your accounting needs a purchase order number on invoices, tell support once through a ticket and every invoice after carries it.

/usage answers a new question: what did each project cost? A per-project table totals node hours and spend, with node time and job time broken out separately, and each row links to that project's page. The by-workspace rollup now splits by member and GPU type as well.

The per-node table gained workspace and project columns, and so did the CSV download, so a spreadsheet built from usage.csv can pivot on the same lines the page shows.

One storage price, not two. Snapshot storage now costs $0.10 per GiB-month, down from $0.11, matching object storage's headline rate. The cut takes effect immediately - price decreases skip the seven days of notice that increases carry - and the free allowance is unchanged. One honest footnote: snapshots meter in binary GiB while object storage tiers use decimal GB, so per byte the new snapshot rate lands slightly under the object tier, in your favor.

Overwriting an existing object in a bucket is now atomic. Anyone reading while the upload runs sees the old bytes or the new bytes, never a mixture: the swap happens only once the upload completes and matches what was declared. A failed or abandoned upload cleans up after itself and can never touch the object it was meant to replace - the only thing that deletes your data is an explicit delete from you.

This also fixes a real bug: replacing an object with a smaller one could wedge that key, refusing every retry. Uploads now converge - fix the file, upload again, done.

Two new things on /billing. Buy credits charges the card you already have on file, anywhere from $10 to $10,000, and the credits are there immediately. Automatic top-up states a floor instead: when your credits fall below one amount, charge the card for another. Credits apply to an invoice before your card is charged, as they always have, so a balance simply gets spent down.

Credits you buy last twelve months, longer than the ninety days a promotional credit keeps, and whichever credit is closest to expiring is always the one spent first, so a bonus never quietly outlives its usefulness behind money you paid. Buying also settles an unpaid invoice on the spot if you are carrying one. Every purchase mails a receipt to the same people your other receipts reach, and turning the automatic rule on or off shows in your audit log, because a standing permission to charge a card is a change worth recording.

Nothing about ordinary billing changes: usage is still metered and invoiced after the fact, and prepaying is an option, never a requirement. There is still no payment form here - the charge goes to the card you attached through the billing portal, and if it declines you are told so plainly. A failed automatic charge waits a day and emails your billing members rather than hammering the card, since card issuers read rapid retries as fraud.

Press ⌘K (Ctrl+K on Windows and Linux) from any signed-in page and a find window opens: type a few letters and jump straight to a page, one of your nodes, or one of your projects. Arrow keys move the selection, Enter goes, Esc closes. The same box sits at the top of the sidebar as “Find” if you prefer the mouse.

Results cover everything the sidebar knows plus your own objects by name: every dashboard page (and the operator console, for operators), your GPU nodes, and your projects. Node and project matches update as you type.

Three fixes from one incident. First, a snapshot whose upload fails now stays in list_snapshots as status: failed with the honest reason, until a newer snapshot of the same node supersedes it or you delete_snapshot it - an upload failure reads as what it is, never as a disappearance. Your node's disk is untouched either way: the failure is the copy, not the source.

Second, a customer snapshot severed mid-upload (a worker restart, a stall) is now re-requested automatically while the node's disk is still parked - the same retry our internal snapshots always had - and any expiry timer you set rides along to the fresh attempt. Third, platform deploys now wait out in-flight snapshot uploads instead of killing them: the worker defers its own upgrade until uploads drain, and the control plane stops nudging a worker that is mid-upload in the first place.

Every job now gets a durable checkpoint slot. Write your state to $GMN_CHECKPOINT_DIR, then tell us it is consistent (POST /v1/checkpoint on the in-container metadata service) - we capture it, encrypted under a key only the control plane holds. If the job is ever interrupted - a preemption, a machine dying, capacity ending - the next attempt finds the slot restored into the same directory before your command starts. If the directory is non-empty, resume from it; that is the whole contract. Jobs also gained GET /v1/job from inside the container: which attempt, how long is left, when the last checkpoint landed, and an early warning event when the machine is scheduled to retire.

Billing follows honestly: an attempt we cut short now bills only up to its last checkpoint - you pay for progress that survives, and nothing after it. And if you declare resume: "checkpoint" at submit, the scheduler will start your job in shorter capacity windows it previously had to skip: when a window closes, the job is stopped on purpose, requeued without touching its restart budget, and resumed from the slot in the next window.

A job is only placed on a machine that provably has enough reserved time left to finish it - that rule protects your run from being cut off mid-flight. But when every machine's remaining reservation was shorter than a job needed, the job looked like an ordinary queue wait, with a position and a cheerful estimate that could never come true. Now the job says exactly what is wrong: get_job reports something like “needs 4h30m contiguous; longest available 3h20m”, and the wait estimate goes null instead of guessing.

More importantly, the platform now resolves it instead of waiting you out: when queued jobs need a longer window than any machine currently holds, we extend a machine's reservation to cover the longest one automatically, and the queue drains. And submit_job tells you up front - a capacity_warning field when no machine currently holds enough contiguous time (expect some queueing while we arrange it), or an immediate refusal with the numbers if the requested duration could never fit any window we can buy.

gman login used to open a browser and wait on a local callback, which made signing in from an SSH host or a cluster node an exercise in port forwarding:

ssh train-box-3
gman login

Now, when there is no browser to open, the CLI prints a sign-in URL and a short code instead. Open the URL on your laptop or phone, confirm the code, and the shell you started from is signed in. Nothing listens on the remote machine, no ports are forwarded, and no token is copied by hand. The CLI picks this path automatically over SSH or when no display is available, and gman login --device-code forces it anywhere. Upgrade with gman upgrade; this ships in gman 0.2.2.

Object storage grew a real S3 endpoint. Mint an access key scoped to one bucket, and aws s3 cp, boto3, DuckDB, rclone, and everything else that speaks S3 works against your data directly:

gman storage key create --bucket corpus --access rw
aws s3 sync ./train-data s3://corpus/train/ \
    --endpoint-url https://storage.givemeanode.com

Keys are read-only unless you ask otherwise, revocable in one command with immediate effect, and listed with when they were last used. Multipart uploads, ranged reads, and presigned URLs all work, so tools like DuckDB can query parquet straight out of a bucket. Nothing changes for agents: they keep reading buckets through connections, with no key involved.

The answer has always been no, and it is now a contractual commitment rather than a habit. The new Data Use Policy, part of the Terms of Service, states that we do not use customer content to train, fine-tune, evaluate, or otherwise improve machine-learning models or generalized products, and that our subprocessors are not permitted to either. It enumerates what customer content means here: node disks and snapshots, uploads, object storage, command strings, logs, job inputs and outputs, imported data, and telemetry. There is nothing to opt out of; this is the only mode the service has. A signed data processing agreement is available on request through the contact form.

Public data was never a problem, but data behind a credential, a gated Hugging Face repo or a private S3 bucket, used to mean pasting a token into the chat, which is exactly where a token should never go. Now an admin describes the access once, from their own terminal with gman connection create, and from then on your agent refers to the connection by name. We fetch the bytes onto the node ourselves, so the credential never appears in the chat, in the agent, or on the node. For S3 the connection can be a cross-account role, which involves no secret at all. (Hugging Face no longer needs the terminal at all: since 29 July you can connect it from your team page by approving the grant in a browser.)

The same release adds object storage: buckets on our own object store that your organization owns, filled from the command line (gman storage cp ./data corpus/) and read by agents through the same import path. The first 100 GB is free, then storage starts at $0.10 per GB-month and gets cheaper in tiers as it grows.

A snapshot is a durable copy of a stopped node's disk, safe against anything that happens to the machine. Prepare an environment once, weights downloaded, kernels compiled, and checkpoint it. A snapshot restores into as many new nodes as you like, and restoring counts as provisioning, so a clone costs nothing until it is ready. Snapshots never expire on our timer, but you can give one an expiry so it cleans up after itself, and snapshot storage is priced per GB-month past a free allowance, with the rate quoted in the response.

Every background command's output now streams into queryable storage as it is produced, so logs outlive the node they ran on and searching a week of runs is one question. GPU utilization, memory, power, and spend are recorded automatically for every node, your training script's own metrics can join them, and requests can be traced end to end. Charts your agent saves land on the project's page at /projects, so each project reads like the instrument panel of that investigation.

Agents talk MCP and humans had the website, but a person at a shell, or a script in CI, had neither. Now everything your agent can do, you can do as typed commands:

curl -fsSL https://givemeanode.com/cli.sh | bash
gman login
gman node create --chip h100
gman run demure-hawk -- nvidia-smi

Under the CLI sits a plain HTTP API you can curl with the same token, described at /preview/openapi.json. It is a preview, so the contract may still move before it is promoted to v1. Every example on /docs now shows the same action three ways: the English you say to an agent, the gman command, and the raw MCP call.

The answer is now a live place in line and a wait estimate, measured from how fast the queue has actually been moving. If there is not enough recent activity to estimate from, the answer says so instead of guessing. Time spent waiting in the queue is still free, so a long estimate costs you nothing but patience.

Small files could already be written straight onto a node, and anything public could be downloaded from inside it. Files that exist only on your agent's side, like a private dataset, were the awkward case. Now your agent can upload up to 10 GB once and land it on any node, and the same upload stays reusable for about thirty days, so five nodes and a batch job can all read the one copy.

Your agent can now open a ticket with us, attach the story of what it was doing when things went wrong, and check back later for our reply. You can read and answer the same tickets yourself at /contact. Nothing about getting help requires leaving the conversation where the problem happened.

A project collects the nodes and jobs that belong to one question you are trying to answer. Next week you can ask “what did we try in scaling-laws, what did it find, and what did it cost?” and get one answer instead of a hunt through history. Your projects also have their own page in the dashboard at /projects.

Share the link with a friend. When they sign up through it and add a payment card, they get $50 of credit to spend on GPUs, and you earn credit worth 2% of what they go on to spend. The /referrals page shows who signed up, when, and what you have earned, day by day.

Open /dashboard and everything about your account is in one place: usage, billing, team, referrals, and projects, in a single sidebar instead of separate pages you had to know the addresses of. The public site got the same cleanup. Every address you may have bookmarked still works.

Open status.givemeanode.com and you will find a monitor called End-to-end. Every few minutes we create a real node, run a real command on it, and stop it, exactly the way your agent would. If any step of that breaks, the status page turns red on its own, usually before you would have noticed anything. A green status page now means the product works, not just that the website is up.

Everything about the product now fits on one page at /docs, from getting your first node to batch jobs, and every section has its own link you can send to someone. The same manual is published as plain text at /llms.txt, so an agent can read the docs the way you would and stop guessing.

Your agent can now make one timed web request to any port on your node and report back the status and the response time. It works on ports you have not made public, and it replaces the fragile dance of quoting a curl command inside a shell command inside a tool call.

Jobs are for work nobody should babysit. Your agent describes the run, we build it, put it in a fair line, run it, and bill only the minutes it is actually running. Waiting in the queue is free, and hours in the queue on a busy night is normal, not a problem. Each job can declare its result as it finishes, so “show me the results” comes back as a tidy table instead of a pile of logs.

One request can carry up to 256 variations of the same job. They share one build, run as separate jobs, and read back as one comparison.

The last line of a training script can now be one small web request that stops the node it is running on, so a run that finishes at 3 AM stops billing at 3 AM instead of when someone wakes up:

curl -s -X POST -H 'Metadata-Flavor: givemeanode' http://169.254.42.1/v1/stop

Scripts on a node can also ask who they are and what they cost per minute, and watch for warnings that carry deadlines, like a machine being retired, in time to save a checkpoint. No password or key is needed for any of this; running on the node is the credential.

GPUs quietly raise and lower their own speed with temperature and load, which makes two runs of the same benchmark disagree for no interesting reason. Ask for a pinned clock when the node is created and your timings become comparable. It costs nothing extra.

Give a CI agent a connection that can run nodes and jobs but cannot see billing or invite anyone. Give a finance script a connection that can read spending and touch nothing. When an agent connects, the approval screen is now a checklist: infrastructure and organization are separate boxes, each with a read-only version, and a box you leave unchecked is an ability that connection never even sees.

The answer comes back per node and per minute, and the same ledger renders in the browser at /usage, split by workspace, by person, and by node, with a CSV download for your spreadsheet. Invoices, receipts, and your payment method live at /billing.

Every account is a team of one until you invite someone. Members run their own nodes on the shared bill, admins see everything, and a billing role sees just the money pages. A workspace can carry a spending cap, and an admin can stop any node in the organization, which is the answer to a student's forgotten node burning money over the weekend. The same controls live at /team.

Your agent can now take any port on a node, a TensorBoard, a Jupyter server, a model answering requests, and give it a public HTTPS address. Anyone holding the link can reach it, so treat the link like a password, or ask for token protection on top. Traffic through the link is free and never keeps the node awake on its own.

When every machine is busy, asking for a node now gets you a place in line instead of an error, with a live position and a wait estimate. The moment a slot frees, the node is yours. Waiting costs nothing, and asking again never loses your spot or creates a duplicate.

Your agent gets back a private download link, and a whole folder arrives as a single archive. In the other direction it can write small files like scripts and configs straight onto the node, and fetch big public things like datasets and models from inside the node, where the network is fast.

Long work now runs in the background on the node, so nothing is lost when a chat moves on or a tool call times out. Your agent can read the newest log lines, see whether the run is still going, and stop it, all later. Checking on finished work never wakes a stopped node, so it is always free.

A stopped node costs nothing and keeps its disk exactly as you left it. Tomorrow, “wake tulip back up and keep going” is the whole procedure; the next command wakes it automatically. It behaves like a machine you can power off: files survive, running programs do not.

That sentence is the whole product. givemeanode gives AI agents like Claude, Codex, and opencode on-demand H100 nodes, billed by the minute, with no SSH keys and no console to click through. You connect it once:

claude mcp add --transport http givemeanode https://mcp.autoresearch.sfcompute.com

A browser window asks you to approve, and from then on your agent can get nodes, run commands on them, and hand you the results. The price is quoted at the moment each node is created, and that quote is what you pay.