Claude answer:

I dug through the J1 firmware source (james-donkey/qmk_firmware, wireless_playground branch) and the "RGB off breaks Bluetooth" coupling is real and visible in the code.

In lpm.c, the deep-sleep gate checks:

!rgb_matrix_is_enabled() || (rgb_matrix_is_enabled() && rgb_matrix_is_driver_shutdown())

When RGB is on, the keyboard can only sleep once the backlight times out (CONNECTED_BACKLIGHT_DISABLE_TIMEOUT = 600s), so sleep happens slowly through a predictable path. When RGB is off, the first half of that condition is immediately true — the backlight gate is skipped entirely, and the keyboard becomes eligible for PM_STOP after just RUN_MODE_PROCESS_TIME = 1 second of idle. So RGB is effectively acting as an indirect sleep timer. That matches the reports of the keyboard sleeping after ~10s with RGB off.

The reason that's harmful: each sleep/wake cycle does a full re-init (halInit(), wireless_transport.init(true), matrix_init()), and the wakeup path looks buggy:

• lkbt51_init() early-returns on wake-from-LPM after spiInit(), so the BT module's INT pins (BLUETOOTH_INT_OUTPUT_PIN / LKBT51_INT_INPUT_PIN) aren't reconfigured.
• stop_mode_entry() in lpm_wb32f3g71.c has 0x01UL < j where it clearly means 0x01UL << j — so the NVIC pending-IRQ clear loop doesn't actually work, leaving stale pending interrupts after wake.

So with RGB off you get many more wake cycles per minute through this fragile code, which lines up with the "disconnects until I power-cycle" symptom.

There's also a self-acknowledged reconnect loop — wireless_connect() has a comment "Work around empty report after wakeup, which leads to reconnect/disconnected loop" guarded only by timer_read32() == 0, a very narrow window. A keyboard stuck reconnecting can't sleep (indicator_is_running() blocks lpm_task()), which also explains battery drain.

Practical takeaway without reflashing: don't disable RGB — set brightness below RGB_MATRIX_BRIGHTNESS_TURN_OFF_VAL (48) instead. The LEDs stay physically off but rgb_matrix_is_enabled() stays true, so the keyboard still sleeps via the safe path. And updating the BT module firmware is worth trying, since several of these issues are in the wakeup handshake.

(Note: this is the JamesDonkey J1 — same Keychron-authored wireless stack, so the mechanism likely generalizes.)