When Not to Use Mélodium

Every tool has a boundary, and we would rather draw it than have you find it.

Your value is a very specific, non-portable toolchain

If ninety percent of your program is calling into one ecosystem’s own tooling, deep integration with a particular framework’s internals, a proprietary SDK, a build system only that ecosystem understands, use that ecosystem’s own language for it. Calling out to a process or a service from Mélodium works and is normal, but it is not a substitute for being inside the ecosystem.

This is not a blanket statement about machine learning or audio processing. Mélodium’s own origin is signal analysis: the language came out of massive audio analysis work at UQAM, built specifically to run the same routines across machines with very different capabilities. ml/models/whisper, ml/models/mistral, and the audio and record packages exist because that use case is a real target, not an afterthought. The boundary is narrower than “AI” or “audio”: it is about how much of your value sits inside one ecosystem’s own idioms versus how much of it is orchestration, I/O, and connecting things together.

You are one person maintaining one script

Two different situations here, worth separating.

If the script already exists and works, the fastest way to see whether Mélodium helps is not a rewrite: wrap the existing logic as a single treatment, so its inputs, outputs, and side effects become explicit and isolated, without touching what is inside it. That alone is often worth doing even if nothing else changes.

If nothing exists yet and you are starting from a blank page, Mélodium is a language like any other for a single script: not worse, not obviously better either. The typed, decomposed structure it forces pays off once the script needs to grow, be shared, or move to more machines. If none of that is coming, the constraint is rent paid early for a return you have not needed yet.

You need a rich per-task operational UI today

Distributed observability is thinner today than a mature scheduler’s UI. This is a known, worked-on gap, not a permanent one: a per-run dashboard view is already designed into the platform’s data model and waiting on the rendering side to be built, see the Cadence.CI roadmap . If a detailed per-task timeline is a hard requirement right now, talk to us about your specific use. We would rather understand what “done right” looks like for you before we build it than guess and redo it later.

Your CI pipeline is mostly third-party marketplace actions

Adopting Mélodium for CI means writing, in a day, the wrapper an existing marketplace action gave you in a line. For a pipeline assembled mostly from actions, that arithmetic genuinely does not favour a rewrite today, and no architecture argument changes it. If a handful of your steps are expensive, custom, and worth moving while the rest stay where they are, that is a different and much more reasonable starting point, worth a conversation about your specific mix.

We also think the marketplace model itself has a cost that is rarely priced: a registry assembled the way npm’s was, then secured after the fact, inherits years of supply-chain problems that are hard to fix retroactively. If we build a package registry, we would rather design signed packages and declared capabilities in from day one than bolt them on later. That is a direction we are thinking about, not a shipped feature, and it does not change the arithmetic above today.

Your workload is a single stream, checkpointed, exactly-once, at very large scale

Mélodium already has state: a model is a long-lived stateful element by design, and a connection is deterministic at every input because it has exactly one source. What is missing is broker-backed exactly-once delivery and windowed aggregation checkpointed at very large scale, the specific thing dedicated stream processors like Flink are built for. If that is your workload, use one of those.

If what you actually need is simpler, a job that runs on a schedule or in reaction to a webhook, that is a much smaller ask and it is close: hosting a job directly, with cron and webhook triggers, no separately running engine required first, is on the near-term Cadence.CI roadmap .

Where it is the right answer

Pipelines that mix I/O, transformation, and external services. Workloads that need to move from one machine to many without becoming a different program. Systems where a data boundary has to be provable rather than described. Anything where the glue between your tools has quietly become the largest codebase you maintain.