Jeff Triplett

How I Work From Anywhere Without Losing My Place

2026-06-13T16:04:52+00:00

I’ve been running a new remote development setup for the last month or so, and the goal is simple: move between all of my devices without losing my place.

The way I think about it, I have three default states:

At my desk on my Mac Studio
Home or out somewhere with my laptop or an iPad and a portable keyboard
Only my phone, at practice or running errands

I wanted a setup that works across all three without rebuilding anything when I switch. I’d rather grab my iPhone or iPad with a portable keyboard than lug a laptop everywhere. If I’m at one of my kids’ practices and want to quickly follow up on something or implement an idea, I always have my phone with me.

The stack is basically:

Tailscale - glues all of my devices onto one secure network
tmux - keeps my dev environment alive so I can leave and come back without rebuilding
Mosh - keeps remote connections resilient across flaky WiFi and network changes
cmux - Ghostty + Workspaces for macOS, the desktop side of this
Moshi - the best iPhone and iPad shell I have found

The first three are the foundation. They work the same no matter which device I’m sitting at. cmux is how I connect from a desktop or laptop, and Moshi is how I connect from my phone or iPad.

Tailscale ties the machines together

Start with Tailscale. I’ve used Tailscale for almost a decade because it’s free, has clients for everything like my phone, iPads, Macs, Linux boxes, and even routers and TVs. It’s a low-friction way to access all of your devices from anywhere securely and privately.

Tailscale gives me a private network across my devices, so I can connect to my Mac Studio at the office, my Mac Mini at home, my MacBook Air, and Linux boxes without opening SSH to the public internet.

That’s a big part of why I’m comfortable with this setup.

These machines are not sitting there with public SSH ports open. They’re only reachable from my tailnet. Tailscale handles the secure network piece, and I don’t have to mess with WireGuard directly.

It just works.

tmux keeps the work alive

tmux is the core of the setup. I’ve been running it for the last couple of months because I wanted something I could reconnect to later, similar to screen, but better suited to the way I actually work.

A lot of the time, I have something running for work, a client, or one of my own projects. I might have Django in one pane, logs in another, and Claude Code or Codex running somewhere else. With tmux, I can leave that entire development environment in place and come back to it later. Being able to do that has been worth the switch on its own.

I’m probably not using 90% of what tmux was built for. Mostly I’m using it to create sessions, connect to them, and disconnect without losing my place. I can split panes and move between them when I need to, but I find myself doing that less and less. The persistence is the part that actually matters to me.

Some alternatives to tmux are Zellij and Herdr. I attempted to use Zellij, but struggled with the basics, so I bailed and went back to tmux. I haven’t tried Herdr, but I’ve seen people talking about it and wanted to include it.

Mosh makes remote sessions feel less fragile

The bigger improvement came when I added Mosh.

Before I left for PyCon US, I decided I didn’t want to spend the week fighting flaky hotel, airport, and conference WiFi.

I remembered that Mosh solves a lot of the disconnect problems SSH has, so I installed it on my server, my work Mac Studio, my home Mac Mini, and my MacBook Air before I left (Homebrew on macOS, your package manager of choice on Linux).

I connected to a session before getting on the plane. About an hour into the flight, I opened my laptop, and the session resumed automatically. I didn’t have to rebuild anything or start over. It worked better than I thought it would.

Mosh and tmux make a great pair. Mosh keeps the connection resilient, and tmux keeps the actual working state alive.

On a desktop or laptop, cmux ties it together

When I’m at a real keyboard, cmux is how I connect. It gives me Ghostty terminals and workspaces on macOS, which makes it easy to keep several machines and sessions organized at once.

Where cmux really earns its place is how it handles agents and shared sessions. One workflow I’ve come to rely on: I’ll start a tmux session on a remote machine, then connect to it in a second terminal window in cmux. Then I’ll have Claude or Codex connect to that same machine and attach to the same tmux session to do the actual work, like setting up a new Linux box or installing packages.

The nice part is that when Claude hits an interactive prompt, I can just take over the tmux session directly. I’m already attached. I can paste in API keys, answer prompts, or make changes that I wouldn’t want to hand off to an agent. Claude normally tries to handle those moments itself, and it doesn’t always do it well. This way I stay in control of the sensitive parts without losing the automation for everything else.

On my phone or iPad, Moshi is the missing piece

When I only have my phone or iPad with me, the part I was missing was a good way to connect to my remote sessions.

