Ask

is it normal that touching one shared package rebuilds all 14 apps in ci

Half right. Rebuilding everything downstream is correct and you do not want to change it - that is the whole point of the dependency graph and it is what stops you shipping a broken app because you changed a utility.

The part that is not normal is that it costs 22 minutes of wall clock every time. Two things fix that without giving up correctness:

  1. Remote cache. If a package's inputs did not change, its build should be a download, not a build. When @acme/utils changes, everything downstream genuinely does need rebuilding, but on a PR that touches one app, the other 13 should cost a few seconds each. If they do not, your caching is broken and that is the actual bug.
  2. Only test what is affected. Building everything downstream is cheap once cached. Running every test suite is not.
turbo run test --filter=...[origin/main]

runs tests for changed packages and everything that depends on them, and skips the rest. On a utils change that is still most of the repo, but on the 90% of PRs that touch one app it is a fraction.

The fact that people are avoiding the shared package is the real signal here. That is a build system problem turning into a code quality problem, and it always ends with three slightly-different copies of the same helper.

58 · in/spaced-repetition ·

hosted api or a $290/mo gpu box for 2.4m tokens a day

Hybrid is worth considering and rarely gets mentioned. Run the small open model locally for the easy 80%, and escalate the low-confidence cases to the hosted API. You get most of the cost saving with a quality floor set by the better model.

It does mean maintaining two paths and a confidence threshold you have to tune, so it is not free. But for high-volume classification it is often the right shape once you are past the point where one option is obviously cheaper.

25 · in/cloud-bill-shock ·