SKILL: Bohrium Job Management

intent

submit, monitor, and manage compute jobs on the bohrium platform. use this skill when a user asks to submit jobs (via CLI args or config file), list running/completed jobs, view logs, download results, terminate/kill/delete jobs, or manage job groups. not for node management, image management, or project setup.

inputs

environment variables (injected via openclaw config ~/.openclaw/openclaw.json):

• ACCESS_KEY: bohrium API key for authentication (required)
• PROJECT_ID: bohrium project ID (required)
• OPENAPI_HOST: defaults to https://open.bohrium.com; set manually if install script doesn't auto-configure
• TIEFBLUE_HOST: defaults to https://tiefblue.dp.tech; set manually if install script doesn't auto-configure

bohr CLI (must be installed and in PATH):

• macOS: run curl -fsSL https://dp-public.oss-cn-beijing.aliyuncs.com/bohrctl/1.0.0/install_bohr_mac_curl.sh | bash
• Linux: run curl -fsSL https://dp-public.oss-cn-beijing.aliyuncs.com/bohrctl/1.0.0/install_bohr_linux_curl.sh | bash
• verify with bohr version

job submission inputs (either CLI args or JSON config):

• image address: full docker image URL (e.g. registry.dp.tech/dptech/deepmd-kit:3.1.1), required
• machine type: CPU or GPU spec (e.g. c4_m15_1 * NVIDIA T4), required
• command: shell command to execute, required
• input directory: local path with job files; defaults to ./
• project ID: bohrium project ID, required
• job name: optional, defaults to auto-generated
• output directory: optional local path for result download
• max run time: optional timeout in minutes
• max reschedule times: optional auto-retry count on interruption
• nnode: optional parallel compute node count; defaults to 1

external connection:

• bohrium API at https://open.bohrium.com/openapi/v1 (requires ACCESS_KEY header)

procedure

step 1: verify environment and CLI installation

input: shell environment output: confirmation that bohr command is available and env vars are set

run bohr version to confirm CLI is installed. verify echo $ACCESS_KEY and echo $PROJECT_ID are non-empty. if either env var is missing, check ~/.openclaw/openclaw.json and re-source shell profile or restart terminal.

step 2: choose submission method (CLI args vs config file)

input: job complexity and user preference output: decision on submission approach

if job is simple and parameters fit CLI flags, use method 1 (CLI args). if job requires multiple output files, datasets, or complex config, use method 2 (JSON config file). config file method is also preferred for reproducibility and archival.

step 3: submit job via CLI arguments (method 1)

input: image address, machine type, command, project ID, optional: job name, input directory, max run time, max reschedule count, nnode output: job ID (integer)

run:

bohr job submit \
  -m "registry.dp.tech/dptech/deepmd-kit:3.1.1" \
  -t "c4_m15_1 * NVIDIA T4" \
  -c "python train.py" \
  -p ./input_dir/ \
  --project_id 154 \
  -n "my-job-name" \
  [--max_run_time 120] \
  [--max_reschedule_times 2] \
  [--nnode 1]

note: use relative paths in the command (e.g. python train.py, not /home/input_lbg-userId-jobId/python train.py). bohrium auto-extracts input files and cds into that directory.

step 4: submit job via config file (method 2)

input: job.json file with all parameters, input directory path output: job ID (integer)

create job.json with fields: job_name, command, log_file, backward_files (list of output files to keep), project_id, machine_type, image_address, job_type (must be "container"), disk_size, dataset_path (optional), result_path (optional: /personal, /share, or /data), max_reschedule_times, max_run_time, nnode. then run:

bohr job submit -i job.json -p ./input_dir/

note: backward_files determines what gets downloaded; empty list means keep all output. result_path auto-collects outputs to data disk (/personal, /share, or /data only).

step 5: list jobs with optional filters

input: optional filter flags (count, status, job group ID, JSON format) output: table or JSON of jobs with ID, name, status, timestamps

run one of:

bohr job list -n 10                    # recent 10 jobs
bohr job list -n 5 --json              # JSON output
bohr job list -r                       # running only
bohr job list -f                       # failed only
bohr job list -i                       # finished only
bohr job list -p                       # pending only
bohr job list -j 15954383              # all jobs in a group

step 6: describe a specific job