I had tried Termius before, and it was decent, but I kept running into small UI issues. CLI apps are not really designed for phones and tablets, so little things like getting to the right key at the right time can become annoying fast.

Then I tried Moshi.

Moshi is an iOS and iPad app for remote terminal connections. It also runs on Apple Silicon Macs as an iPad app, which is a nice bonus.

Moshi has really good tmux support, and probably other multiplexers I haven’t tried yet. When I connect to a server that has tmux sessions running, Moshi prompts me with a list of those sessions before I even get to a shell. I don’t have to remember the command or go hunting around. I just pick the session and I’m back where I left off. That’s the feature that made the whole setup click.

Moshi also has a good mobile UI for this kind of work. I created a couple of shortcuts, one for space and one for enter, and that gets me through most of what I need when I’m using Claude Code or Codex from my phone.

Codex still has a few spots where it wants escape, and I haven’t fully figured that out yet. That may have been a connection issue, or it may be something I need to configure better.

But for most of what I’m doing, it works shockingly well. I can open my phone, connect to an existing tmux session, check logs, nudge an agent, review what changed, or keep something moving without opening my laptop.

Setup was easier than expected

Moshi also handles setup nicely.

When you connect to a server, it can show a QR code. You scan that from your phone, and it handles creating and copying the SSH key for you.

That makes setup about as easy as I think it can be.

On Apple devices, Moshi can also share connection settings across devices on the same Apple account. Once I had it set up, connecting from my iPad was painless. I hit the button, picked my session, and I was in.

There is an Android version too. I haven’t tested it because I don’t have an Android device, but it’s there if you need it.

Moshi is a paid app, unlike the rest of this stack, which is free or open source. It runs around $30 a year or around $80 for lifetime access, which felt reasonable given how much I’m using it.

Voice input

Moshi also supports voice input, which ended up being a bigger deal than I expected.

On my Mac, I already use voice input a lot. I use tools like MacWhisper because voice to text has become a really good input method for me.

Moshi brings that same idea to my phone and iPad.

It can use Apple’s voice to text, and it can also run a Whisper model. That means I can connect to a remote session from my phone and use voice input to interact with the tools I already have running.

Claude Code has voice support on the Mac, but that doesn’t really help when I’m remotely connected into another machine. Moshi having voice support built in makes the whole thing much more useful.

Where I’m using it

So far, I’ve been using this setup on Django TV, my job board, client work, and a bunch of one-off projects.

I have a Mac Studio at the office and a Mac Mini at home, and I’m constantly moving between them from my MacBook Air. I’ve also been playing with direnv so I can jump into a project and have the right environment load on the right machine. It’s not really part of this stack, but it pairs well with it.

The split helps me keep things organized. Client work lives on the Mac Studio at the office. Side projects and personal work live on the Mac Mini at home. I can connect to whichever one I need without mixing everything together on my laptop. It also helps my MacBook Air battery, because the heavier work is happening somewhere else.

And because the sessions are always running, I don’t have to worry about rebooting my MacBook Air or losing a Claude Code or Codex session mid-task. If one machine is having a problem, I can exit and switch to the other one while everything I care about stays up and running.

Review has also gotten easier. I can pull up GitHub’s web interface or the GitHub desktop app from wherever I am and review pull requests without needing my full dev environment in front of me. The work is already staged. I just need a browser.

I can still work locally when I want to. There’s nothing wrong with that. But keeping these remote sessions open all the time has been a much better experience.

The databases are already connected. The processes are already running. The agents are already in context. I can leave things in progress and come back later without rebuilding the whole setup.

The glue code

I’ve also been writing some shell aliases and scripts to smooth over the rough edges, because I don’t want to memorize tmux’s command flags.

I have a set of tmux-* aliases that handle the things I actually do: create a new session, resume an existing one, and kill one when I’m done. That covers most of what I need without having to look anything up.

On the cmux side, I’ve been experimenting with its CLI and API. I wrote cmux-dump and cmux-restore commands to save and reload workspace layouts. The idea is to build out profiles for each project so I can get everything running the way I want it with one command. That might mean starting a tmux session on a remote machine and connecting to it over Mosh, all from a single alias.

All of this lives in my dotfiles repo and will keep changing as I figure out what actually works. I’m still early in this part of the setup.

When and why you need each tool

You don’t have to adopt all five of these at once. Each one solves a specific problem, and you can add them as you hit that problem.

