How do their APIs compare?

These two projects are architecturally very different animals, and it shows clearly in how (or whether) each exposes an "API":

whisper.cpp: a deliberate, stable, embeddable C API

whisper.cpp is designed from the ground up to be used as a library. Its public surface is a single C header, include/whisper.h, exposing extern "C" functions with a stable ABI. The retrieved code shows the pattern clearly:

• Lifecycle functions: whisper_init, whisper_free, and analogous _init/_free pairs are used consistently even in backend-specific sub-modules, e.g. the Core ML wrapper (whisper_coreml_init / whisper_coreml_free) [src/coreml/whisper-encoder.h:L13-L14] and the VitisAI (Ryzen AI NPU) backend (whisper_vitisai_init / whisper_vitisai_free) [src/vitisai/whisper-vitisai-encoder.h:L10-L12]. This opaque-handle-plus-free pattern (struct whisper_context, struct whisper_coreml_context, struct whisper_vitisai_context) is the backbone of the whole API.
• The core inference entrypoint is whisper_full(ctx, params, audioData, n_samples), which runs the entire pipeline — PCM → log-mel spectrogram → encoder → decoder → text — in one call, followed by accessor functions like whisper_full_n_segments and whisper_full_get_segment_text to pull results out. This is visible in the Java JNA binding, which mirrors the C API 1:1 [bindings/java/src/main/java/io/github/ggerganov/whispercpp/WhisperCpp.java:L139-L178].
• Callbacks are part of the API contract: new_segment_callback, progress_callback, and encoder_begin_callback are set on whisper_full_params so callers get streaming/progress feedback and can abort mid-inference. The Go binding shows these being wired up via cgo trampolines [bindings/go/whisper.go:L10-L60].
• Internally the API is layered on ggml — tensors, backends, and a scheduler (whisper_sched, wrapping ggml_backend_sched_t) [src/whisper.cpp:L541-L564] — but none of that leaks into the public header; it's all hidden behind the opaque whisper_context/whisper_state types.
• The API is intentionally multi-language: the same C ABI is wrapped by Go (cgo), Java (JNA), and others, plus backend-specific internal APIs (Core ML, VitisAI/Ryzen AI NPU) that are not meant for end users but follow the same init/free/encode idiom for consistency [src/vitisai/whisper-vitisai-encoder.h:L14-L30].

mosh: no public library API — internal class interfaces only

Mosh is an end-user SSH-replacement application, not a library, so there's no equivalent "public API" for third parties to link against. What exists instead are internal C++ class interfaces used to wire together the client/server:

• Terminal::Emulator exposes state-transition methods like execute, CSI_dispatch, Esc_dispatch, OSC_end, plus accessors like get_fb() and an operator== for comparing terminal states [src/terminal/terminal.h:L71-L83]. These are used internally by the terminal-emulation and dispatch code, not by external consumers.
• The Complete class (in completeterminal.cc) has a compare() method used to diff two synchronized terminal states, checking framebuffer size, per-cell equality, and cursor position [src/statesync/completeterminal.cc:L176-L211] — again an internal state-synchronization primitive, not a public interface.
• Networking and terminal-overlay code (stmclient.cc, terminaloverlay.h) interoperate through internal headers like network.h, transportsender.h, and parser.h [src/frontend/terminaloverlay.h:L34-L37], and STMClient::process_network_input/process_user_input show how the client polls the network layer and framebuffer diffing rather than exposing anything for external callers [src/frontend/stmclient.cc:L295-L320].

The core contrast

• Audience: whisper.cpp's API is meant to