A few days ago, Vaibhav Sisinty posted something on X that stopped my scroll: someone had wired up an actual, physical stick shift to switch between Claude models. Not a settings menu. Not a dropdown. A gear shifter, like the one in a car, sitting on a desk.
Fable 5 in one gear. Sonnet in another for daily driving. Opus when the problem needs real depth. Slam the stick into position, and the model underneath your workflow changes.
The detail that makes this more than a novelty: he built the shifter with Claude, specifically to make his own use of Claude faster. That's a nice little loop — using the model to remove friction from using the model.
Why this is a smarter idea than it sounds
On the surface it's a gimmick. Under the surface, it's solving a real problem that every heavy AI user runs into: model selection is a decision tax.
Every time you open a chat and have to think "is this a Sonnet task or an Opus task?", you're spending attention on meta-work instead of the actual problem. It's a tiny cost, but it's a cost you pay dozens of times a day, and it never shows up on any productivity dashboard. A physical control collapses that decision into a single motor action — the same way a car driver doesn't consciously reason about gear ratios, they just feel the road and shift.
That's the actual insight here: the best interface for a decision you make constantly is the one that requires the least conscious thought. A menu makes you look, read, decide, click. A physical lever makes you feel and move. For something you do fifty times a session, that difference compounds fast.
A plausible look at how something like this comes together
Nobody's published exact wiring diagrams here, but the architecture almost writes itself if you've worked with hobbyist hardware and API-based model switching. Here's roughly what a build like this involves:
1. The physical input layer
A repurposed automotive or sim-racing shifter has a set of positions, each one closing a different switch or landing on a different potentiometer value. A microcontroller — an Arduino or a Raspberry Pi Pico is the obvious choice — reads which gear the stick is in. Three or four gears is plenty: one per model tier.
2. Signal to software
The microcontroller reports the gear position over USB serial (or Bluetooth, if you want it cordless) to a small script running on the host machine. This script's only job is to watch for a gear-change event and translate it into a model selection: gear 1 → Sonnet, gear 2 → Opus, gear 3 → Fable, that kind of mapping.
3. Where the switch actually takes effect
This is the part that determines how "real" the integration feels. There are a couple of reasonable approaches:
- API-side: the script updates which model string gets passed on the next request (e.g. through the Claude API), so whatever tool or wrapper you're using picks up the new model on the next call.
- Client-side automation: the script simulates the click that a person would make in a chat interface's model picker, effectively doing the menu navigation for you at hardware speed.
Either way, the mental model is the same: the shifter isn't talking to Claude directly — it's talking to a small piece of glue code, and that glue code is the one actually making the model swap happen.
4. Feedback so it doesn't feel like flying blind
The nice builds add a confirmation layer — an LED that changes color per gear, or a short status readout — so you always know which model is currently live without having to check a screen. This matters more than it sounds like it should. Without feedback, a physical control just becomes a fancier way to be unsure what you clicked.
The part worth sitting with
What I like about this project isn't the soldering. It's the underlying behavior it encourages: being deliberate about which model you reach for, instead of defaulting to whatever's already open in the tab. A lot of us just use whichever model loaded last, regardless of whether the task in front of us actually needs deep reasoning or just needs to move fast.
A gear shifter forces a tiny moment of intention before every switch. That's a UX pattern worth stealing even without the hardware — a keyboard shortcut, a CLI alias, a quick-switch panel, anything that makes "pick the right tool for this task" take less effort than "just use what's already open."
And it's a good reminder of something easy to forget: sometimes the most interesting AI projects aren't about the model at all. They're about designing a better on-ramp to it.
Top comments (0)