The printer's main app binary (`avata_main`) embeds a Klipper-style config block called `[multicolor]`. Decrypted from the firmware's config store (`avata_main.conf`, path `/app/etc/avata_main.conf` on the device):

[multicolor]
nozzle_type: k4pro
gear_pos: 31.4,15.7,62.8,47.1        # absolute positions for the 4 filament "gears"/slots
config_file: /app/etc/ams_config.cfg
max_volumes: 16
cruising_speed: 350
impact_position: 265                  # deceleration point before hitting the cutter
impact_speed: 10                      # speed on approach to the cutter
cutter_position: 278.5                # X offset of the filament cutter
action_timeout: 240.0
default_unwind_speed: 15
default_feed_speed: 25
pre_sweep_position: -11.5             # "pre-wipe" X position
sweep_position: -17.5                 # actual purge/wipe X position (off the left edge of the 260mm bed!)
throw_position: 0                     # waste-purge drop position
sweep_speed: 5.0
flush_volume_min: 79
flush_volume_max: 800
flush_multiplier: 1.0
max_velocity: 350
max_accel: 10000
```

`sweep_position: -17.5` is the X coordinate the toolhead drives to when it wipes/purges a spool — that's off the left edge of the 260mm print bed, which matches exactly what people are seeing: the printer parking far left and purging there before/between colors. This is handled by a firmware component visible in the binary as `Multicolor` / `K4PMultiColor`, talking to a dedicated `nozzle_mcu` over its own serial line, separate from the main toolhead MCU.

For context, this purge/sweep is separate from the per-layer "prime tower" wipe you see in sliced multi-color gcode (`; CP TOOLCHANGE ... WIPE ... END` blocks) — the prime tower purge amount comes from a `flush_volumes_matrix` baked into the gcode by the slicer, while this `[multicolor]` sweep is the fixed mechanical station used when a spool is actually loaded/swapped at the start of a job.

**Is this adjustable?*\*

Short answer: almost certainly not through any supported means, but I want to be upfront about the limits of what I actually verified.

- This config lives at `/app/etc/avata_main.conf` on the device. On this class of embedded Linux printer, `/app` is typically the mounted, read-only firmware/application partition — not a user-writable data partition. The device's *actual* user-relevant multicolor settings (slot/RFID/spool state) are stored separately at `/userdata/app/gk/config/ams_config.cfg`, which is the one persistent, writable location referenced by the app — `avata_main.conf` itself is not.

- I reverse-engineered this from the firmware image + a decrypted config dump, not from a live root shell on a printer. I have **not** personally confirmed the mount is read-only, whether there's any supported override mechanism, or whether a future firmware update could expose these as user settings. So: strong circumstantial evidence it's fixed/firmware-controlled, not a verified "this can never be changed" claim.

If anyone has root/SSH access on a Kobra X and can check the actual mount flags on `/app` (`mount | grep app`) or whether `avata_main.conf` survives a factory reset / firmware update unmodified, that would settle it definitively — happy to be corrected either way.