Five real scenarios CPYNET is actually built for - not hypothetical ones. Every command below is real input against a real deployment, shown with the exact output it produces.
You're SSH'd into a remote server, something failed, and you need to get the relevant log lines to a teammate right now - without another round of SSH access or emailing a file.
$ journalctl -u myservice -n 200 | cpy482913curl "https://llmtag.com/482913"
Two lines back: the bare code and a ready-to-run curl command. Paste either one in chat - whoever reads it gets the exact text, and it's gone the instant they do:
$ pst 482913Aug 08 14:02:11 myservice[1823]: connection refused: db.internal:5432Aug 08 14:02:11 myservice[1823]: retrying in 5s...Aug 08 14:02:16 myservice[1823]: connection refused: db.internal:5432
That's the pst shell function - it also drops the text on their clipboard as a side effect, pure convenience. No cpy/pst installed on their end? The plain curl "https://llmtag.com/482913" line cpy printed above works exactly the same, no alias required. Either way, a second read of the same code (by anyone, including you) gets a 404 - it's already gone.
Some environments - locked-down corporate laptops, VDI sessions, remote desktops with no shared clipboard between host and guest - simply don't let you copy text out through the OS clipboard at all.
$ echo "wifi password: correcthorsebatterystaple" | cpy174205curl "https://llmtag.com/174205"
$ pst 174205wifi password: correcthorsebatterystaple
CPYNET never touches the OS clipboard on the locked-down machine either way - everything moves out as plain text over curl, so a disabled clipboard doesn't matter there. The machine reading it back is a normal one, so pst's clipboard convenience works fine on that end. No terminal handy on the receiving side? Scan the QR code shown after sending with your phone instead - it opens straight in the browser.
Not everyone you need to share with wants to run a command - a client, a manager, or a teammate on a locked-down machine just needs a link and a password they type once, in a browser.
$ echo "staging: https://staging.internal user: demo pass: xQ9!vB2m" | cpy -password=handoff2026591042curl "https://llmtag.com/591042"
Send the plain link (not the code alone - the code by itself still needs the right URL) and the password through separate channels. They open the link in any browser, type the password into the field on the page, and read it once - no CLI, no browser extension, no account. A wrong password fails without burning the read; a missing one just prompts again.
A container without a shared volume, an isolated build step, a CI job's intermediate output - anywhere stdout is reachable but the filesystem isn't shared with wherever you actually need the result.
$ docker run myimage some-command | curl --data-binary @- https://llmtag.com/https://llmtag.com/718234
A raw pipe (no cpy installed inside the container) gets back just the bare URL - still exactly one line, still pipeable into the next step:
$ pst 718234{"status":"ok","records_processed":48213}
The container had no cpy installed, so it fell back to a raw pipe - your own machine almost certainly does, so reading it back is just pst (a plain curl "https://llmtag.com/718234" works identically if it doesn't). Works the same with kubectl exec, a minimal scratch/distroless image that doesn't even have curl (see the netcat fallback), or any other environment where the only thing you can reliably reach is a pipe.
The password above (-password=) is checked server-side - the server briefly sees the plaintext to verify it. cpy -e is a different, stronger layer: encryption happens entirely on your machine before anything is sent, and the server only ever stores ciphertext.
$ echo "root ssh passphrase: Tr0ub4dor&3" | cpy -e305817curl "https://llmtag.com/305817"key (share separately, never with the link/code): n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdE
Send the code through one channel and the key through a different one (a call, a second chat thread, in person) - anyone with only the link or code gets back unreadable ciphertext, the server included.
$ pst 305817 -key=n8xQ2vLKw+9fZTa3mPqR7yUvXsB4tCdEroot ssh passphrase: Tr0ub4dor&3
Leave off -key= and pst prints the raw ciphertext instead - the server never has enough information to decrypt it either way, key or no key.