Tailscale is the one to start with if your machines aren’t already on a shared network. You need it the moment you want to reach a machine that isn’t sitting in front of you without exposing SSH to the public internet. If all of your work happens on one machine, you can skip it for now.
tmux is what you need when losing your terminal state hurts. If closing a laptop lid or dropping a connection means rebuilding your dev environment, restarting servers, or losing an agent session mid-task, tmux fixes that. It’s also the piece that lets two terminals, or you and an agent, share the same session.
Mosh matters when your network is unreliable. Hotel WiFi, airports, conferences, tethering, or just moving between home and office. If you only ever connect over a stable wired network, plain SSH is fine. The moment you roam, Mosh is the difference between a session that survives and one you have to reconnect constantly.
cmux is for the desktop side, when you’re juggling several machines and sessions and want them organized into workspaces instead of a pile of terminal windows. Any terminal works here, but cmux makes the multi-machine setup easier to live in.
Moshi is for the phone and iPad side. You need it when you want to check on or nudge work from wherever you are. Its tmux session picker, key shortcuts, and voice input are what make a phone a usable terminal instead of a frustrating one.

The short version: Tailscale gets you to the machine, tmux keeps the work alive on it, Mosh keeps the connection from breaking, and cmux and Moshi are the front doors from a desk and from a phone.

This is not about working all the time

The real reason I like this setup is not because I want to maximize every spare minute of my life.

It’s almost the opposite.

This setup gives me more flexibility.

If I have 15 minutes at my son’s track meets or baseball practice, I can pull out my phone and reconnect to something already in progress. If I’m waiting on slow tests, client feedback, or a deploy, I don’t have to sit glued to my desk.

I can make dinner. I can pack lunch. I can pick up one of my kids. I can run an errand.

Then, when something is ready, I can check in, make the next change, and keep moving.

It makes the work less jarring. I don’t have to reset everything on my laptop just to make one small change or direct an agent for two minutes.

The best part is that I can just close my laptop or walk away from my desk and know that my Claude and Codex sessions are going to keep running. When I come back, whether it’s on my phone or back at my desk, I can resume right where I left off without worrying about a disconnected session or a timed-out agent.

Why this feels different

The built-in remote options from tools like Claude Code and Codex work sometimes, but I kept running into connection weirdness when one laptop was trying to coordinate across multiple machines.

What I wanted was something that didn’t require rebuilding context every time I moved. This stack gives me that. The connection doesn’t break. The session doesn’t disappear. The agents don’t lose their place.

That’s a different kind of flexibility than I had before. It’s not about squeezing more work into more hours. It’s about not paying a tax every time I pick up where I left off.

This is what’s working well for me right now, but I’m genuinely curious what you’re using. If you have a tool that replaces one of these or collapses a few layers into one, I want to hear about it. If you try any of this and it works for you, let me know. And if I’m holding one of these tools wrong and there’s a better way, I’m all ears for that too.

Written by Jeff via a mix of voice transcription and typed notes. Edited with Claude Code.

Originally posted on: https://micro.webology.dev/2026/06/13/how-i-work-from-anywhere/

Django Chat Podcast: E201

2026-04-30T18:10:04+00:00

This week, I joined Will Vincent and Carlton Gibson on the Django Chat podcast for DjangoCon Europe Recap + Other News. You can also watch it on DjangoTV via YouTube.

On this episode, we discussed DjangoCon Europe, which Carlton had attended. We caught up on what’s going on with Django News and the Django Software Foundation. We also spent a good chunk of time on AI workflows and tooling. And I got to have a little soapbox rant at the end, which is always fun for me.

Projects I Recommended

Pydantic AI is the Django ORM for accessing LLM providers
CodexBar - If you are on a Mac, CodexBar will let you easily track and see your token usage across 20+ providers
Ghostty - After almost two decades of using iTerm2, I switched.
cmux - Built on Ghostty but a nice UX to switch between Agent sessions
MacWhisper - Still my favorite voice to text Mac app

Books I Recommended

At the end of the episode, I recommended these two books:

The Greatest Bedtime Story Ever by Jessie Sima
Enshittification: Why Everything Suddenly Got Worse and What to Do About It by Cory Doctorow (I recommended this one, but maybe not for the reasons you might think)

Conclusion

I’m always excited and honored to be invited on the show, and I always enjoy it. I hope it was a good listen, and I especially appreciated getting to step on the soapbox one more time at the end.

Originally posted on: https://micro.webology.dev/2026/04/30/djangochat-podcast-e/

DjangoCon US Talks I'd Like to See 2026 Edition

2026-03-19T20:54:26+00:00

