Experimental. This feature is new and may change in backwards-incompatible ways before it stabilizes. The KonduktorResult condition type, the $KONDUKTOR_OUTPUT_DIR/result.json contract, and the Job.result() / konduktor result surfaces are the most likely to shift based on early feedback.
Konduktor jobs can report a JSON-serializable value back to the launching process. This is useful for hyperparameter sweeps, Optuna trials, and any workflow where the launcher needs to read an objective / metric / artifact pointer from the run.
Job Handles
Every Konduktor-launched pod has:
- An
emptyDir volume mounted at /konduktor/output.
- An environment variable
KONDUKTOR_OUTPUT_DIR pointing at that directory.
To report a value, write JSON to $KONDUKTOR_OUTPUT_DIR/result.json:
Retrieving the value (Python API)
konduktor.launch() returns a Job handle (a str subclass, back-compatible with existing job_name = konduktor.launch(task) code). New methods:
job.wait(timeout=...) returns the terminal state ("succeeded" or "failed") without parsing a value.
Retrieving the value (CLI)
konduktor launch --wait blocks until completion and prints the result JSON:
konduktor result <job-name> fetches the result of a terminal job:
Both commands exit non-zero on job failure, malformed result, or timeout.
Failure modes
If your result is larger than 4 KB, return a summary (e.g. a checkpoint path), not the full artifact.
Multi-node jobs
In a multi-node JobSet, only worker 0 of the first replicated job reports. Other workers’ termination messages are ignored.
Use case: Optuna sweep
The primitive pairs naturally with an Optuna hyperparameter sweep: