I Turned a 2013 Google Glass Into a Claude Code Terminal

I have access to a first-generation Google Glass Explorer Edition.

Not the vaguely useful later enterprise version. The original 2013-era Glass: OMAP4430, tiny battery, tiny display, ancient Android, and enough compute to make a Raspberry Pi look extravagant.

It is not mine. I just have access to it, which is apparently enough permission to start making bad decisions.

Naturally, I wanted to run Claude Code on it.

Obviously I was not going to actually run Claude Code on it. That would be stupid.

What I wanted was the experience of putting on Glass, looking up, and having my real development terminal sitting there. I wanted to be able to talk into it, have my speech show up in Claude Code, and watch Claude work without pulling out a laptop.

The interesting part turned out to be how little software Glass itself actually needed to run.

Glass should be a terminal, not a computer

The first mistake with projects like this is trying to make the old hardware do things it has absolutely no business doing.

Glass does not need Node. It does not need Git. It does not need Claude Code. It does not need a local LLM. It definitely does not need Whisper.

It needs to do five things:

display text
capture audio
detect a button
move bytes over Wi-Fi
run SSH

That's it.

Everything expensive happens somewhere else.

My workstation already has my repositories, Claude Code, compilers, Docker, Git, tests, credentials, and all the other garbage accumulated by an actual development environment.

So Glass became a very thin client for that machine.

The core setup is almost offensively simple:

Google Glass
     |
     | SSH
     v
development workstation
     |
     v
tmux session
     |
     v
Claude Code

The persistent tmux session is called glass.

Glass SSHes in and attaches to it.

Claude Code runs inside that session exactly as it would if I were sitting at my desk.

There is no special Claude integration on Glass at all.

tmux is doing most of the magic

The part that makes this actually usable is tmux.

Wearable computers are shitty network clients.

Glass goes to sleep. Wi-Fi disappears. Android kills things. Batteries die. You walk outside. You walk back inside. Some 13-year-old component decides it has suffered enough.

I do not want any of that to matter.

If Glass owned the shell session, every disconnect would murder whatever I was doing.

Instead:

Glass disconnects
       |
       X

tmux + Claude keep running

Then when Glass comes back:

SSH
 |
 v
tmux new-session -A -s glass

and I'm exactly where I left off.

That means the Glass unit is effectively disposable from the session's point of view.

Reboot it. Kill Termux. Walk out of Wi-Fi range. Whatever.

Claude does not care.

This also means I can attach to the same session from a normal terminal when I need to unfuck something.

That turned out to matter.

Getting Glass to boot into something useful

The Glass is running the community Android 5.1.1 build rather than the original Glass OS.

I unlocked it, rooted it, and modified the boot image so Android launches Termux after boot.

The intended boot sequence is basically:

power on
   |
Android boots
   |
Termux starts
   |
wait for network
   |
SSH
   |
attach tmux

At that point Glass stops behaving like a novelty Android device and starts behaving more like an appliance.

That's what I wanted.

I do not want a launcher.

I do not want to swipe around looking for an app.

I want to put the stupid thing on my face and get a terminal.

There is one mundane problem here that becomes very obvious once you automate the boot: Android finishes booting before Wi-Fi necessarily finishes connecting.

So the terminal bootstrap cannot just immediately SSH once and give up.

It retries until the workstation is reachable and then attaches to the session.

Not interesting. Completely necessary.

Then I wanted to talk to it

A tiny terminal display is useful.

Typing on Google Glass is not.

The obvious next step was voice input.

Again, Glass should not do the expensive part.

Trying to run useful Whisper inference on an OMAP4430 would be less "edge AI" and more an elaborate cry for help.

I already have another machine on my network named fenchurch. It runs Void Linux, which is also what I use on my main workstation. There is no special reason Whisper needs Void; it is just the Linux I already run, and it makes fenchurch a very simple little speech-to-text box with essentially nothing between the microphone stream and whisper.cpp.

So the audio path looks like this:

Glass microphone
      |
      v
raw audio
      |
      v
fenchurch
      |
      v
whisper.cpp
      |
      v
text
      |
      v
tmux
      |
      v
Claude Code

fenchurch runs whisper.cpp on CPU.

Glass records roughly the sort of audio Whisper wants anyway: mono PCM around 16 kHz.

There was no reason to build a fucking distributed audio platform for this.

I considered various transports and eventually arrived at the usual conclusion:

Use the dumbest thing that works.

Raw audio over a socket is fine.

SSH piping is fine.

I don't need Kafka for a pair of eyeglasses.

The camera button became push-to-talk

Original Glass has a physical camera button on top.

I have essentially zero interest in taking pictures with this thing.

A physical button on a wearable, however, is extremely useful.

So it became push-to-talk.

The interaction is:

hold camera button
        |
record

speak

release button
        |
stop recording
        |
send audio
        |
transcribe
        |
inject text

That feels surprisingly natural.

The camera button also gives the microphone an explicit state.

I do not particularly want a Glass microphone continuously shipping everything happening around me to a speech recognizer just so I can occasionally tell Claude to run a test.

Push-to-talk solves that without needing some elaborate wake-word daemon running on prehistoric hardware.

Speech recognition was the easy part

Once whisper.cpp gives me text, I have to put that text into the existing Claude terminal.

The naive version is something like:

ssh workstation "tmux send-keys -t glass '$TEXT' Enter"

Do not do that.

Speech can contain quotes.

Speech can contain dollar signs.

Speech can contain semicolons.

Speech can contain backticks.

Speech can contain something that happens to look exactly like shell syntax.

And eventually Whisper will hallucinate something weird enough to make you regret treating arbitrary transcription as executable command construction.

The transcription should be data.

So I send the text through stdin, load it into a tmux buffer, and paste the buffer into the session.

Conceptually:

printf '%s' "$TEXT" |
ssh workstation '
    tmux load-buffer - &&
    tmux paste-buffer -t glass &&
    tmux send-keys -t glass Enter
'

Now the text lands in Claude exactly like pasted keyboard input.

It is not being reparsed as part of some shell command I dynamically constructed.

This is a small implementation detail that becomes a fairly important implementation detail the first time you dictate something involving shell metacharacters.

The return path required basically nothing

This is probably my favorite part of the whole design.

There is no response API.

There is no custom renderer.

There is no "Claude Glass client."

Claude writes text to a terminal.

The terminal is inside tmux.

tmux is attached over SSH.

SSH is displayed by Termux.

Termux is on Glass.

Done.

Claude
  |
terminal
  |
tmux
  |
SSH
  |
Termux
  |
Glass display

Anything that works in the terminal works on Glass.

Claude responses.

git diff.

Test output.

Compiler errors.

Logs.

Interactive prompts.

All of it.

The least sophisticated component in the system is Glass, which is exactly how this should work.

The topology ended up looking like this

                 GOOGLE GLASS
              +----------------+
              | terminal       |
              | microphone     |
              | camera button  |
              +-------+--------+
                      |
            +---------+---------+
            |                   |
          SSH               microphone
            |                   |
            v                   v
 +-------------------+   +------------------+
 | dev workstation   |   |    fenchurch     |
 |                   |   |                  |
 | tmux: glass       |<--| whisper.cpp      |
 | Claude Code       |   | speech -> text   |
 | Git / Docker /    |   +------------------+
 | compilers / etc.  |
 +-------------------+

Away from my LAN, I can put the network behind WireGuard rather than exposing any of this shit directly to the Internet.

Glass does not need to know or care whether the workstation is three feet away or across the country as long as it can reach SSH.

This works because I stopped trying to make Glass smart

I think this is the generalizable part.

Old hardware projects often turn into a contest to cram modern software onto hardware that hates you.

Sometimes that is fun.

But it is usually not how you make the hardware useful.

Google Glass still has several things going for it.

It is wearable.

It has a heads-up display.

It has Wi-Fi.

It has a microphone.

It has physical controls.

It can run enough Linux-ish userspace to speak SSH.

Those properties have aged much better than its CPU.

So instead of asking:

Can this 2013 computer run a 2026 AI coding environment?

I asked:

What is the smallest piece of a 2026 AI coding environment that actually needs to run on my face?

The answer is almost nothing.

Glass is just a window into the real machine.

That makes the absurdity of the hardware mostly irrelevant.

The result is a 13-year-old Google Glass that boots directly into a persistent Claude Code terminal, lets me dictate prompts with a hardware push-to-talk button, sends the audio to Whisper on another machine, injects the transcription safely into tmux, and shows Claude's response back in the display.

It is ridiculous.

It is also genuinely useful.

And, as far as I can tell, this may be the first productive thing anyone has done with Google Glass in years.