This is my annual list of DjangoCon US talks I’d like to see. I have been doing this since 2015, and it’s one of my favorite traditions.

DjangoCon US 2026 is in Chicago this year, August 24-28.

The CFP is open. The deadline is March 23, 2026 at 11 AM CDT. Submit a talk!

Past editions

Drew’s Topics

Drew Winstel published a great list of talk ideas for DCUS ‘26 with over 20 ideas. Here are some of my favorites from his list. Any of these would make good talk ideas, so check out Drew’s full list too.

GPTs, LLMs, and AIs, oh my!
Deployment at any size
Unexpected use cases, especially ones that make the world better
Clever hacks (such as Carlton Gibson’s single-file Django project)
Using Django in machine learning projects
New features in Django 6.x
Development and testing techniques that help you build better code
Convincing product management that you don’t need a SPA or yet another mobile app
Personal growth: how the community helped you in some way and you’d like to pay it forward
Adapting communities to changes in life

My Topics

Here are some topics that I’d personally like to see this year.

What’s coming in Python and Django

With some big shifts coming in Python 3.15 and 3.16, it would be really interesting to see more about what Django developers would benefit from knowing about what’s coming up. Something a little more core to Python would be interesting.

I’d also love to see more Django talks, whether it’s from the Steering Council or anybody working on features for the Django 7 series. What’s coming? What are the big features being tackled?

Django’s deployment story

Last year I was on a panel called Two Decades of Django: The Past, Present, and Future. During that panel, I challenged people to really look into Django’s deployment story and find ways to improve it. If we can remove one or two steps along the way, we can make the deployment story better.

A couple of projects came out of that conversation that I really liked, including Django Prod Server. Anything that makes deployments better and reduces the number of steps is worth exploring. If anybody has topics around improving Django’s deployment experience, that would be a great one to discuss.

Rust in our ecosystem

I’d like to hear more about Rust in our ecosystem. Tools like uv, Ruff, and Pydantic are all built with Rust. Pydantic led to Django Ninja and other applications built around it. Are you using Rust in your Django applications? Why? Where are you building with it? How is it improving your workflow? Is it for linters? Code formatters? Are you solving performance bottlenecks with Rust? What should Django learn from Rust? Which parts of Django would be better if rewritten in Rust? That story is really fascinating to me.

LLMs and Django

I’d like to see more LLM talks about the amazing things people are building. This could be with Pydantic AI, creating model agents, or things you’re building that either run Django websites or help people do amazing things with agents. What does it look like to give a functional brain to a Django app? That would be an interesting talk idea.

Agent skills and productivity

I’d also like to hear about agent skills. How are you improving your productivity? How are you taking some of the drudge work out of working with Django? What skills do you use? What problems are you solving that a skill helps you with? What should Django learn from LLMs, skills, and agents? That would be another interesting topic.

Real talk about LLMs and team productivity

There are a lot of talks about the negative things about LLMs and AI, and I think that is respectable and understandable. But it has become taboo for some weird reason that people who use LLMs every day aren’t speaking out about it and aren’t talking about the productivity gains they get. Especially if you’re on a small team doing a lot of stuff.

If you’re working with a bigger team and everybody’s using these tools, how are you managing it? How are you getting through pull review processes? How are you making your code better? What’s working? What didn’t work? What’s scaled up for you?

Everything is changing in our industry whether we like it or not. Agents are here. The companies as of today are not going anywhere and the bubble hasn’t burst. I’m really curious about team productivity. What do you like? What don’t you like?

Defending and embracing LLM traffic

On the flip side with LLMs, so many things have changed in the last year that we have to be a little more defensive with our websites, whether that’s using CDNs like Cloudflare or Fastly. I’m really interested in what people are doing to scale their servers now with LLMs in mind.

Some people may or may not want to make their websites more LLM friendly. There are definitely advantages and disadvantages to doing that. Writing a website to be consumed by LLMs is an interesting topic, both defensively and in terms of how you take advantage of it.

Submit a talk

You can always go back to my 2024 list and of course there’s Drew’s list too. Some of the best topics that will be submitted will be things that don’t fit either of our lists. The whole idea is just to give people a starting point for things we’d both personally like to see, but that shouldn’t limit your imagination.

Outside opinions are great. Not everything needs to be about Django. We always get a bunch of community talks and talks that don’t have to be about the tech. But I think it’s an exciting year to really dig deeper into some of the tech because so much is changing on a weekly basis.

Submit your talk for DjangoCon US 2026!

