Dexy

Give coding-agent work its own cyberdeck.

Dexy is a concept for a modular cyberdeck, a portable computer with its own keyboard, screens and expansion ports, built for engineers who supervise coding agents away from a laptop.

It would pair an ARM Cortex-M55 coprocessor that logs serial buses all day, a Rockchip RK3588 with a 6 TOPS NPU for local search, and a hardware secure enclave (a TEE) that scrubs secrets before anything is indexed.

Nothing is built, so every figure here is a design target or a datasheet estimate.

I'm designing it alone, as industrial designer and systems architect. My bet is that agent work deserves its own tactile instrument, because the keyboard, screen and pointer have changed far less than the software they run.

The work now means supervising agent loops, probing hardware buses and reading endless terminal logs, all on one clamshell with one screen. Dexy would take that supervising, remembering and probing off the laptop and give it physical controls.

Stop adding windows. Build a separate instrument.

A separate device beats a bigger screen, because the laptop fails at three things agent work needs.

• The multi-window attention tax. IDEs, terminals, debuggers, inspectors, analyzer charts and chat channels compete for one screen, and switching drains mental state.
• Ephemeral development context. Stack traces, diagnostics, agent diff proposals and logic captures vanish when a terminal closes or a buffer rolls over.
• Heat and battery. Local embeddings, heavy compiles and several agent harnesses could drain a laptop in roughly 90 minutes by my estimate.

Mixing consoles in audio production and flight decks in aviation are my reference points: instruments built around one job. Dexy would give agent work the same treatment.

The cost is one more device to carry and charge. My test is blunt: "Would I still reach for the laptop first?" If yes, the instrument has failed.

Choose the clamshell cyberdeck over the monolith and the slate

The modular clamshell fits a deck that lives on a desk and travels in a bag, so I picked it over two other archetypes.

• The desktop companion monolith. A stationary console with rotary dials, status screens and macro pads.
• The ultra-compact handheld slate. A pocket-sized diagnostics console with a thumb-matrix keyboard, made for server aisles and telecom towers.
• The modular clamshell cyberdeck. An ortholinear mechanical keyboard, dual displays, 21700 cells and magnetic peripheral rails.

Weights are targets from the component choices. The battery lives are rough estimates that assume 21700 cells, and no cell capacity has been tested.

The catch? At 820g the clamshell is more than twice the slate's weight, and I'm paying that for battery, keys and rails. If the deck will live on ladders and in server aisles, the slate wins.

Each reason for the clamshell comes with its price, because a decision without a cost is just a preference.

Mechanical ergonomics for deep work

Ortholinear mechanical switches in hot-swap sockets should give tactile precision over long coding sessions. The cost is a layout most people don't type on today, so I'd expect a learning curve.

Thermal headroom

A CNC-machined aluminum chassis would act as a passive heatsink and should allow sustained compute without fan noise. That claim is untested, and the chassis is part of the 820g target.

Modular peripheral bus

Standardized magnetic click-rails on the chassis flanks would support hot-swappable hardware pods without cable clutter.

The first prototype check I'd run is whether I can swap a pod with one hand and no cable. If I can't, the rail has failed.

The sketch below shows how I picture a telemetry packet crossing the bus, with a timing field that fits each one (UART uses a baud rate, CAN a bitrate, I2C and SPI a clock frequency).

// hardware/bus-controller.ts (design sketch, not working firmware)
type BusConfig =
  | { channel: 'UART'; baudRate: 115200 | 921600 | 3000000 }
  | { channel: 'CAN'; bitrate: 500_000 | 1_000_000 }
  | { channel: 'I2C' | 'SPI'; clockHz: number }
 
export type TelemetryPacket = BusConfig & {
  payload: Uint8Array
  timestampUs: bigint
}
 
export function describePacket(packet: TelemetryPacket): string {
  const timing =
    'baudRate' in packet ? `${packet.baudRate} baud`
    : 'bitrate' in packet ? `${packet.bitrate} bit/s`
    : `${packet.clockHz} Hz`
  return `[${packet.channel} @ ${timing}] payload bytes: ${packet.payload.byteLength}`
}

Three tradeoffs shaped the hardware.

Resolving three tradeoffs produced the stack below.

┌─────────────────────────────────────────────────────────────┐
│                 Dexy Chassis & Compute Stack                │
├─────────────────────────────────────────────────────────────┤
│  [ Low-Power Cortex-M55 ]  →  Always-on bus logging (<0.2W) │
│  [ Rockchip RK3588 NPU  ]  →  Local vector search (<5.0W)   │
│  [ Wi-Fi 7 / 5G Bridge  ]  →  Remote workstation offload    │
│  [ Hardware TEE Enclave ]  →  Secret & token scrub pipeline │
└─────────────────────────────────────────────────────────────┘

