This is Part 5 in a series about a LED diabetes dashboard I built for my daughter Abigail. It shows her glucose, insulin, and weather on a 64x64 display, with an AI agent that offers short supportive observations. Part 1 covers building it. Part 2 adds insulin tracking. Part 3 introduces the AI insights agent. Part 4 refines it after a stressful night.

I used an agent framework where a single prompt would have done the job. The overkill was on track to cost me $1,700/month.

I built the insights agent using AWS Bedrock Agents. Bedrock Agents is a framework for building autonomous AI workflows where the model decides which tools to call, in what order, based on a conversation. It’s great for complex, fluid tasks where the reasoning path isn’t known in advance.

My task was not complex or fluid. I needed to take diabetes data, inject it into a prompt, and get a 30-character insight for an LED display. The same data, the same prompt structure, every time. A one-shot inference call.

Instead, I built a multi-turn agent with four action groups, OpenAPI schemas, IAM roles for each tool, and agent alias versioning. The agent would decide to call getRecentGlucose, then getDailyStats, then getRecentTreatments, then getInsightHistory, then storeInsight. Each roundtrip resent the full prompt and accumulated context. Five calls, each one bigger than the last.

One Prompt Instead of Five

The fix was simple. Instead of letting the agent orchestrate its own data gathering, each Lambda pre-fetches the data it needs from DynamoDB, formats everything into a single prompt, and calls Claude once via InvokeModel. One request, one response.

I (with Claude Code) replaced the entire Bedrock Agent framework with a shared invoke-model.ts utility of about 80 lines. Deleting 2,559 lines of code is always satisfying.

Bedrock Agents are super cool. I’ll definitely build more agents on this service where I have more ambiguous tasks. But for a predictable prompt/response cycle where I know exactly what data the model needs, one-shot inference worked way better. Faster, cheaper, and about 80 lines of code instead of 2,559.

Post-deploy results after a full day of production data: zero errors, 32 insights generated, quality unchanged. Cost: roughly $1/day, down from $58/day.

Rate Limiting

The architecture wasn’t the only inefficiency. The agent ran on every CGM reading: 288 per day, one every 5 minutes. Most invocations replaced a still-relevant insight minutes later.

I replaced the 5-minute debounce with smart triggers that only generate a new insight when something actually changes: enough time has passed, glucose moves significantly, or glucose crosses a zone boundary. This cut invocations from 288/day to about 36.

I also tried switching from Claude Sonnet 4.5 to Haiku 4.5, figuring short LED insights didn’t need the bigger model. That didn’t go well, at all. Haiku hallucinated constantly. “Steady drop since 8pm” when the data showed 25 minutes of decline. “Great overnight!” when she’d been high for hours. It would confidently describe glucose patterns that weren’t in the data at all. For anything involving medical data, even short observations, grounding matters more than speed. I switched back to Sonnet the same night.

The nice thing: with rate limiting cutting volume by 87%, Sonnet at 36 invocations/day cost less than Haiku at 288/day. I didn’t have to compromise on quality to fix the cost problem.

Quality Fixes

I fixed several quality issues along the way.

Repetition. I analyzed 2,477 insights over a week and found a 54% repeat rate. “Best day this week!” appeared 260 times. The agent was copying example phrases from its prompt verbatim. I removed the examples, banned generic praise, and added a storage-layer dedup that rejects exact duplicates within a 6-hour window.

Timezone. Lambda runs in us-east-1, and the agent was using UTC hours from Date.getHours(). Noon Pacific is 8 PM UTC. The agent would say “evening going well!” at lunchtime. Fixed with Intl.DateTimeFormat using America/Los_Angeles.

What It Looks Like Now

The display looks the same. Same 30-character insights in green, yellow, red, and rainbow. Same supportive voice noticing patterns. Abigail doesn’t know anything changed, which is exactly right.

The original dashboard ran for $4/month. The insights agent blew that up to $1,700/month. Now it’s about $30/month total: the original infrastructure plus one-shot inference at a sensible rate. The codebase is 2,559 lines lighter, the insights are less repetitive, and the agent knows what time zone it’s in.

Still open source on GitHub.

– John

