Jeff Triplett

How I Work From Anywhere Without Losing My Place

Sat, 13 Jun 2026 16:04:52 +0000

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](https://tailscale.com) - glues all of my devices onto one secure network - [tmux](https://github.com/tmux/tmux) - keeps my dev environment alive so I can leave and come back without rebuilding - [Mosh](https://mosh.org) - keeps remote connections resilient across flaky WiFi and network changes - [cmux](https://cmux.com) - Ghostty + Workspaces for macOS, the desktop side of this - [Moshi](https://getmoshi.app) - 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](https://zellij.dev) and [Herdr](https://herdr.dev). 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](https://getmoshi.app). 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](https://direnv.net) 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`](https://github.com/jefftriplett/dotfiles/blob/main/home/bin/cmux-dump) and [`cmux-restore`](https://github.com/jefftriplett/dotfiles/blob/main/home/bin/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](https://github.com/jefftriplett/dotfiles) 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

Thu, 30 Apr 2026 18:10:04 +0000

This week, I joined [Will Vincent](https://wsvincent.com) and [Carlton Gibson](https://noumenal.es) on the [Django Chat](https://djangochat.com) podcast for [DjangoCon Europe Recap + Other News](https://djangochat.com/episodes/djangocon-europe-recap-other-news-jeff-triplett). You can also watch it on [DjangoTV via YouTube](https://djangotv.com/videos/djangochat/2026/djangocon-europe-recap-other-news-jeff-triplett/). On this episode, we discussed [DjangoCon Europe](https://2026.djangocon.eu), which Carlton had attended. We caught up on what’s going on with [Django News](https://django-news.com) and the [Django Software Foundation](https://www.djangoproject.com). 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](https://github.com/pydantic/pydantic-ai) is the Django ORM for accessing LLM providers - [CodexBar](https://github.com/steipete/CodexBar) - If you are on a Mac, CodexBar will let you easily track and see your token usage across 20+ providers - [Ghostty](https://ghostty.org) - After almost two decades of using iTerm2, I switched. - [cmux](https://cmux.com) - Built on Ghostty but a nice UX to switch between Agent sessions - [MacWhisper](https://goodsnooze.gumroad.com/l/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](https://www.simonandschuster.co.uk/books/The-Greatest-Bedtime-Story-Ever/Jessie-Sima/9781665974523) by Jessie Sima - [Enshittification: Why Everything Suddenly Got Worse and What to Do About It](https://us.macmillan.com/books/9780374619329/enshittification/) 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

Thu, 19 Mar 2026 20:54:26 +0000

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](https://2026.djangocon.us) is in Chicago this year, August 24-28. **The [CFP](https://pretalx.com/djangocon-us-2026/cfp) is open. The deadline is March 23, 2026 at 11 AM CDT. Submit a talk!** ### Past editions - [2024 Edition](https://micro.webology.dev/2024/04/28/djangocon-us-talks.html) - [2023 Edition](https://jefftriplett.com/2023/djangocon-us-talks-i-d-like-to-see-2023-edition/) - [2022 Edition](https://jefftriplett.com/2022/djangocon-us-talks-i-d-like-to-see-2022-edition/) - [2018 Edition](https://jefftriplett.com/2018/djangocon-us-talks-i-d-like-to-see-2018-edition/) - [2017 Edition](https://jefftriplett.com/2017/django-talks-id-like-to-see/) - [2016 Edition](https://jefftriplett.com/2016/djangocon-us-talks-id-like-to-see/) - [2015 Edition](https://gist.github.com/jefftriplett/cdda63bf42c592b1a6c8) Drew’s Topics ------------- [Drew Winstel](https://winstel.dev) published a great list of [talk ideas for DCUS ‘26](https://winstel.dev/2026/01/05/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](https://djangotv.com/videos/djangocon-us/2025/panel-discussion-two-decades-of-django-the-past-present-and-future-with-velda-kiara/). 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](https://github.com/nanorepublica/django-prodserver). 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](https://micro.webology.dev/2024/04/28/djangocon-us-talks.html) and of course there’s [Drew’s list](https://winstel.dev/2026/01/05/talk-ideas-for-dcus-26/) 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!](https://pretalx.com/djangocon-us-2026/cfp)** 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

Fri, 27 Feb 2026 02:56:51 +0000

I first got exposed to [django-simple-nav](https://github.com/westerveltco/django-simple-nav) while working with [Josh Thomas](https://github.com/joshuadavidthomas) at [the Westervelt Corporation](https://github.com/westerveltco) 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:

```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`:

```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:

```html
{% 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`:

```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](https://grammarly.com) and [Claude Code](https://claude.ai/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

Thu, 19 Feb 2026 14:00:00 +0000

If you use a Mac, you’ve probably noticed that the menu bar fills up with icons pretty quickly. [Bartender](https://www.macbartender.com) and [Ice](https://github.com/jordanbaird/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](https://micro.webology.dev/2024/06/04/bartender-mac-app.html). 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.

```shell
# 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

Wed, 18 Feb 2026 22:54:47 +0000

Today I learned about [displayplacer](https://github.com/jakehilborn/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:

```shell
[1] [2]
[3] [4]

```

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

```shell
[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:

```shell
#!/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

Thu, 11 Dec 2025 01:43:48 +0000

My friend [Trey Hunner](https://treyhunner.com) 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](https://mise.jdx.dev). 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](https://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](https://github.com/JoeInnsp23/claude-glm-wrapper) 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:

```bash
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:

```bash
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](https://github.com/musistudio/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](https://z.ai/subscribe?ic=GLMN4NLXLV) (affiliate) or feel free to use [Trey Hunner’s invite link](https://z.ai/subscribe?utm_medium=edm&utm_content=blackfriday&_channel_track_key=PJg2GPj2) (affiliate) instead. Resources --------- - [Claude GLM Installer tool on Reddit](https://www.reddit.com/r/ClaudeCode/comments/1nv64g5/i_made_a_tool_to_use_zais_glm_models_with_claude/) - [claude-glm-wrapper on GitHub](https://github.com/JoeInnsp23/claude-glm-wrapper) - [claude-code-router on GitHub](https://github.com/musistudio/claude-code-router) --- Written by Jeff. Edited with [Grammarly](https://grammarly.com) and [Claude Code](https://claude.ai/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

Sun, 23 Nov 2025 05:01:54 +0000

I’ve been fighting a runaway [OpenAI](https://openai.com) 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](https://www.digitalocean.com) to [Hetzner](https://www.hetzner.com). 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](https://djangotv.com) project. I use the [OpenAI API](https://platform.openai.com/docs/api-reference/introduction) to help parse presenter names and clean up titles whenever we add new videos. I had recently added [DjangoCon US](https://djangotv.com/videos/djangocon-us/2025/) videos and [Wagtail Space](https://djangotv.com/videos/wagtail-space/2025/) videos during the last two weeks, both on the same day our LLM usage spiked. I checked my [Django-Q2](https://github.com/django-q2/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](https://ai.pydantic.dev) 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: 1. **Timeout issues**: Tasks were timing out after 90 seconds when processing large batches 2. **Bulk processing**: Processing all videos in one call instead of individual async tasks 3. **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](https://grammarly.com) and [Claude Code](https://claude.ai/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

Thu, 20 Nov 2025 00:37:48 +0000

So, picture this: you’re working at a walking desk, you’ve got a cool voice-to-text tool like [MacWhisper](https://goodsnooze.gumroad.com/l/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](https://www.amazon.com/dp/B0BW15CPTY) 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. ![The BTXETUEL 4-Key Mechanical Keyboard vibing](https://cdn.uploads.micro.blog/137490/2025/b388258f45.png)### 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](https://chatgpt.com). Edited with [Grammarly](https://grammarly.com) and [Claude Code](https://claude.ai/code). Originally posted on: https://micro.webology.dev/2025/11/19/the-vibe-coding-keyboard-how/

📅 Office Hours for November

Thu, 13 Nov 2025 23:08:22 +0000

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](https://time.is/0230PM_14_November_2025_in_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](https://time.is/0230PM_21_November_2025_in_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](https://policies.python.org/python.org/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/

Default Apps 2025

Wed, 29 Oct 2025 23:55:03 +0000

2025-10-29 Default Apps 2025 ============================ Here are my Default Apps 2025, which builds from my [Default Apps 2024](https://jefftriplett.com/2024/default-apps-2024/) and [Default Apps 2023](https://jefftriplett.com/2023/default-apps-2023/) posts. 🤖 AI Coding Assistant: [Claude Code](https://claude.ai/code) + [GitHub Copilot CLI](https://github.com/features/copilot/cli) + [Codex](https://openai.com/codex/)⚙️ Automation: [Hammerspoon](https://www.hammerspoon.org)🎒 Backups: [Backblaze](https://www.backblaze.com)🔖 Bookmarks: [Raindrop.io](https://raindrop.io)🌐 Browser: [Vivaldi](https://vivaldi.com)📆 Calendar: Apple Calendar 💬 Chat: Apple Messages (family & friends), [Discord](https://discord.com/) (friends), [Slack](https://slack.com/) (work and community work), [Telegram](https://telegram.org) (weird bots) 📁 Cloud File Storage: iCloud Drive + [Syncthing](https://syncthing.net)🧑‍💻 Code Editor: [Sublime Text](https://www.sublimetext.com/) + [Zed](https://zed.dev)🤖 Containers: [OrbStack](https://orbstack.dev) + [Docker Compose](https://www.docker.com)✍️ Grammar: [Grammarly](https://grammarly.com)🚀 Launcher: [Alfred 5](https://www.alfredapp.com)📨 Mail Client: [Mimestream](https://mimestream.com) (Gmail only and not very often) 📮 Mail Server: [Fastmail](https://www.fastmail.com) (I pay for it but still don’t use it enough) + Gmail 👔 Menu Bar: [Ice](https://icemenubar.app)🎵 Music: [Apple Music](https://www.apple.com/apple-music/) + [Spotify](https://spotify.com)🔐 Password Management: [1Password](https://1password.com/)🎤 Podcasts: Apple Podcast 📑 Read It Later: [Raindrop.io](https://raindrop.io)🔗 Remote Access: [Tailscale](https://tailscale.com)🗓️ Scheduling + Booking: [Cal.com](https://cal.com)🖼️ Screenshots: [Xnapper](https://xnapper.com)🔍 Search: [Kagi](https://kagi.com)🐚 Terminal: [iTerm2](https://iterm2.com) + [Ghostty](https://ghostty.org)🌐 Terminal Proxy: [VibeTunnel](https://vibetunnel.sh)🎙️ Transcription: [MacWhisper](https://goodsnooze.gumroad.com/l/macwhisper)🗃️ Version Control: [Tower](https://www.git-tower.com)📹 Video Calls: [Zoom](https://zoom.us) + [Cal.com](https://cal.com) + [Meeter](https://www.trymeeter.com)✈️ VPN: [Mullvad](https://tailscale.com/mullvad)📝 Writing: [Obsidian](https://obsidian.md/) Commentary ---------- The biggest changes for me this year were the addition of more AI tooling like coding assistants, VibeTunnel, and the MacWhisper voice translating app. A year ago, I was writing my own AI coding tools with Python. Today, I use voice-to-text to interact with multiple coding assistants that I can access from any browser connected to my Tailscale Tailnet. It’s a mouthful to explain, but coding looks very different now than it did a year or two ago for me. I’m not using Google Apps as much as I was a few years ago, though I still need to switch between Google Orgs for work and community organizations. Changes from 2024 ----------------- **New Additions:** - AI Coding Assistant (Claude Code, GitHub Copilot CLI, Codex) - **VibeTunnel** for accessing my terminal through any browser on my Tailnet - I started using **Ghostty** to run my AI sessions, but I find its lack of find (⌘f) support to be terribly frustrating. - I have used MacWhisper for years, but now it’s a daily driver. I can hold down the globe (fn) key on my keyboard and talk to my computer and quickly reply to people or even write blog posts with my voice. It’s incredibly cool and powerful. **Apps Removed:** - I dropped **Polypane** (Browser category) - I managed to not use **Overcast** (Podcasts category) for most of the year, but I’m still not happy with Apple’s Podcast app. I might be switching back. Previously inspired by: “Apps I’ve been using regularly this year.” Heavily inspired by [Matt Stein](https://mattstein.com/thoughts/default-apps-2023/) and cataloged by Robb Knight’s [App Defaults](https://defaults.rknight.me) Originally posted on: https://micro.webology.dev/2025/10/29/default-apps-here-are-my/

🤖 On GitHub Copilot CLI and prompts as code

Sun, 05 Oct 2025 01:57:19 +0000

I checked out William Vincent’s [The Secret Prompts in GitHub Copilot CLI](https://wsvincent.com/copilot-cli-secret-prompts/) tonight, and I wanted to share a few tips and what stood out to me. GitHub Copilot CLI uses Claude Sonnet 4.5 by default ---------------------------------------------------- > No luck other than confirming it is using Claude models by default. Apparently, you can change the underlying model, for example, to ChatGPT 5, by updating the environment variable `COPILOT_MODEL=gpt-5`; however, we will work with the defaults here. You can Copilot CLI’s default model via the `/model` command and it will also let you pick between three models.

```shell
 Select Model

 Choose the AI model to use for Copilot CLI. The selected model will be persisted and used for future sessions.

 ❯ 1. Claude Sonnet 4.5 (default) (current)
   2. Claude Sonnet 4
   3. GPT-5
   4. Cancel (Esc)

 Use ↑/↓ to navigate, Enter to select, Esc to cancel

```

I’m somewhat surprised that GitHub CLI isn’t shipping with `gpt-5-codex` model support yet. From my testing, it appears to be OpenAI’s best coding model, but it may be shipping soon. The “You are” trick ------------------- > Well, what we “really” care about are any prompts that start with “you are” since those are instructions from Copilot CLI to the model. The “you are” tip is one I shared with Will and [Simon Willison](https://simonwillison.net), which I have used for a few years when trying to find a tool’s system prompt, which is always buried and obfuscated in their JavaScript files. Simon and I were invited to Microsoft HQ last month for an AI Insider’s summit (I prefer not to use the term influencer), where we were given early access to GitHub Copilot CLI before the public release. The first thing we both did was dive into the system prompt to see what it contained. Every system prompt has “You are” buried in it somewhere, which makes it much easier to find that paging through 10k lines of JavaScript. Use Xml tags in your prompts ---------------------------- Will posted the Copilot CLI’s system prompt, and one thing that stood out to me was the various XML-tagged sections, such as `` and `