Originally posted on: https://micro.webology.dev/2026/03/19/djangocon-us-talks-id-like/

How I Use django-simple-nav for Dashboards, Command Palettes, and More

2026-02-27T02:56:51+00:00

I first got exposed to django-simple-nav while working with Josh Thomas at the Westervelt Corporation over the last two or three years. It quickly became a go-to library in my toolkit. django-simple-nav lets you define nav items and groupings in Python, then hand them off to a Django template to render. I use it for sidebars, headers, dashboards, and other spots where I need a menu.

Since then, I have also started using it on a lot of personal projects. It has been a great fit every time.

Defining nav items once and reusing them everywhere

Recently I wanted to reuse parts of a menu nav without having to update a bunch of different files. I had a dashboard with a sidebar full of links, and I also wanted a command palette that could search across all those same options when you hit Command-K from any page. django-simple-nav was a natural fit because you define your items once in Python and render them with whatever template you want.

Here is an example of what that looks like in Python:

from django_simple_nav.nav import Nav
from django_simple_nav.nav import NavGroup
from django_simple_nav.nav import NavItem

NAV_ITEMS = [
    NavItem(title="Home", url="home"),
    NavItem(title="Dashboard", url="dashboard"),
    NavGroup(
        title="Admin & Tools",
        items=[
            NavItem(title="Admin", url="admin:index", permissions=["is_staff"]),
        ],
    ),
    NavItem(title="Login", url="login"),
    NavItem(title="Logout", url="logout"),
]


class DashboardNav(Nav):
    template_name = "nav/dashboard.html"
    items = NAV_ITEMS


class CommandPaletteNav(Nav):
    template_name = "nav/command_palette.html"
    items = NAV_ITEMS

Flexible URLs and named routes

A few things to notice here. When you create a nav item and you have a URL, you can either use the URL’s name or you can give it the path to it and it will figure out what it is. So if I want a nav item for the Django admin, I can use "admin:index" as the URL.

Handling permissions without template logic

Another nice feature is the permissions parameter. The Admin link uses permissions=["is_staff"], which means it only shows up for staff users. You can use this to hide things based on whether someone is staff, a superuser, or has specific Django permissions. This makes it nice to keep all of your nav options in one place without having to write special conditional logic in your templates to show or hide items for different users.

Rendering a dashboard nav with Django templates

The other thing to notice is the two Nav classes at the bottom: DashboardNav and CommandPaletteNav. They both use the same NAV_ITEMS list but point to different templates. This is where the reuse really shines.

Here is an example nav template at templates/nav/dashboard.html:

<nav>
  {% for item in items %}
    {% if item.items %}
      <span>{{ item.title }}:
        {% for subitem in item.items %}
          <a href="{{ subitem.url }}"{% if subitem.active %} class="active"{% endif %}>
            {{ subitem.title }}
          a>
        {% endfor %}
      span>
    {% else %}
      <a href="{{ item.url }}"{% if item.active %} class="active"{% endif %}>
        {{ item.title }}
      a>
    {% endif %}
  {% endfor %}
nav>

Then in your base template, you can render it with the template tag:

{% load django_simple_nav %}

{% django_simple_nav "myapp.nav.DashboardNav" %}

Building a command palette from the same nav items

Because the CommandPaletteNav class uses the same NAV_ITEMS list but with a different template, we can render the same nav data as JSON for a command palette. Here is an example template at templates/nav/command_palette.html:

{% load django_simple_nav %}

<script type="application/json" id="command-palette-data">
[{% for item in items %}{% if item.items %}{% for subitem in item.items %}
  {"title": "{{ subitem.title }}", "url": "{{ subitem.url }}", "group": "{{ item.title }}"}{% if not forloop.last or not forloop.parentloop.last %},{% endif %}{% endfor %}{% else %}
  {"title": "{{ item.title }}", "url": "{{ item.url }}"}{% if not forloop.last %},{% endif %}{% endif %}{% endfor %}
]
script>

This also lent itself well when I was trying to do something quickly with Claude. I don’t know how to build a command palette, but I was able to just have Claude create one. I asked it to use HTMX to keep everything pretty lightweight.

Final thoughts

All in all, django-simple-nav is a nice library to have in your toolkit. I like using it for headers, menus, dashboard navigation links, and even footer text. If you need flexible, reusable navigation in Django, give it a look.

Written by Jeff. Edited with Grammarly and Claude Code.

Originally posted on: https://micro.webology.dev/2026/02/26/how-i-use-djangosimplenav-for/