Yesterday I wrote about adding an AI insights agent to the diabetes dashboard. Getting it to sound human was the hard part. Since then, I’ve been teaching it to think more like we do.

Tonight

Abigail broke routine after school. A new dance class and a goldfish snack were all it took to spike high. It happens. We loaded her up with insulin all evening to bring her back down. After she went to bed, it became clear we’d overshot the correction. Also happens. Normally not a huge deal, we just had to wake her up and give her some sugar.

The first wakeup went fine. She took the juice, we waited. But it wasn’t enough. She kept dropping.

By the second wakeup she was low enough to feel it. Disoriented, uncooperative, and very unhappy to be woken up. This is when it gets scary. We had to hold her down and push honey over her screams. Sometimes it’s not gentle coaxing and juice boxes. Sometimes it’s restraining your screaming kid because the alternative is worse.

Eventually the sugar kicked in. She rebounded hard, then leveled off. Actually stable.

After she started to come up, the display said “SMOOTH LANDING!” Only it wasn’t. Not yet. She was barely out of the woods and climbing fast. The insight was wrong, the opposite of useful after a stressful situation.

The Gap

The obvious problem: no intelligence about rate of change. The insights were over-indexed on the current value, not the trend.

After treating a low with sugar, glucose often spikes. Easy to overcorrect. A rise from 78 to 105 in a few readings isn’t a “smooth landing.” It’s a rebound that might overshoot high. The agent was celebrating these rebounds. “Coming up nicely!” when the trajectory suggested she’d blow past 200.

The same problem works in reverse. A glucose reading of 115 and dropping doesn’t tell you much by itself. But 115 dropping and slowing down is good news. That’s a landing. 115 dropping and speeding up is a problem. Same number, opposite actions. The agent would see a drop from 150 to 130 to 120 to 115 and say “Still dropping, eat!” That’s false urgency. The drop is decelerating. She’s leveling off.

What “Stable” Actually Means

A subtler problem: the agent didn’t know what stable really means.

It was saying “leveling off nicely!” when glucose was still drifting toward a low. 80 and dropping slowly isn’t stable. It’s still dropping. But the agent saw the number in range and celebrated.

This matters most near the edges. At 78 and still drifting down, even slowly, “leveling off” creates false confidence. Stable means truly flat readings: two to three consecutive readings within ±3 mg/dL. That’s when “FINALLY STABLE AGAIN!” actually means something.

How the Refinements Happen

So I fired up Claude Code and together we refined the agent prompt to take all of this into account.

The cycle: I see a situation, note what the insight should have been, and Claude iterates on the prompt.

The agent says “Smooth landing!” during a steep rebound. Should have been: “Coming up fast, watch it.” Claude adds guidance about post-low spikes and overshoot risk.

The agent says “Leveling off!” while still drifting down. Should have been: “Still drifting, more?” Claude adds guidance that stable means flat for 2-3 readings.

The agent creates false urgency during a decelerating drop. Should have been: “Leveling off nicely!” Claude adds guidance to factor in acceleration, not just direction.

It’s iterative. The prompt grows more specific with each edge case, with explicit FORBIDDEN examples for each failure mode.

Capturing the Reasoning

To make this cycle easier, I have the agent record its thinking with each insight so I can review it later and iterate accordingly.

Bedrock Agents don’t enforce required parameters, so even with emphatic prompts the agent wasn’t passing reasoning through the tool. But it does explain itself in its conversational response. So I parse that out and store it alongside the insight.

Insight: "[green]Leveling off nicely![/]"
Reasoning: Glucose dropped from high→less high→almost normal over
the past hour, but the rate is decelerating. Each reading shows a
smaller drop than the last. This is a landing pattern, not a
continuing fall. Celebrating the deceleration, not warning about
the direction.

Insight: "[yellow]Coming up fast![/]"
Reasoning: Post-low rebound in progress. Glucose was 72 twenty
minutes ago, now 118 and still climbing steeply. This +46 rise
suggests overcorrection from treatment. Not celebrating yet
because trajectory points toward overshoot into high territory.