Give each job to the cheapest chip.

Three tiers keep the battery alive, because a quantized 14B parameter model running all day would draw an estimated 35W to 50W and flatten standard cells in under two hours.

Think of a hotel at night. One porter stays awake on a small wage, watching the door and writing things down. Specialists handle the jobs that need them, and the heavy paperwork goes to head office.

1. Always-on telemetry coprocessor, an ARM Cortex-M55. Targets less than 200 mW to monitor serial buses, log terminal inputs and read the physical dials.
2. Local neural accelerator, a Rockchip RK3588 with a 6 TOPS NPU. Would handle local vector embeddings, OCR parsing and fast semantic indexing within a 5W target envelope.
3. High-speed network offload over Wi-Fi 7, 5G or a PCIe bridge. Would send heavy code synthesis and multi-agent loops to a remote workstation or cloud cluster.

The cost is dependence. Heavy synthesis needs a network link and a remote machine, so on its own Dexy is a supervisor, not a workhorse.

Scrub secrets before anything is indexed.

Everything captured would pass through a scrubber before it reaches the search index, because real terminals hold API tokens, SSH keys and proprietary source code.

Dexy would integrate an on-chip Trusted Execution Environment (TEE) that would parse every captured log through a sanitizer running in the secure world. This part of the design is not yet validated on hardware.

High-entropy strings, RSA/ECDSA key patterns, database connection strings and credential variables would be replaced with keyed hashes (HMAC) before reaching the local vector index.

A plain hash is a poor choice, since anyone can hash guesses at a low-entropy secret and compare.

A key that never leaves the enclave would stop that, and the same secret would still map to the same placeholder, so search would keep working.

The catch? A sanitizer only catches the shapes it knows. I expect the hard part to be the secret that doesn't look like one.

My test: if I wouldn't paste a log line into a public chat, it shouldn't reach the index unscrubbed.

Carry the lab on the rails, not in a bag.

Magnetic rails would replace the bag of instruments, each with its own cable. Dexy would have precision-machined magnetic rails along its perimeter that would supply 12V power, USB 3.2 differential pairs, and SPI/I²C/UART signaling to hot-swappable pods:

• Logic Analyzer Pod: 8-channel 500MHz digital logic analyzer for embedded signal decoding.
• SDR Transceiver Pod: Sub-6GHz software-defined radio for RF diagnostics.
• Industrial Bus Pod: Isolated RS-485, CAN-FD, and optical UART interfaces for industrial control systems.
• High-Density Storage Pod: Dual M.2 NVMe slots for multi-terabyte offline datasets.

Count what's missing. None of the four pods is a multimeter. And since nothing is built, I can't say whether a pod beats the bag it replaces.

A prototype would settle that (ideally before anyone climbs a ladder with it).

Dexy OS: make the terminal remember, and make approval physical

Dexy OS would be a lightweight Linux distribution tuned for low-latency terminal use and continuous agent monitoring. It has two jobs: remember what happened, and put a hand between an agent and anything destructive.

Engineering Moments: semantic memory for the terminal

Infinite, unorganized scrollback is the default. Dexy would group terminal operations into discrete "Moments" instead, pairing command inputs, execution outputs, compiler errors and git diff snapshots into semantic cards. The output below is a mockup.

# Illustrative output (concept mockup): natural language search over past engineering moments
$ dexy query "the rust borrow checker error when compiling the packet parser"
Found Moment #142 (Yesterday, 16:42) in crate::net::protocol:
  → error[E0502]: cannot borrow `buffer` as mutable because it is also borrowed as immutable
  → Diff proposal by Claude Code: applied in commit 4f8a29c

The bar is simple. If one natural-language query can't find last week's compiler error, the memory has failed.

Physical agent dials and hardware interlocks

Rotary encoders and illuminated toggle switches would let engineers adjust agent autonomy, step through agent actions turn by turn, and approve destructive bash commands with a tactile click.

The cost is speed: an agent that waits for a human hand is slower, and that's on purpose.

What Dexy won't do, and what I haven't verified

A concept has a long list of limits, so here they are up front.

• It isn't built. Every weight, battery and power figure is a target or a datasheet estimate, including the less than 200 mW and less than 5 W budgets.
• It won't run a big model locally all day. Heavy synthesis would go to a remote machine, which needs a network.
• The TEE sanitizer isn't validated on hardware.
• The pods are specs, not parts, and the bus code above is a sketch.

What I believe, and what I'd build first

I believe tactility would help: rotary controls, mechanical switches and a secondary display should give engineers a more direct hold on their software than floating windows do.

Hardware also has no hotfix (every millimeter and milliwatt forces a priority call).

If I build it, the risky parts go first: the always-on tier, because the less than 200 mW budget and the battery target depend on it, then the TEE sanitizer.

For a related project built around coding agents, see Claudey.