Jordan Baird's Ice beta fixed my macOS Tahoe menu bar issues

2026-02-19T14:00:00+00:00

If you use a Mac, you’ve probably noticed that the menu bar fills up with icons pretty quickly. Bartender and Ice (sadly, now an unfortunate name) are apps that let you manage and hide unwanted icons from your macOS menu bar so it stays clean and uncluttered.

About a year ago, I switched from Bartender to Ice, which just happens to be open source, because there was some drama. Since then, I’ve been very happy with Ice.

A couple of months ago, I upgraded to macOS Tahoe, and my menu bar stopped working correctly. The icon colors were all this weird shade of blue, so I couldn’t customize anything. After months of trying to figure it out, I noticed that it had been a while since Ice released a new version. That’s how open source goes sometimes.

I was getting to the point of deciding whether to go back to Bartender or stick with Ice. Today, I noticed that there’s a Homebrew package for jordanbaird-ice@beta. I decided to give it a try, removed the old version, installed the beta, and to my surprise and delight, the problem was fixed.

# remove the stable version
brew remove jordanbaird-ice

# install the beta
brew install jordanbaird-ice@beta

I’m hoping there’s a more official release soon. The new Bartender looks good too, so if Ice doesn’t keep getting updated, I might switch back. If you’ve run into this same issue, give the beta a try and let me know how it goes. And if you know of any alternatives to Bartender and Ice, I’d love to hear about those too.

Originally posted on: https://micro.webology.dev/2026/02/19/jordan-bairds-ice-beta-fixed/

My displays keep rearranging and displayplacer fixed it

2026-02-18T22:54:47+00:00

Today I learned about displayplacer - “macOS command line utility to configure multi-display resolutions and arrangements.”

In December, I upgraded to MacOS Tahoe and picked up the TS4 dock for my work machine.

While my upgrade was painless, the biggest issue I’ve had is with my displays. Every time my displays go to sleep and then I come back from lunch or come back the next day to work, my orientation of my displays changes and it puts them in a random order.

My displays should be arranged like this:

[1] [2]
[3] [4]

But after waking from sleep, they end up like this:

[2] [1]
[3] [4]

It’s really annoying. It takes a minute to fix and it’s just frustrating.

I tried displayplacer today. I had Claude Code actually run the displayplacer list command. It figured out which displays and which settings needed to be changed. I had it record that and then I tried it out a few times where I manually dragged my displays around, put them in the wrong order, then ran the command, and it just magically worked.

I saved the working configuration to a shell script:

#!/usr/bin/env bash
# Restore display layout: 4 monitors (2x 16" 1920x1080, 2x 73" 2048x1280)

displayplacer \
  "id:F4AB0D6C-8E85-4E84-B5AB-C5B388536E3D res:1920x1080 hz:60 color_depth:8 enabled:true scaling:off origin:(0,0) degree:0" \
  "id:C9240C8E-A9D2-418A-89AC-28D3B5DEE5FC res:1920x1080 hz:60 color_depth:8 enabled:true scaling:off origin:(-1920,0) degree:0" \
  "id:B43E3352-ACB7-4163-A25B-2DDAE0174571 res:2048x1280 hz:60 color_depth:8 enabled:true scaling:off origin:(0,-1280) degree:0" \
  "id:B32F530C-62CF-4F0D-9997-80BF2B812AC8 res:2048x1280 hz:60 color_depth:8 enabled:true scaling:off origin:(-2048,-1280) degree:0"

I also tried setting it up as a Stream Deck key and for some reason I couldn’t get that to work. But it’s fine. I can run a shell script and that takes a lot less time to get it in the right order.

Originally posted on: https://micro.webology.dev/2026/02/18/my-displays-keep-rearranging-and/

🤖 Trying Out GLM with Claude Code

2025-12-11T01:43:48+00:00

My friend Trey Hunner showed me the GLM set of models before Thanksgiving. While traveling to see family, I somehow messed up my Claude Code setup because of a wrapper I have with mise-en-place. I couldn’t use it for a while, and that made me realize I really need a backup for Claude Code.

Why GLM?

Z.AI’s GLM model is better than Gemini but not quite as good as Claude Code. It’s really fast (about twice as fast as Claude Code), seems like 90+ percent as good, and it’s really cheap. You can get an annual subscription for around $26-28 for the first year, and I’ve read online that it’s very hard to hit the limit even on the lowest tier subscription.