Insight: "[yellow]Still drifting, more?[/]"
Reasoning: Glucose at 81, down from 88 and 94. Still dropping
about 6-7 per reading. Not flat yet. Near the low threshold so
caution warranted. Suggesting additional carbs rather than
celebrating stability that hasn't arrived.

Now I can review not just what the agent said, but why it said it. Useful for debugging and for understanding when the logic needs refinement.

The Result

“BACK STEADY AFTER THAT!” acknowledges the journey. The agent saw the red spike in the chart, watched the recovery, and waited for truly flat readings before celebrating. It won’t confuse a rebound for a landing. It won’t panic during a decelerating drop. And it won’t claim stable when the drop keeps going slowly, like tonight.

That’s what I wanted: an agent that thinks about the situation the way we do.

I sure wish I could get real-time insulin data. The pump knows how much insulin is “on board” in these situations, which would help predict where things are headed. But Glooko syncs are delayed several hours. Something I’ll add the minute I can get my hands on real-time pump data. (Please please please give me API access to this, Insulet!)

Still open source on GitHub.

Part 5 replaces the agent framework with one-shot inference to save $1,700/month.

– John

The dashboard has a new feature: an AI that watches the glucose and insulin data, then offers short observations on the display. Not commands or clinical alerts, just a friendly voice that notices patterns we might miss.

Why an Insights Agent

Managing T1D means interpreting numbers constantly. Is this a trend or a blip? Did lunch hit harder than expected? Are overnight lows becoming a pattern? We do this interpretation all the time, but we can’t watch every moment (we try though).

I wanted a second set of eyes and some validation. Something that could look at the last few hours (glucose, insulin, carbs) and surface one helpful observation. Not a diagnosis or medical advice, just a nudge, “steady all morning, nice!” or “rising after lunch, pre-bolus next time?”

What It Feels Like

The display now has a voice. Glancing at it in the morning: “great overnight!” in green, a small celebration. After a rough lunch: “been high a while, bolus?” as a gentle check-in. Three days of tight control: “3 days in range!” cycling through rainbow colors.

It’s not a medical device. It’s not trying to be a doctor. It’s more like a friend who pays attention. Another person on the team that notices the patterns. A supportive cheer for the wins and gentle questions about the struggles.

The Hard Part: Making It Human

Thanks to Claude Code, getting the agent working was easy. It took most of the day, chugging away with me stopping to give feedback every 30 minutes or so, but it didn’t take much input from me to get going. Getting it to sound human took some tweaking and is where I felt my value to the project.

Claude’s first attempt yielded abbreviations. “Hi 4h avg230 now241”. Readable if you studied it, but robotic. It was building a telegraph, not a friend.

Second attempt: natural language with exact numbers. “Glucose 241, been high 3 hours, consider bolus.” Better, but clinical. Felt like a medical device, not a companion.

I kept giving feedback: more ranges, more questions, some color, gentle. Instead of “241,” say “over 200.” Instead of “need bolus,” ask “bolus?” A caring friend suggests, doesn’t command. The difference between “you should eat” and “hungry?” is everything when things are already suboptimal.

The final prompt required explicit FORBIDDEN examples. I literally had to tell Claude that “Hi 4h avg230” was “robotic garbage.” Subtle guidance wasn’t enough but we got there!

Colors for Emotion

Plain white text couldn’t convey tone. A celebration looked the same as a warning.

I added color markup the agent can use. Green for celebrations and wins. Yellow for caution when running high. Red for urgent situations like lows. And rainbow for big wins, cycling through colors character by character.

“steady all day!” in green hits different than plain white text. The display becomes expressive.

Colors are muted, about two-thirds brightness, so they don’t compete with the glucose reading. The number is still the star. The insight is a whisper, not a shout.

The Constraints

The LED display has room for two lines of about 15 characters each. 30 characters total. Every word counts.

The agent often generated 40, 50, even 80 characters despite the prompt. I added a retry loop: if the insight is too long, ask the agent to shorten it. Same session, same context, just “that was 45 chars, please make it 30.” Works most of the time. Force-truncate as a fallback.

Two lines also need to look balanced. “BEEN HIGH A FEW” + “HOURS” looks awkward. “BEEN HIGH A” + “FEW HOURS” looks intentional. The compositor now splits short text near the middle.

