What these clients actually weigh

Four SSH and SFTP clients installed on the same Mac on the same afternoon, each measured the same way. Install size, process count, and physical memory with the application open and idle.

Two columns you might expect are missing, and the reason is in the method: connection time and transfer speed cannot be measured honestly from outside a graphical application. What can be measured instead is the transport itself, and it has its own row.

The numbers

Sort by any column. An empty cell means the figure was not measured, never that it is zero — the reason for each gap is spelled out further down.

Install size, processes and idle memory per client, measured on 2026-08-23. Sorted by install size; the column buttons sort by any column.

Conchshell 2.15.1	9.1 MB	20 MB	1 (own process only, see the note under the table)	—	native	yes
Cyberduck 9.5.3.45464	171.3 MB	262 MB	1	510 MB	Java	no
Tabby 1.0.235	143.2 MB	379 MB	5	693 MB	Electron	no
Termius the build installed on 23 Aug 2026	—	531 MB	6	547 MB	Electron	no
MobaXterm	—	—	—	—	—	yes
WinSCP	—	—	—	—	—	no

* Conchshell’s count is its own process only. It draws its window with the system’s WebKit, whose processes run from macOS rather than from the application bundle, so they are not counted here — while the helper processes of the Electron clients sit inside their bundles and are. Counted the way the home page counts, with every process the application is responsible for, Conchshell 2.10.1 came to 7 processes with four sessions open. This column is not like-for-like.

Data as of 2026-08-23. Machine: MacBook, Apple silicon, macOS 26.5.2, 16 GB RAM.

Seen as bars

Installed size

Megabytes on disk after installation

Memory at idle

Physical footprint across the whole process tree

How to read this

These are not benchmarks of speed. Nothing here tells you which client connects faster or moves files quicker, because none of that was measured — see below for why.

What is measured is what an application costs you while it sits there: the space it takes on disk and the memory it holds with no connection open. On a laptop with four applications running that is the number you feel, and it is the number that differs most between a native application and one carrying a browser engine or a Java runtime with it.

One figure deserves suspicion rather than trust: Cyberduck's 510 MB. A Java heap is sized from the machine's RAM, not from what the application needs, so on a machine with different memory that number will be different. Do not carry it over to your own hardware.

Method

Machine. One MacBook on Apple silicon, macOS 26.5.2, 16 GB of RAM. Every client was measured on the same machine on the same day, with the others closed.

Install size is du -sm on the installed application bundle.

Memory is the sum of phys_footprint across every process belonging to the bundle, read with the system's own footprint tool. Not RSS: RSS counts shared pages once per process, and for an application made of fifteen processes the sum is inflated several times over.

Processes are counted the same way: those running from inside the application bundle. For Conchshell that leaves out the system WebKit processes that draw its window, so its count is not comparable with the others — the note under the table has the details.

Idle means launched, left alone for twenty-five seconds, with no connection opened. Three runs per client, application quit between runs, median reported.

Runtime is read from the bundle: an Electron framework, a bundled JVM, or neither.

What is deliberately not here

Connection time and transfer speed per client: these are graphical applications, and such numbers cannot honestly be taken from outside one.
Idle memory for Conchshell: the run happened from a terminal inside the application itself.
MobaXterm and WinSCP: no macOS build exists.

A fourth omission, for completeness: an earlier version of the script reported a readiness time. Every client came out between 2240 and 2254 ms, which is not a property of the applications — it was the floor of the sampling loop. The metric measured the script and has been removed rather than published.

The transport, measured separately

Every client in this table speaks to the same servers over the same network. That part is common to all of them, and it can be measured — just not per client. These are OpenSSH's own numbers for one connection and one 10 MB upload, over a long-haul link.

Tool: OpenSSH_10.2p1, LibreSSL 3.3.6
Path: a server in Bulgaria, over a link from South-East Asia
Connect: 2573 ms minimum, 2615 ms median
Transfer of 10 MB: 8654 ms minimum, 12756 ms median
Runs: 10

The interesting part is not the numbers but their steadiness. Across ten runs the connection took between 2573 and 2657 ms — a spread of three per cent. The same 10 MB upload took anywhere from 8.6 to 22.8 seconds, nearly a factor of three. On a long link, setting up a connection is predictable and bulk transfer describes the link at that moment, not the software. Which is another reason no client in the table is given a throughput figure.

Reproduce it, or contribute data

The scripts that produced this table are not published. Everything they do uses tools macOS ships, and none of it needs sudo, so each step can be repeated by hand:

install size — du -sm on the installed application bundle;
idle memory — launch the application, leave it for twenty-five seconds without connecting anywhere, and add up phys_footprint from footprint for every process running from inside the bundle; three runs, quitting in between, median reported;
the transport — ssh host true for the connection and an sftp put of a 10 MB file for the transfer, with ControlMaster=no: with multiplexing on, every run after the first reuses an open socket and reports single-digit milliseconds.

One trap is worth knowing: do not measure from a terminal inside one of the applications being measured. This table was produced that way, which is why Conchshell has no idle memory figure.

If you run it on hardware or a link that differs from this one, the numbers are worth having and this table has room for them. Send them to support@conchshell.app with the machine and the date, and they go in with your attribution.

Two rows are open by construction: MobaXterm and WinSCP have no macOS build, so they are unmeasured here. Anyone with a Windows machine can fill those in.

Where Conchshell stands, plainly

It is the smallest of the four on disk, by a wide margin, and it is the only one of the four that is not carrying a browser engine or a Java runtime. That is the whole of the claim.

Its idle memory is not in the table, and the reason is not flattering: the script was run from a terminal inside Conchshell itself, so the application was hosting a live session rather than sitting idle. With that session open its own process held 70 MB. That is not an idle figure, and not a whole one either: the system WebKit processes that draw its window are not in it. A cold measurement needs the script run from a different terminal, and it will go in when it is done.

Download Conchshell free