I replaced my 137MB Electron menu-bar app with a 693KB native build

XM Yang · SweetAI — Fri, 23 Oct 2026 06:36:27 +0000

I ship a small macOS menu-bar utility that shows AI API quota usage — used + remaining with a reset countdown — in a Control-Center-style dropdown. Click any tool for a native detail window. The first version was Electron: a 110–137MB download for what is essentially a dropdown panel and a settings window.

Last week I rebuilt it native (macOS + Windows, separately). The macOS Apple Silicon build is now 693KB. The Windows build is 221KB. Same features, roughly 200× smaller.

What actually made the difference:

The web runtime was the product. Chromium + Node accounted for nearly all of those megabytes. My own code was a rounding error. If your app is mostly native UI with a little logic, you're shipping a browser to display a dropdown.
Menu-bar UX is one native API call. NSStatusItem + NSPopover gives you the dropdown behavior for free — vibrancy, dark mode, screen-edge positioning. In Electron I was fighting frameless windows and CSS to fake it.
The rewrite deleted more than it added. All the Electron-side scaffolding I had accumulated (auto-updater config, the signing dance, transparent-window glitches) went away entirely. Less code to maintain, not more.
What I lost: one codebase for two platforms. I now maintain two native codebases. For a utility this size that's fine; for a document editor it wouldn't be.

Honest trade-off, not a prescription: if your app is genuinely a web app with a desktop shell, stay on Electron. If it's a native-feeling utility wearing an Electron costume, the rewrite pays for itself in download size, launch time, and fewer "why does this dropdown eat my RAM" complaints.

QuotaTray 2.0 (the native rebuild) is $24: https://payhip.com/b/o7RZ1 — includes the macOS Apple Silicon and Windows builds.

The poisoned LiteLLM 1.107.0 problem, and the 30-second check I now run on every repo

XM Yang · SweetAI — Fri, 23 Oct 2026 00:05:54 +0000

On Oct 21, LiteLLM disclosed that v1.107.0 shipped compromised — malicious wheels on PyPI (live 11:39–13:23 UTC), poisoned Docker tags (v1.107.0, latest, main-latest, main-stable, 11:46–14:20 UTC), and GHCR images (until 13:51 UTC). The official announcement: https://docs.litellm.ai/blog/security-incident-oct-21-2026

The part that caught people off guard: in an affected environment, any Python start re-runs the implant. So the vendor's own response steps warn you not to start with pip install or pip show on a suspect box — you check files and metadata first, from the shell.

I turned the announcement's manual steps into a small checklist I now run on every repo and venv folder. Here's the method, then the tool that automates it.

The manual check (works from any shell, no Python startup)

Version specs, evaluated not grepped. litellm==1.107.0 pinned = exposed. But litellm>=1.0, ~=1.107, ^1.107.0, or unpinned litellm in requirements/pyproject/Poetry files = admits the bad version — whether it actually installed it depends on whether you installed during the exposure windows above. A spec that excludes 1.107.0 = clean on this axis.
Lockfiles. Check poetry.lock, uv.lock, Pipfile.lock for a resolved litellm 1.107.0 — the lockfile tells you what actually got installed, the manifest only tells you what was allowed.
Dockerfiles and compose files. Tags v1.107.0 = exposed; latest / main-latest / untagged images pulled during Oct 21 11:46–14:20 UTC = suspect. Also compare against the compromised image digest published in the announcement.
Installed environments — without starting Python. Read litellm-*.dist-info/METADATA directly in site-packages. If it says 1.107.0, treat the environment as compromised: rebuild from litellm==1.106.2, rotate every secret that box could reach, check CloudTrail.
Implant markers. Look for cook.pth, cook.py, a planted sitecustomize.py, and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if that lockfile exists).

The automation

I packaged the above as litellm-check (13 rules, each mapped to a step in the official announcement), because I kept seeing "how do I know if I was exposed?" in issue threads:

pip install litellm-check
litellm-check scan ./your-project        # code side
litellm-check scan ~/.virtualenvs        # installed-env side

Output is a Markdown or JSON evidence report — file:line, the matched spec/tag, and the announcement basis for each finding. --fail-on critical works as a CI gate. Zero third-party dependencies, Python 3.11+, Apache-2.0.

The honest limit, printed on every report: a clean scan means "none of the known indicators were found" — nothing more. Environments rebuilt after exposure, images pulled without a definition file in the tree, or CI-only installs leave nothing on disk to find. This is evidence collection, not a safety certification.

Repo: https://github.com/dylanXM/litellm-check
PyPI: https://pypi.org/project/litellm-check/
Packaged bundle with sample report & remediation checklist ($29): https://payhip.com/b/eFOvm
Not affiliated with BerriAI/LiteLLM; "LiteLLM" names only the incident this tool audits.

If your stack exposes LiteLLM somewhere these 13 rules miss, rule PRs with fixtures are the most useful contribution.

DEV Community: XM Yang · SweetAI

I replaced my 137MB Electron menu-bar app with a 693KB native build

The poisoned LiteLLM 1.107.0 problem, and the 30-second check I now run on every repo

The manual check (works from any shell, no Python startup)

The automation