How It Works

I used this as an opportunity to learn AWS Bedrock Agents, something we’re also embracing at work. The agent runs Claude Sonnet 4.5 with access to the diabetes data in DynamoDB. It can query glucose readings, insulin doses, carb entries, and computed stats like Time in Range. Then it stores a short insight for the display.

DynamoDB Streams trigger the agent when new data arrives. Event-driven, not hourly cron. When Abigail’s CGM sends a new reading or Glooko syncs pump data, the agent runs within seconds.

What It Costs

The insights agent changed the economics. The original dashboard ran for about $4/month. With the agent analyzing every CGM reading, costs jumped significantly.

CGM readings arrive every 5 minutes, 288 times per day. Each agent invocation uses Claude Sonnet 4.5 on Bedrock at $3 per million input tokens and $15 per million output tokens. With the prompt, data queries, and responses, that adds up to roughly $40-50/month for the agent alone.

Worth it for us. The supportive nudges and pattern recognition add real value to daily diabetes management. But it’s no longer a $4/month hobby project.

What’s Next

That 10x cost jump needs work. Right now the agent runs on every CGM reading, even at 3am when we’re asleep and the numbers are steady. Smarter would be: only generate new insights when glucose moves significantly, or when it’s been a while, or when we’re probably awake. No need to pay Claude to tell a sleeping house that everything’s fine. (Though I appreciate the sentiment.)

I’ll keep tweaking the prompt too. The voice is close but not perfect. More feedback, more iterations.

Stepping back from the display itself, there’s a bigger opportunity here. The agent already has access to weeks of glucose, insulin, and carb data. Why stop at 30-character insights on an LED?

Morning email reports summarizing how overnight went. Weekly trends with suggestions to try. Coaching on carb ratios and bolus timing. “You’ve been running high after breakfast three days in a row. Want to try a 10% increase in your morning ratio?” The data is there. The reasoning is there. The interface could be anything.

For more complex workflows, AWS has AgentCore, a newer framework for building multi-agent systems. Could be fun to explore for coordinating analysis, recommendations, and delivery across different channels.

I’m excited to keep building. AI tools for diabetes management feel like exactly the kind of thing I want to spend time on. Personal, useful, iterative. A fun excuse to keep learning and a real way to help my family.

Still open source on GitHub.

Part 4 refines the insights after a stressful night.

– John

Why a Terminal App

TUIs are faster to build than GUIs: no layout constraints, no asset pipelines, no Xcode storyboards. Just text and boxes. With Claude Code and SwiftTUI, I had a working interface in minutes. That kind of speed makes building things genuinely fun again.

SpeechAnalyzer is 55% faster than Whisper and handles continuous transcription properly. The old SFSpeechRecognizer was designed for Siri-style dictation, and its isFinal flag rarely triggered during long recordings, forcing workarounds like stabilization timers. SpeechAnalyzer just works.

What It Does

Steno runs in your terminal. You see a real-time audio level meter, the current transcript, and a status bar. Partial results appear in yellow as you speak, then turn white when finalized. Everything happens on-device.

Press space to start transcribing, again to stop. The other keys do what you’d expect: s for settings, q to quit, i to cycle inputs, m to switch models.

The AI piece is optional. If you add your Anthropic API key, Steno will summarize your transcript on demand. It fetches the current list of Claude models from the API and lets you pick one. I default to Haiku for speed.

Building with Claude Code

This is the part I love. I described what I wanted (real-time transcription in a terminal) and Claude Code helped me build it. We started with SwiftTUI for the interface, wired up AVAudioEngine for audio capture, then connected it to the SpeechAnalyzer API.

We added global keyboard shortcuts, which turned out to be tricky. SwiftTUI handles input through a first-responder system, but I wanted single-keystroke shortcuts that work regardless of focus, and SwiftTUI doesn’t expose the internals needed to intercept keystrokes before they reach the responder chain.

Claude suggested forking SwiftTUI locally. We added a static globalKeyHandlers dictionary to the Application class. Now the input handler checks for global shortcuts first:

if let handler = Application.globalKeyHandlers[char] {
    handler()
} else {
    window.firstResponder?.handleEvent(char)
}