input: job ID output: job metadata including status, machine type, image, command, timestamps, and optionally full details

run:

bohr job describe -j 22153612 [--json] [-l]

the -l flag includes full output. use --json for machine-readable format.

step 7: view job logs

input: job ID, optional output directory for download output: logs printed to stdout or saved to local directory

run:

bohr job log -j 22153612                # print to stdout
bohr job log -j 22153612 -o ./logs/     # download to directory

logs are real-time if job is running. if job is finished, logs are archived and still viewable.

step 8: download job results

input: job ID, output directory path output: result files saved to local directory

run:

bohr job download -j 22153612 -o ./results/

or for a job group:

bohr job_group download -j 15954383 -o ./results/

downloaded files are those listed in backward_files (if specified) or all output files (if backward_files is empty).

step 9: manage running/completed jobs

input: job ID or list of job IDs, action (terminate, kill, or delete) output: confirmation message; job status changes

run one of:

bohr job terminate 22153612             # mark done, keep results
bohr job kill 22153612                  # force stop, discard results
bohr job delete 22153612                # remove everything
bohr job terminate 22153612 22153613    # batch terminate
bohr job delete 22153612 22153613       # batch delete

terminate: job moves to "completed", results are kept, record is kept. kill: job moves to "failed", results are discarded, record is kept. delete: job record and files are completely removed.

step 10: manage job groups

input: optional job group name, project ID, optional date range, optional group ID output: list of groups, created group ID, or confirmation of action

run:

bohr job_group list -n 10 [--json]                              # list groups
bohr job_group list -s 2026-01-01 -e 2026-03-14                 # by date range
bohr job_group create -n "experiment-v1" -p 154                 # create group
bohr job_group terminate 15954383                               # terminate all jobs in group
bohr job_group delete 15954383                                  # delete group
bohr job_group download -j 15954383 -o ./results/               # download all results

note: CLI job group IDs are different from web UI IDs. use CLI IDs with bohr job submit -g <id>.

step 11: advanced API operations (CLI unsupported only)

input: ACCESS_KEY env var, job ID or job group ID, optional filter params or JSON body output: JSON response from bohrium API

use only for operations not covered by CLI. examples:

import os, requests

AK = os.environ.get("ACCESS_KEY", "")
BASE = "https://open.bohrium.com/openapi/v1"
HEADERS = {"accessKey": AK}

# filter jobs by status (0=pending, 1=running, 2=finished, 3=scheduling, -1=failed)
r = requests.get(f"{BASE}/job/list", headers=HEADERS,
    params={"page": 1, "pageSize": 10, "status": 1})

# get job config (returns file access token and paths)
r = requests.get(f"{BASE}/job/view/conf/{job_id}", headers=HEADERS)

# view job snapshot (state, baseDir, tempDir, token, host, expires)
r = requests.get(f"{BASE}/job/{job_id}/snapshot", headers=HEADERS)

# rename job
requests.post(f"{BASE}/job/{job_id}/modify",
    headers={**HEADERS, "Content-Type": "application/json"},
    json={"name": "new-name"})

# rename job group
requests.post(f"{BASE}/job_group/{job_group_id}/modify",
    headers={**HEADERS, "Content-Type": "application/json"},
    json={"name": "new-group-name"})

decision points

CLI vs API submission: if job is straightforward (single command, single image), use CLI args (bohr job submit -m ... -t ... -c ...). if job needs multiple outputs, datasets, or complex config, write job.json and use bohr job submit -i job.json. if you need to filter by status or rename jobs, use API calls.

Path format: always use relative paths in commands (e.g. python train.py, cd se_e2_a && dp train input.json). do not use absolute paths like /root/input or /home/input_lbg-userId-jobId/. bohrium auto-cds into extracted input directory.

terminate vs kill vs delete: if job is done and you want to keep results and record, use terminate. if job is stuck and you want to stop it immediately without keeping results, use kill. if you want to erase all traces, use delete. default is terminate.

Image address format: if user provides a short name (e.g. deepmd-kit:3.1.1), expand it to full registry URL: registry.dp.tech/dptech/deepmd-kit:3.1.1. if user provides full URL, use as-is. docker image names without registry default to docker hub, which bohrium does not access.

