cook-volatile

A normal cook recipe records every change between your stock and tuned file. That is great — unless the tune touched things that are different from car to car, like the VIN (the car's ID number) or the checksum stores. Two cars of the same software still have different VINs, so a plain recipe that includes those bytes fails on the other car.

cook-volatile fixes exactly that. It is cook with one extra step: it detects those volatile (car-specific) changes, excludes the near-certain ones from the recipe, and writes down what it excluded and why — evidence you can read and audit.

The result is a car-portable recipe: it applies to any car of the same software revision, not just the exact file it was cooked from.

cook-volatile only reads your two files — it never changes them.

When do I need it?

• Whenever the recipe may be applied to another car of the same software version (the usual tuning workflow).
• When the tune touched the VIN or checksum stores — a plain cook recipe would carry those car-specific bytes along.
• Only have the exact same binary to re-flash? Plain cook is enough.

Try it (2 minutes)

openremap cook-volatile stockA.bin stage1.bin --output portable.remap

You will see the usual build summary, and — unless you suppressed it — the list of volatile instructions that were reviewed:

  ✅ Recipe built successfully
  ...
  Recipe saved to portable.remap

(Output shortened. When volatile changes are found they appear in a volatile section of the recipe with their evidence — see the CLI page.)

Understanding the answer

Open the .remap file in any text editor — everything is human-readable and auditable.

For developers

cook_volatile (note the underscore in code) is one method of openremap.api:

Where to go next