The whole patch was about ten lines. Swift 6’s strict concurrency required marking the static dictionary as nonisolated(unsafe), but since SwiftTUI’s input handling is already single-threaded, that’s fine.

The Audio Pipeline

Getting audio from the microphone to SpeechAnalyzer required some format wrangling. Mics typically output 48kHz stereo. SpeechAnalyzer wants 16kHz mono. The AudioTapProcessor handles the conversion:

AVAudioEngine → AudioTapProcessor → AsyncStream → SpeechAnalyzer
                     ↓                                  ↓
              (48kHz → 16kHz)                   SpeechTranscriber
                                                       ↓
                                               transcriber.results

The processor is isolated from the main actor to satisfy Swift 6’s concurrency requirements. Audio callbacks can’t block on the main thread.

Try It

Steno is open source: github.com/jwulff/steno

Requirements: macOS 26 (Tahoe) or later.

# Download and unzip
curl -L https://github.com/jwulff/steno/releases/latest/download/steno-macos-arm64.zip -o steno.zip
unzip steno.zip

# Remove quarantine attribute (required for unsigned binaries)
xattr -d com.apple.quarantine steno

# Run
./steno

On first run, you’ll need to grant microphone and speech recognition permissions. The speech models download automatically if needed.

If you want AI summarization, add your Anthropic API key in the settings screen (press s).

The best part of building with Claude Code is the velocity: describe a feature, watch it appear, iterate. The forked SwiftTUI approach would have taken me hours to figure out alone, but with Claude we had working keyboard shortcuts in twenty minutes. I forgot how much I missed this feeling of just making things.

What’s Next

Next I want to play with more structured analysis and real-time feedback. Imagine something that listens and proactively researches what’s being discussed, a real-time expert deep diver for spitballing conversations. That’d be neat.

– John

The family dashboard got smarter. It now shows insulin delivery patterns alongside glucose readings. Five days of insulin totals, bolus vs basal breakdown, and integration with Abigail’s insulin pump through Glooko.

Since building the dashboard, I’ve been iterating on the display. The glucose sparkline was useful, but diabetes management is about more than glucose. Insulin timing and dosing matter just as much. Could I get pump data onto the display too? Yes!

Getting Pump Data

Dexcom handles glucose. But insulin comes from a different system entirely. Abigail uses an Insulet Omnipod 5 insulin pump, which syncs to an app called Glooko. Glooko aggregates data from the pump: bolus doses, basal delivery, carb entries. All the treatment data that helps explain why glucose goes up or down.

Glooko’s web dashboard: glucose readings up top, carbs in the middle, insulin at the bottom with bolus (light purple) and basal (dark purple) stacked.

Insulet doesn’t have a public API, but they do share data with Glooko—which doesn’t have a public API either, but does have a CSV export in their web UI. No API? No problem. I built a web scraper.

A Lambda function runs Puppeteer with headless Chrome. It logs into Glooko, navigates to the export page, downloads a CSV archive, and parses the treatment data. The whole thing runs hourly on a schedule. Puppeteer in Lambda requires some gymnastics (@sparticuz/chromium for the binary, 1GB of memory for Chrome), but it works reliably.

The scraper extracts everything: bolus doses, basal rates, carb entries, even alarm events from the pump. All of it goes into DynamoDB with idempotent writes, building a historical diabetes database over time. Same data, same key, no duplicates.

Five Days of Insulin at a Glance

The display now shows five days of insulin totals in a row. Each number shows total insulin for that day—bolus plus basal combined. A brightness gradient makes the pattern clear: oldest on the left (dim), newest on the right (bright).

Below each number, a tiny ratio bar shows the bolus/basal split. Light purple for bolus, dark purple for basal. The bar width represents 100% of that day’s insulin. At a glance, I can see if the split is typical (roughly 50/50) or unusual.

The colors match Glooko’s own charts. Familiar visual language.

After the five totals, a latency indicator shows how fresh the bolus data is. “5m” means the last known bolus was 5 minutes ago. “2h” means we’re flying blind for a while. Useful context.

Time in Range