machine_type format: if user specifies CPU cores and RAM only, map to standard CPU types (e.g. 4 cores, 8G RAM = c4_m8_cpu). if user specifies GPU, use format c{cores}_m{ram}_{count} * NVIDIA {type} (e.g. c4_m15_1 * NVIDIA T4). if unsure, check common machine types table.

large file handling: if bohr job submit appears to hang after specifying -p ./dir/, check if directory contains large hidden files or temp files. compress input dir or remove unnecessary files. if input compresses slowly, submission will timeout.

waf blocking: if command contains pipes, redirects, or special shell syntax and returns HTTP 405 (WAF rejection), write command to a shell script and use bash run.sh as the command instead.

auto-retry on interruption: if job fails due to node preemption or resource reclaim, set max_reschedule_times to a positive integer (e.g. 2). bohrium will auto-resubmit the entire job (not resume from checkpoint). normal job failures do not trigger retry.

job_id vs job_group_id: CLI job operations (kill, terminate, download) use job IDs (e.g. bohr job terminate 22153612). job group operations use group IDs (e.g. bohr job_group terminate 15954383). these are not interchangeable.

env var missing: if $ACCESS_KEY or $PROJECT_ID are empty, check openclaw config at ~/.openclaw/openclaw.json under the bohrium-job section. ensure the keys exist and are not empty strings. re-source shell profile or restart terminal.

api call auth failure: if API call returns 403 or "invalid accessKey", verify os.environ.get("ACCESS_KEY") is populated. if using raw requests, ensure header is {"accessKey": AK}, not {"Authorization": "Bearer ..."}.

empty result set: if bohr job list returns nothing, check filters (e.g. -r for running only). if filtering by status, ensure status code is correct (0=pending, 1=running, 2=finished, 3=scheduling, -1=failed). if job was deleted, it will not appear in any list.

output contract

job submission: on success, bohrium returns a job ID (integer, e.g. 22153612). this ID is printed to stdout and is used for all subsequent operations (log, describe, terminate, download).

job list: output is a table with columns: job ID, job name, status, create time, update time. if --json flag is used, output is JSON array of job objects with all metadata.

job describe: output is job metadata including status, machine type, image address, command, input/output paths, create/update/finish times. if -l flag is used, output includes full logs and additional details. if --json is used, output is a single JSON object.

job log: if no download path specified, logs are printed to stdout (real-time for running jobs). if -o ./path/ is specified, logs are saved as text file in that directory.

job download: all result files specified in backward_files (or all files if backward_files is empty) are saved to the output directory. directory structure is preserved.

job management (terminate/kill/delete): on success, a confirmation message is printed (e.g. "Job 22153612 terminated successfully"). job record is updated immediately and visible in subsequent bohr job list calls.

job group operations: create returns the group ID. list returns table or JSON of groups with ID, name, create time, job count. download saves all job results to the output directory in subdirectories per job.

api calls: successful calls return JSON response with status 200. responses are documented in bohrium open API docs at https://open.bohrium.com/openapi/. error responses include status code and error message in JSON.

outcome signal

user knows the skill worked when:

1. job submitted: bohr job submit prints a job ID to stdout and returns exit code 0. user can then run bohr job describe -j <id> and see the job in "Pending" or "Running" state.

2. job listed: bohr job list displays a table with at least one row. user sees job names, IDs, and statuses. if filtered (e.g. -r for running), only jobs matching that filter appear.

3. logs viewed: bohr job log -j <id> prints job output to terminal or saves log file to disk. if job is running, new log lines appear in real-time. if job is finished, full log is available.

4. results downloaded: bohr job download creates output directory (if not exists) and populates it with result files. user can verify files exist and are non-empty with ls -la ./results/.

5. job terminated/killed/deleted: bohr job terminate/kill/delete command returns exit code 0. subsequent bohr job describe -j <id> shows status changed to "Completed", "Failed", or job is not found (if deleted). if job was running, it stops within seconds.

6. job group created: bohr job_group create prints a group ID and returns exit code 0. subsequent bohr job_group list includes the new group. user can submit jobs to this group with bohr job submit -g <id>.

7. api call successful: Python requests call returns response.status_code == 200. response JSON contains expected fields (e.g. job list contains array of job objects, job config returns token and paths).

---

credits: original skill authored by clawhub community. enriched per implexa quality standards with explicit decision points, edge case handling, environment setup guidance, and outcome signals.