Skip to main content

Can a third-party app drive per-key RGB on the Creator Micro 2?

Feature Request

Hi Work Louder team,

I've just ordered a Creator Micro 2 Pro.
Before it arrives I'd like to check what's possible on the host side, so I build the right thing rather than guess.

I'm writing a small local macOS app for my own use that supervises coding-agent sessions - conceptually the same job the Codex Micro does for Codex, but for a different tool and running entirely on my own machine.
Mapping keys to actions is straightforward with Input.
What I'd like to know is whether the feedback direction is available to me: lighting individual keys from my own app to show live status, the way the Agent Keys work on the Codex Micro.

Three specific questions:

  1. Does the Creator Micro 2 expose a raw HID interface (QMK-style usage page 0xFF60, or any vendor-specific interface) that a third-party host application can open and write to?

  2. Is there a supported or permitted way to set per-key RGB from a host app — an Input API, a documented report format, a local socket, anything? I understand the Codex integration is a specific partnership; I'm asking about the general capability, not access to that integration.

  3. If nothing exists today, is it something you'd consider? A documented "set key N to colour X" channel would make the Micro the obvious controller for any agent-style tool, not only Codex — that seems like it's in your interest as much as mine.

Also useful to know, if you can say: is the Creator Micro 2 firmware QMK/VIA-based like the original Creator Micro, or a different stack? I noticed the v2 isn't in QMK mainline, so I don't want to assume.

Happy to be pointed at docs if these are already answered somewhere — I couldn't find them.

Thanks,

Paulo

Product
Creator Micro v2
Posted by Paulo Ribeiro ·
Status: Planned13 comments

Log in to comment and vote

Comments13

  • Paulo Ribeiro

    •

    Jul 26

    Update — I found a lot of this answered elsewhere on the board, so let me narrow the ask.

    From other CM2 owners' reports I can see the device exposes an RPC over HID (v.oai.rgbcfg, v.oai.thstatus, and Input's own lights.preview / fs.writebin), and that v.oai.rgbcfg succeeds on stock v0.4.0 firmware even when Codex initialisation fails on the missing thstatus. I also saw Davide's note that Codex support needs beta firmware 0.6.0 + Input 0.18.0 + a Codex layer. That's genuinely helpful.

    So my question is no longer "is it possible" but "is it safe to build on":

    1. Is the vendor RPC considered private and subject to change without notice, or would you be willing to document and keep stable a minimal subset — realistically just "set key N to colour X"?

    2. If a third-party app drives key lighting, how is ownership arbitrated? I've seen the report that ChatGPT takes global RGB control and overrides Input's per-layer settings. Is there a documented way to acquire and release lighting control cooperatively, so a third-party app, Input, and ChatGPT don't fight over it?

    I'm not asking for access to the Codex integration — just enough stability guidance to know whether to build on the RPC or treat it as best-effort and expect it to break.

    Thank you.

    • Davide // Work Louder

      Team•

      Jul 29

      Hello @Paulo Ribeiro the current implementation is private to the OpenAI and could change without notice. We’re considering a public implementation but I cannot 100% confirm it as of now

      • Paulo Ribeiro

        •

        Jul 29

        Hi David,

        I think it would be a great idea to have a public implementation because it would maximize the number of coding agents that your hardware could be used with and as you most certainly know there are others that are as big as OpenAI and would benefit from using this solution that is quite interesting.

        Let me know if there is any development in that area.

        Thank you.

      • Balázs Barta

        •

        Aug 1

        @Davide // Work Louder I'd like to see per-key RGB on CM2. It doesn't need to be app driven just to be able to assign colors to individual keys (or to actions). Using the new transparent keycaps users would be able to assign a color for each button per layer so it will be much much easier to recognize/learn actions/macros.

  • Aljosa Asanovic

    •

    Aug 15

    You can get this working@Julian Ozen, I have a herdr plugin you can use as an example

    https://github.com/alasano/house-of-herdr

    You basically need to hijack the first layer (and have codex closed) because only the first layer has per button light controls and interactivity. But you should be able to just point your agent at my repo to the codex-micro plugin and ask it to implement yourself something just for Claude if you want it.

    Otherwise if you use Herdr you can just use the plugin and it will work for Claude/Codex CLI/Pi/etc all harnesses that Herdr supports.

  • Bill Papas

    •

    Aug 3

    I want to be able to change RGB colors for keys on the fly. For coding agents, For app notifications, and also to for me to know which app I am launching when I hit the button. Please make this a public implementation

  • hazel zhang

    •

    Aug 6

    Same here, would really love to have per-key RGB. And I really think you SHOULD have it.

    The landing page of Creator Micro v2 highlights the AI Agent controller with keys of different backlights based on agent status, which is what I wanted to build on. But I got the keyboard, after a couple hours of trying, finding out the per-key RGB only works for Codex. No per-key RGB API for other agents.

    And I ended up seeing this post. It is really frustrating. Your marketing page is really misleading.

  • Julian Ozen

    •

    Aug 15

    I dont believe this is possible. I am trying to get this set up in claude code today

  • Lance Herron

    •

    Aug 30

    Do we know when this will be supported? I just pre-ordered the frosted keycaps. Will be awfully disappointed if they arrive and still no per-key lighting options.

  • Oleksandr Diudiun

    •

    Sep 13

    It would also be helpful to ensure that the layer remains editable in the Input app when controlling the key light with a third-party application. Currently, if I add a custom key code to any layer, such as KV_OAI_AG*, it blocks the entire layer from edit mode in the Input app. If the key code is unfamiliar to the Input app, it can display “Custom Key” or a similar label but per key not per layer.

  • Gustavo Stor

    •

    Sep 23

    This would be REALLY nice!