I also added TIR—Time in Range—to the glucose sparkline. It’s a standard diabetes metric: what percentage of readings fall within the target range (70-180 mg/dL) over the last 24 hours? The number appears in the corner of the chart. Quick insight into how the day is going.

= 70% TIR is generally considered good. Higher is better. Seeing the number on the display makes it ambient. No need to open an app.

Compact Everything

The original display used a 5x7 pixel font. Fine for readability, but it ate vertical space. I switched everything to a 3x5 font. Same information, fewer pixels. The sparkline chart grew from 21 pixels tall to 23. More room for trend detail.

Keeping it Simple

Since my last writeup, I added and then removed Oura readiness scores. Nice idea and looked neat, but I wasn’t finding them useful in practice. The display should show what matters. For diabetes management, that’s glucose and insulin.

Still Running Cheap

The scraper adds a bit to the AWS bill—Puppeteer needs more memory than a typical Lambda—but the whole system still runs for about $4/month.

What’s Next

The dashboard now covers glucose and insulin. The two main variables in diabetes management. Having them side by side on a glanceable display feels right.

I’m thinking about adding carb totals next. The data is already there from Glooko. Just needs a place on the display.

The scraper is also building a historical diabetes database in DynamoDB. Months of glucose, insulin, and carb data, all queryable. I’m curious what insights might emerge from pointing Claude Opus 4.5 at the trends—an AI endocrinologist on AWS Bedrock, offering succinct observations about patterns in the data? That’d be cool. 😎

The code is still open source on GitHub.

Update: Part 3 adds an AI insights agent.

– John

I built a family dashboard on a 64×64 LED matrix. It shows time, weather, and glucose readings. Serverless AWS backend, $4/month of AWS to run, developed entirely with Claude Code. The display is always on, always current.

My daughter Abigail has Type 1 diabetes. Living with T1D means checking glucose numbers constantly. All our phones have widgets charting readings every 5 minutes from her Dexcom G7 continuous glucose monitor. We check. A lot. The numbers matter, and the trend between numbers can matter even more. Is she rising? Falling? Holding steady?

Phones are great tools. I can’t imagine managing diabetes without them. But it’s also great to have something visible at a glance when we’re at home. Something we can check without pulling out our phones.

SugarPixel

Courtney found SugarPixel. We love it. We have several at home and set up a few more at Abigail’s school. Highly recommend if you’re managing diabetes.

SugarPixel is a small LED display that shows glucose, trend arrows, and the delta from the last reading. Color-coded by range: red for lows, green for in-range, yellow and orange for highs. It connects to Dexcom’s servers and updates automatically. Glanceable. Always on. No phone required. It doesn’t show trend history, but it’s still our primary CGM monitor.

We even travel with one, paired with a GL.iNet Puli portable 4G router so it stays connected anywhere. The setup works well enough that it deserves its own post sometime.

But SugarPixel sparked an idea. What if we could have one with trend history? Or data for other parts of our life—weather, calendar, notifications? How fun would that be to build?

Failed Starts and Found Solutions

I’d tried building an LED dashboard before. I bought an Adafruit 64x64 RGB LED Matrix, figured I’d wire it up and write some code. The hardware setup was a pain. Power supplies, driver boards, level shifters. The controller needed tons of setup just to get on wifi. I wanted to write software, not debug electronics.

Then Aaron Patterson posted about the Pixoo64.

I’ve admired Aaron’s work for years. He’s a Ruby core committer who makes everything look fun. His blog, tenderlovemaking.com, is a mix of deep technical posts and playful projects.

He recently wrote about building a Ruby client for the Pixoo64. The Pixoo64 is a 64×64 LED matrix from Divoom with WiFi and an HTTP API. He uses it to display PM2.5 and CO2 levels in his office. “I learned that I need to open a window,” he wrote.

The Divoom handles everything I didn’t want to DIY: packaging, networking, power, display API. I just write software and push pixels over HTTP.

I set out to build a dashboard. Serverless, running on native AWS services. A multi-widget architecture where each data source lives independently. Minimal maintenance, bias for reliability. Developed entirely with Claude Code. Deployed through GitHub Actions. A pattern I love.

Cloud to Countertop

The Pixoo sits on my home network, behind NAT. I can’t push to it directly from the cloud. The device needs to pull, or something local needs to relay.