This is a great option for folks who can’t quite justify the $100/mo Claude plan but occasionally hit limits on the $20/mo Claude plan. I actually subscribe to the $100/mo plan, but I ended up getting the GLM Pro Plan because I like the amount of usage it gives me. The plan I’m on has five times as much token usage as the base tier.

Running Both Side by Side

There’s a wrapper tool that lets you use Z.AI’s models as Claude Code’s backend, so you can run both Claude and Z.AI’s GLM in two different windows. Having a reasonable backup that I can switch between or run in parallel is nice.

I never find speed to be an issue with Claude Code, but I’m definitely a fan of having options.

API Access

Claude doesn’t include API key access without paying extra. GLM solves this problem by giving you a raw API for a set price per month. Their API is OpenAI compatible, so I can work on agentic scripts using Open Coder or other applications without paying extra for Anthropic tokens.

Getting Started

To get started, run:

bunx claude-glm-installer

This will give you bash aliases that let you run various GLM models while still letting Claude default to the Anthropic backend:

ccg              # Claude Code with GLM-4.6 (latest)
ccg45            # Claude Code with GLM-4.5
ccf              # Claude Code with GLM-4.5-Air (faster)
cc               # Regular Claude Code

Trey also told me about claude-code-router, which lets you change models on the fly without restarting Claude Code. This might work well if you want to switch between models mid-session.

If you find yourself running out of Claude Code tokens a couple of times a week or even a couple of times a day, it might be worth checking out GLM as a backup or alternative.

If you want to try out Z.AI’s GLM models, please use my invite link (affiliate) or feel free to use Trey Hunner’s invite link (affiliate) instead.

Resources

Written by Jeff. Edited with Grammarly and Claude Code.

Originally posted on: https://micro.webology.dev/2025/12/10/trying-out-glm-with-claude/

🤖 How I Accidentally Spent Over 62 Million OpenAI Tokens

2025-11-23T05:01:54+00:00

I’ve been fighting a runaway OpenAI bill for the last few weeks. I was worried I was leaking one of my API keys in a non-obvious way, possibly in one of my public projects.

Two weeks ago, I deleted all my keys and contacted OpenAI support. I created new keys for every project, making it easier to track usage and identify any leaks. I had already been doing this, but I was a bit lax on a few projects while migrating from Digital Ocean to Hetzner. More on that migration soon.

Fast forward two weeks, and OpenAI notified me again that I hit my very low recharge threshold. With granular keys in place, it only took a minute to narrow down the culprit: my DjangoTV.com project.

I use the OpenAI API to help parse presenter names and clean up titles whenever we add new videos. I had recently added DjangoCon US videos and Wagtail Space videos during the last two weeks, both on the same day our LLM usage spiked.

I checked my Django-Q2 logs and noticed several tasks failing because they were timing out after 90 seconds. The task accepts a list of video IDs and loops through them, parsing each one using Pydantic AI and the OpenAI API. When I ran it from the command line, I never hit a timeout. But when I created a Django Admin Action to bulk process videos, I was trying to process them all in one call instead of fanning them out into individual tasks.

What Went Wrong?

I didn’t have just one bug - I had two, possibly three bugs that weren’t obvious at the time:

Timeout issues: Tasks were timing out after 90 seconds when processing large batches
Bulk processing: Processing all videos in one call instead of individual async tasks
Infinite retries: I failed to set a maximum number of retry attempts. I assumed that not having a default meant there was a fixed number of retries, not infinite

That third bug was the killer. My job ran for over 24 hours, burning through over 32 million tokens in the process. In total, I spent over 62 million tokens in November before I found and fixed the issue. Thankfully, my out-of-pocket costs were more than reasonable.

What Changed?

I could blame this on vibecoding since DjangoTV is >99% vibe coded, but the project was built using sensible defaults and this wasn’t obvious at the time.

Here’s what I changed:

Set max_attempts to limit retries
Kept my 90 second timeout
Spaced out retry attempts to a few minutes between tries
Adjusted my parse_presenters_with_ai and parse_titles_with_ai Django Admin Actions to queue up one async_task per Video instead of processing them all in one call

Sometimes the most expensive bugs are the ones that combine multiple small issues into one perfect storm. Granular API keys for tracking, sensible retry limits, and proper task queuing are now non-negotiable in my projects.

Computers!

Written by Jeff. Edited with Grammarly and Claude Code.

Originally posted on: https://micro.webology.dev/2025/11/22/how-i-accidentally-spent-over/

The "Vibe Coding Keyboard" How I Made My Walk-and-Talk Setup Even More Awesome

