Nodes/comfyui-minimax-h3-audio-T8/MiniMax H3 Creator Run Receipt / 候选运行回执 (Advanced/T8)
ComfyUI Node

MiniMax H3 Creator Run Receipt / 候选运行回执 (Advanced/T8)

Log what actually happened, so the plan can trust it

By T8mars·Created 2 months ago·Updated about 8 hours ago· 1,158
MiniMax H3 Creator Run Receipt / 候选运行回执 (Advanced/T8)
  • workspace
  • previous_ledger
  • ledger
  • event_json
  • ledger_json
  • report_json
◄run_position0►
◄variant_index0►
◄attempt_number1►
◄outcomecompleted►
◄prompt_id►
◄cache_observationunknown►
◄artifact_manifest_json{"video":{"path":"output/candidate.mp4"}}►
◄notes►

A retention plan is only as trustworthy as its evidence, and the evidence here is a run receipt: a record of what actually happened to one candidate, filled in by you (or an external executor) after the fact. MiniMaxH3CreatorRunReceiptT8Advanced logs a single observed outcome - completed, accepted, rejected, cancelled, failed - plus the attempt number, prompt ID, cache observation, and artifact metadata, and appends it to a running ledger. It never probes the queue and never mutates a cache. It just writes down what you tell it, which is the whole point: garbage receipts in, garbage plan out, and it's your garbage.

How it works

You chain receipts: the optional previous_ledger input lets each node append to the last one, so N receipts become an ordered ledger of N events. The outcome combo drives everything downstream - the Retention Plan node treats accepted candidates as keep-worthy and rejected/cancelled as proposed-delete material. run_position and variant_index say which shot/variant this receipt is about (they must match the workspace's numbering), and attempt_number distinguishes retries of the same candidate. cache_observation records whether a rerun hit a cached result - useful signal when you're wondering why a "new" render looks identical. artifact_manifest_json (default {"video":{"path":"output/candidate.mp4"}}) points at the actual file, and notes is your free-text excuse for why this one is garbage.

Outputs

ledger (the custom object that flows into Retention Plan or the next receipt), event_json, ledger_json (the whole ledger so far), and report_json. If nothing else, this node is a beautifully explicit audit trail for "did I ever render seed 3, and what happened to it."

Installing it

From the MiniMax H3 Audio T8 pack. Manager → search MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8

restart. No forced pip dependencies; you supply H3 weights/CLIP/VAE/LoRAs into models/ yourself. H3 weights carry the MiniMax H3 Community License (excluded territories: US, EU, UK, South Korea).

Where people slip

The most common mistake is treating the receipt as automation. It is not: nothing reads the queue or the cache to figure out what happened - you set outcome and prompt_id. If your ledger says everything is completed but it was actually a crash, that's on the data entry, not the node. Also watch the numbering: run_position/variant_index must line up with the workspace's indices or your Retention Plan will attach the receipt to the wrong shot. The pack would rather you abstain than misattribute - if you're unsure, cache_observation and notes exist precisely so the ambiguity survives in the record.

CategoryT8/MiniMax H3/Studio/Experimental

Inputs (10)

NameTypeDefaultDescription
workspaceH3_T8_CREATOR_WORKSPACE—
run_positionINT00–100000—
variant_indexINT00–63—
attempt_numberINT11–100000—
outcomeCOMBOcompleted5 options: completed, accepted, rejected, cancelled, failed
prompt_idSTRING—
cache_observationCOMBOunknown4 options: unknown, executed, cache_hit, partial_cache_reuse
artifact_manifest_jsonSTRING{"video":{"path":"output/candidate.mp4"}}—
notesSTRING—
previous_ledgeroptH3_T8_CREATOR_RUN_LEDGER—

Outputs (4)

NameTypeDescription
ledgerH3_T8_CREATOR_RUN_LEDGER—
event_jsonSTRING—
ledger_jsonSTRING—
report_jsonSTRING—