The solution: a serverless AWS backend that holds the glucose data, and a small relay running on my home network that pulls updates and pushes them to the Pixoo’s HTTP API.

Lambda functions fetch glucose readings from Dexcom. A WebSocket connection lets the relay subscribe to updates. When new data arrives, the relay renders it to the display. The whole thing runs for pennies a month. No server to maintain.

The Stack

SST v3 handles all the infrastructure as code. AWS provides the pieces: Lambda, API Gateway WebSocket, DynamoDB, EventBridge for scheduling, CloudFront for the web emulator. TypeScript everywhere, organized into packages for the core logic, Lambda functions, the relay, and a web interface. Monorepo with pnpm workspaces.

The architecture uses a compositor pattern. Each widget (glucose, clock, weather) publishes its data independently to SNS. A compositor Lambda combines them into a single 64×64 frame whenever anything changes. The relay doesn’t know about widgets. It just receives pixels.

The web emulator was a late addition. Testing display layouts without physical hardware made iteration much faster.

Always On

The relay needs to run constantly. I could leave my dev machine on, but that was bound to be unreliable and wasteful for a single WebSocket connection.

Once I got everything working locally, I deployed the relay to a $3.50/month AWS Lightsail nano instance. The catch: the Pixoo is on my home network, and Lightsail can’t reach it directly. The solution: WireGuard. The Lightsail instance tunnels into my home network through a VPN. It was easy to set up on my router, a Ubiquiti Dream Machine. The Pixoo thinks it’s talking to something local. The cloud thinks it’s pushing to the internet. Everyone’s happy.

The relay runs as a systemd service with automatic restart. If the WebSocket drops, exponential backoff with jitter spreads out reconnection attempts. Keepalive pings every five minutes prevent idle disconnects. The service won’t start until the WireGuard tunnel is up. It’s been running for days without intervention.

Total cost: about $4/month for Lambda, DynamoDB, and the Lightsail relay. Cheaper and easier than leaving a computer running.

Built With Claude Code

I built this with Claude Code. The pairing made everything fast and fun. Claude handled the SST wiring, the Dexcom API integration, the WebSocket handshake, the binary protocol for pushing pixels to the display. I described what I wanted, Claude wrote the code, I tested and refined.

The worktree-based workflow helped too. Multiple branches in flight, each focused on a different piece: the Lambda functions, the relay, the display rendering. Claude could context-switch between them.

This project came together in a weekend.

Reading the Dexcom

Dexcom’s Share API is how followers receive glucose data. The same data that shows up on the Follow app. The system fetches the latest reading every minute, though Dexcom only pushes new values every five minutes.

The display shows the glucose value, a trend arrow, and the delta from the previous reading. Color-coded the same way SugarPixel does it: red below 70, green between 70 and 180, yellow up to 250, orange above that. The visual language is familiar. Anyone in the family can read it at a glance.

Patterns Over Time

Once the glucose number was working, I wanted trend data. SugarPixel shows the current reading. I wanted to see patterns at a glance.

I added a sparkline chart. But 24 hours of data compressed into 64 pixels loses detail. The last few hours matter most for decision-making: is she trending up from lunch? Coming down from a correction? So I split the chart in half. The left side shows 21 hours of compressed history. The right side shows the last 3 hours in detail. Recent data gets more pixels.

To do this I had to keep state. DynamoDB stores historical readings with automatic TTL cleanup. Every minute the compositor fetches 24 hours of history and renders both charts side by side.

I added vertical time markers at midnight, 6am, noon, and 6pm. Color-coded with a gradient from purple at night to yellow at midday. At a glance I can see when different readings happened. After-lunch highs are common with T1D. Now I can see them in context. The pattern matters as much as the number.

Weather Band

Same idea, different data. I built a weather band showing temperature and conditions across 24 hours: 12 hours trailing, 12 hours forward. The center is now. A gradient shows daylight levels using the same purple-to-yellow curve as the glucose chart. Cloud cover dims the band. Rain adds a blue tint. Temperature numbers overlay at key points.