2025-11-20T00:37:48+00:00

So, picture this: you’re working at a walking desk, you’ve got a cool voice-to-text tool like MacWhisper running, and you want to control it all with just a couple of dedicated keys. That was the dream that led me to build what I now call my “Vibe Coding Keyboard.”

Why Voice Control in the First Place?

Before I get into the keyboard itself, let me explain why I’ve gotten so into voice control. A considerable part of my day involves Slack and Discord conversations, and voice mode is high-speed for firing off replies. I also use it to drive Claude Code sessions and other workflows, and it’s just become second nature.

But the real game changer is the walking desk. When you’re walking and working, typing gets awkward fast. Your arms are in weird positions, and trying to maintain your stride while reaching for your keys just looks clumsy. With voice mode, I can quickly dictate a response to an email or message, clean it up if needed, and keep moving. It’s way more natural than contorting myself to type while walking.

Why a Dedicated Keyboard?

I already had an Apple Magic Keyboard that I loved. It’s sleek and all, but I kept running into a minor but annoying problem: I was running out of keys to assign to all my voice-control shortcuts. I tried using the function key as a makeshift “vibe” key, but it just wasn’t cutting it.

So I went looking for the smallest possible external keyboard I could find. I wanted something that would just plug in like a regular HID keyboard, no extra drivers or fancy setup. I originally tried to find a two-key keyboard, but I couldn’t find any that were USB-C. So I went with the BTXETUEL 4-Key Mechanical Keyboard instead, and it turned out to be perfect. Its small enough that it doesn’t take up much space, and having four keys actually gives me a bit more flexibility than I originally thought I needed.

### Setting Up the Vibe Keys

Here’s how I configured it:

Key 1: My “vibe” key. This one toggles MacWhisper’s dictation mode on and off. I just tap it, and boom, I’m in voice mode.
Key 2: Enter key. Super handy for confirming commands or just hitting “enter” without reaching for my main keyboard.
Key 3: Backspace. Because voice-to-text sometimes needs a quick correction.
Key 4: Escape key. Just a nice little “get me out of here” button if I need to exit a mode or cancel something.

And because I wanted a bit of flair, each key has an LED that can change color. I made the vibe key cycle through a rainbow pattern, so it stands out and literally “vibes.”

The Fun of Customization

The best part is how customizable this little gadget is. I even 3D-printed some LEGO keycaps just for fun. It’s become a hobby project, and it has made voice coding even more enjoyable for me.

A Boost to Productivity (and Fun)

In the end, it’s not something you absolutely need, but it’s been a surprisingly nice productivity boost. Plus, it’s just plain cool to have a dedicated vibe key that lights up in rainbow colors while you work. If you’re into voice mode coding or want a fun little side project, give something like this a try!

Written by Jeff. Dictated via ChatGPT 5.1. Edited with Grammarly and Claude Code.

Originally posted on: https://micro.webology.dev/2025/11/19/the-vibe-coding-keyboard-how/

📅 Office Hours for November

2025-11-13T23:08:22+00:00

I’m hosting office hours on the next two Fridays in November.

Office Hours Schedule

Friday, November 14, 2025, 2:30 pm to 4:30 pm CT
- Starting at 2pm CT, I’ll be working on some community/open source projects if anyone wants to see Claude Code or Claude Code on the web in action
Friday, November 21, 2025, 2:30 pm to 4:30 pm CT
🦃 Friday, November 28th - No office hours due to US Thanksgiving

Join Us

These sessions are open to anyone, especially those working remotely who wants to connect with others. It’s a collaborative space for discussions, catch-ups, or just hanging out while you work.

While we have a bunch of Python and Django developers who regularly attend, anyone is welcome to join even if you don’t use either of these things.

Whether you’re a first-time attendee or a regular, you’re welcome to drop in anytime during the session. No need to stay for the full two hours, come and go as your schedule allows.

How to Join

The Zoom link is available in the gist from our previous sessions. Feel free to reach out if you need the details.

ℹ️ Meeting Guidelines

🔕 Please mute when someone else is talking 👈
👍 Be respectful to other people and mute when not talking
👍 Be mindful of the spirit of the Python Code of Conduct
👍 Be mindful and respectful of everyone’s time.
👍 Join because you want to work on something with a small group
⚠️ No marketing your product or service
⚠️ No meeting/recording bots. Humans are welcome. Meeting bots are not.
⚠️ Mute!

See you there!

Originally posted on: https://micro.webology.dev/2025/11/13/office-hours-for-november/