Watching a Mélodium program run: debug mode and execution reporting

Send a treatment off to a remote engine and “it’s running somewhere” stops being good enough the moment something takes longer than expected. Mélodium 0.10.0 added a debug/dump execution mode plus execution reporting with run IDs and execution group IDs; 0.10.1 rounded it out with the entrypoint and parameters each run was called with. Together, they’re the difference between guessing and actually watching.

--debug: a local dump

melodium run --debug ./run.debug Compo.toml

--logs <path> and --debug <path> write execution logs and a debug dump to a file as the program runs, instead of only to stdout. Since 0.10.2 both flush on every line and event rather than waiting for the run to finish, so if a run dies mid-flight, the file already has everything up to that point.

--api-report: a remote report

MELODIUM_API_TOKEN=... melodium run --api-report Compo.toml

--api-report sends status and logs to the Mélodium API as the run happens, instead of (or alongside) writing them locally. Each reported run carries a run ID, an execution group ID, and, since 0.10.1, the entrypoint and parameters it was called with: enough for whatever’s on the receiving end to reconstruct what actually happened, not just that something did.

What actually receives it

This is exactly what several Mélodium showcase examples rely on to hand execution off to a provisioned worker and then let you follow it. ci_pipeline, distributed_llm_cluster, and ci_failure_triage all run with --api-report against a Cadence.CI  token, precisely so the dashboard has something to show while a CI stage or a distributed inference job is in flight on a machine you’re not looking at.

Locally, --debug is enough to see what a program did after the fact. The moment execution moves to a machine you don’t have a terminal open on, --api-report is what makes it visible at all.