Glancing at the display, I can see where the weather is going relative to where it was. Warmer tomorrow. Rain coming this afternoon. The same ambient information principle: no interaction required, just a glance.

A Family Dashboard

Glucose is the starting point, not the whole vision. A 64×64 grid has room for more.

The next addition: Oura Ring readiness scores. Courtney and I both wear Ouras. It’d be fun to have the top corner show our readiness scores, color-coded by how recovered we are. Two health metrics from two different sources, one glanceable display.

Then maybe more weather, calendar events, or a doorbell notification. Multiple data sources, composed onto one display. Perhaps other Pixoos in other rooms, each showing a different mix. The kitchen gets glucose and weather. The office gets calendar and glucose.

Open Source

I’ve open-sourced it on GitHub.

Ambient displays change how you interact with information. Or rather, how you don’t interact. The best interface is no interface. Just information, always visible, waiting for a glance.

Update: Part 2 adds insulin tracking and pump integration.

– John

One Button Recording

I wear an Apple Watch Ultra. On the side there’s an action button. Big, orange, impossible to miss. I set it to record Voice Memos. One press and I’m recording. Walking to lunch, driving to work, lying in bed at 2am with an idea I’ll definitely forget by morning. Press, talk, done.

The memos pile up. Some are grocery lists. Some are half-baked product ideas. Some are specific thoughts about projects I’m working on. All of them were archived in the Voice Memos app. A couple times a week, I’d open my laptop where iCloud had synced the recordings. I’d go into the Voice Memos app, hit transcribe on each recording, copy the transcription, paste it into my second brain, then process with Claude Code. It worked fine but those steps quickly got monotonous.

My Second Brain

My vault is an Obsidian folder—markdown files organized by date and topic, all linked together with [[wikilinks]]. Notes about people, places, trips, recipes, projects. Everything connected. I’ve taught Claude Code how the vault works via a CLAUDE.md file with all my naming conventions, folder structures, and linking rules.

Too Much Friction

The gap between a voice memo on my watch and a note in my vault was all manual. Transcribe, copy, paste, file, link. Friction kills habits, and this had too much friction.

I wanted to tell Claude: “Listen to my voice memos from today and process them into my vault.”

So I (with Claude Code) built the MCP tools to make that possible.

What I Built

MCP (Model Context Protocol) is Anthropic’s standard for giving AI assistants access to external tools and data. I built two servers:

apple-voice-memo-mcp reads directly from the Voice Memos database on macOS. It can list memos, get metadata, extract audio, pull existing transcripts, and transcribe on-device using Apple’s speech recognition. No cloud APIs, no sending my rambling thoughts to third parties. As far as I can tell, nobody else has built Voice Memos access for MCP.

whisper-mcp handles transcription with OpenAI’s Whisper model, running locally. There are several Whisper MCP servers out there. Mine is as light as possible, built to pair with the voice memo server above.

Now I Just Talk

Now my note-taking routine includes a simple command in Claude Code:

“Process my voice memos.”

Claude finds the recordings, transcribes them, figures out what each one is about, and files them appropriately. A random thought about a food project goes to my cooking folder. A reminder to call someone becomes a task. A shower thought about some code I’m writing gets appended to that project’s notes.

The friction is gone. I talk, and the thoughts find their way home.

I lose ideas all the time. The gap between having a thought and capturing it is where most of them die. The watch closes that gap. The MCP servers close the gap between capture and organization.

Get the Tools

Both servers are in the official MCP registry and on npm. Add them to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "apple-voice-memo-mcp": {
      "command": "npx",
      "args": ["-y", "apple-voice-memo-mcp"]
    },
    "whisper-mcp": {
      "command": "npx",
      "args": ["-y", "whisper-mcp"]
    }
  }
}

For Claude Code, add the same to ~/.claude/settings.json or your project’s .mcp.json.

Requirements: macOS Sonoma+, Node.js 18+, Full Disk Access permission. For whisper-mcp, also brew install whisper-cpp ffmpeg.

Source code is MIT licensed on GitHub:

• apple-voice-memo-mcp
• whisper-mcp

If you have ideas for improvements, PRs are welcome.

The best tools are the ones that disappear. Press a button, talk, and trust that the thought will end up where it belongs.

– John