ssh always reads stdin unless you tell it not to with the -n option (or the -f option).

The reason is so that you can do things like

tar cf - somedir | ssh otherhost "tar xf -"

And it always does this because ssh has no way of knowing if your remote command accepts input or not.

Likely what is happening in your first command is that seq fills up the network and pipe buffers (seq -> ssh -> sleep), and since sleep isn't reading anything, it gets blocked waiting for more reads, and then sleep exits, causing those full buffers to be dumped, and then seq is unblocked, feeding the remainder to wc.

In your second command, it is still reading stdin, but you've externally assigned /dev/null to stdin.

ssh always reads stdin unless you tell it not to with the -n option (or the -f option).

The reason is so that you can do things like

tar cf - somedir | ssh otherhost "tar xf -"

And it always does this because ssh has no way of knowing if your remote command accepts input or not.

Likely what is happening in your first command is that seq fills up the network and pipe buffers (seq -> ssh -> sleep), and since sleep isn't reading anything, it gets blocked waiting for more reads, and then sleep exits, causing those full buffers to be dumped, and then seq is unblocked, feeding the remainder to wc.

Note that you would get similar results with seq 1000000 | ( cat | cat | sleep 1; wc -l)

In your second command, it is still reading stdin, but you've externally assigned /dev/null to stdin.