Write a file (path in body, utf8 or base64)

Write a small file onto a node: configs, entry scripts, calibration sets: the heredoc pattern as a real tool (no shell quoting, binary via encoding:"base64", executable:true for mode 0755). Returns {path, bytes_written, sha256, sha256_verified}; parents are created and an existing file is replaced atomically. sha256 is the digest of the content, and the file is hashed AGAIN on the node before it is moved into place (a mismatch refuses the write), so the receipt is a receipt for the bytes on the disk - hash your payload locally and compare, and a base64 blob that got mangled on the way in is caught by one string comparison instead of a debugging session (sha256_verified:false means the image has no sha256sum, so the file was checked by length alone). The content never rides a command line, so nothing of it is recorded. NOT for secrets: pass those as run_command's env (this writes plaintext to the node's disk); NOT for datasets or weights: pull those from inside the node (run_command: curl / git clone / huggingface-cli download). Getting results OUT: export_file returns a download URL, or push from inside the node (huggingface-cli upload, aws s3 cp, git push) before stopping it. Calling this on a stopped node wakes it, exactly like run_command (same queued/waking answers) - and THE WRITE DOES NOT HAPPEN on those answers: there is no pending-write queue, the content is not stored anywhere, and the answer says so (written:false). Re-send it once the node is running; to push several files, wake the node, then hold_node, then write, so the idle window cannot close between them. Files under ~ survive stop_node and wake. A wake this opens bills to the node's mission, like any other work on it. The answer's timing_ms (server: our whole handling; exec: the node leg) shows a write lands in well under a second; a slow call spent the rest in your client producing the content, so send text as utf8.