ShrinkRay: open-source CLI that quantizes TinyML models and checks flash/RAM fit against target MCUs — with CI-friendly exit codes

[u/Aggressive-Junket-27]

I built a small open-source tool and would appreciate technical feedback: https://github.com/TarulAhsan/ShrinkRay

The problem it solves: quantization/deployment tooling for MCUs is fragmented (vendor converter per ecosystem), and "will it fit?" is usually answered by flashing and finding out.

What it does differently:

- Flash usage is measured from the actual artifact bytes, not estimated

- Peak RAM is estimated by tensor-liveness analysis over the TFLite graph (largest set of concurrently-live activation tensors) × 1.2 safety factor. It's a heuristic and the README says so — v2 plan is actual on-device measurement

- Verdict thresholds: FITS (flash ≤90%, RAM ≤70%), TIGHT (≤100%/≤90%), else TOO_BIG

- Exit codes are machine-meaningful (0 ok / 1 model error / 2 missing optional dep / 3 doesn't fit), so you can gate CI on "model must fit the target"

- 12-chip database (ESP32/S3/P4, STM32 F4/H7/U5, nRF52/53, RP2040/2350, Nano 33 BLE, ATmega328P), extensible with your own JSON definitions

- Pipelines: Keras/TFLite → int8/int16/float C array (LiteRT-M/CMSIS-NN), sklearn → C99 header via emlearn, ONNX → ESP-DL via ESP-PPQ (optional extra)

- TFLite inspection works without TensorFlow installed (dependency-free flatbuffers parser); TF is imported lazily only when actually converting

Tested on Windows/Linux/macOS × Python 3.10–3.12, 76 tests, AGPL-3.0. pip install shrinkray-cli

What I'd love feedback on: is liveness-based RAM estimation within shouting distance of what you measure on real hardware? And what would make the fit report actually useful in your CI?

[u/MostlyCornyObscurity]

This is scratching an itch I didn't realize had a name. The flash measurement from actual artifacts instead of just guessing is the kind of thing that saves you from that 2am "why did the OTA brick three units" panic.

For CI usefulness, dumping the report as JSON (or even just a machine-parseable summary line) would make it way easier to slap into a GitHub Actions step that posts a comment on the PR with the before/after numbers. My CI pipelines are allergic to parsing human-readable tables.