Parakeet has long been a fan favorite local transcription model in Quick Subtitles. Apple's is slower and not as accurate, while Whisper is a little bit more accurate, but is way slower. With the combination of high accuracy and massively better speed, why go with anything else, right?

Well, what if we could take Parakeet's already outstanding performance and accuracy, and make it faster? A lot faster…

TLDR: I've multi-threaded Parakeet in the Quick Subtitles CLI so it runs about 3x as fast as before, and is available now. The main app will get this in a few weeks, and is currently available in beta for More Birchtree subscribers.

The results

I threw the model at the latest episode of Comfort Zone, which is 102 minutes long. Using the updated version of the CLI transcribed it in 12 seconds on the M4 Pro and 8 seconds on the M6.

Eight. Seconds.

These numbers are clearly outrageous, so how did we get here?

Transcription is single-threaded

I was doing some investigation into how the three transcription models I use scale. It turns out Apple's model does almost all of its work on the CPU and will utilize one performance core. Parakeet behaves very similarly, also limiting itself to whatever your fastest core can do. Whisper is a bit different, doing almost all of its work on the neural engine. This is shown in the chart above, which shows power consumption over a run of transcriptions using each model.

In terms of opportunity to speed things up, I only had options on one of these. Apple doesn't allow developers to choose how many cores their transcription model runs on, so there's nothing I can do there. Whisper is powered mostly by the neural engine, which is already multi-threaded and is doing all it can. See below for what happens to transcription speed when on the Mac you force Parakeet and Whisper to run only on an efficiency core.

Parakeet is mostly powered by the CPU, though, so if I could get that running on multiple cores, we might see better speeds. I dug deeper into how Parakeet works (via FluidAudio), and actually, it's already cutting up files into 15-second chunks and transcribing each chunk sequentially. By assigning each chunk to a different core, I'm able to get through the file quicker.

However, as it goes with computers, once you unlock one bottleneck, the next one appears, and that's the neural engine. While the neural engine is not the main contributor in this process, it is part of the process, and I found in my testing that once you get past 4 cores giving data to the neural engine, it can't keep up and you stop getting meaningful benefits after that.

What’s interesting is that I do my development on an M4 Pro Mac and I know the M6 has a new neural engine with twice as many cores, so I wondered if this would be improved on that device. I did the exact same test and surprisingly the answer is no. Here are the performance numbers when using 1-8 cores on each device.

Improvements decrease with each new core, and once you get to 4 cores, you're basically capped out, as the CPU simply builds up a queue elsewhere in the system, which as far as I can tell can not presently be increased. Although let's put this into perspective, on a base M6 processor, we're transcribing up to 12 minutes of audio per second…that's pretty damn good.

Availability

I've done quite a bit of A/B testing and the results are exactly the same, so going forward, this is just how Parakeet will work in Quick Subtitles. There's no need to select a "Turbo" option, it'll just be the fastest damn version of Parakeet you can get anywhere.

It is available now in the Quick Subs CLI which you can install with…

brew install mattbirchler/tap/quicksubs

…or by upgrading if you already have it.

Those using the app will get this in the next update, which is coming in the next few weeks.

The US Department of Transportation finalized its plans today to weaken fuel efficiency standards, calling it “among the largest deregulatory actions under the second Trump Administration.”

I just think there's something wild about Republicans in the US constantly advocating for things to get objectively worse. You want cheaper, cleaner energy? Nah, let's boost dirty, expensive energy production! You want better gas milage in your car? Nah, let's make sure car makers can make it worse. The vast majority of people want more restrictions on data centers? Nope, how about we make it easier for them to be built where people don't want them and also ensure they can be as dirty as possible.

Users have shown — again, I don’t need to prove this — that they don’t think about a stock Mac app vs. custom. Do they dislike Things for not having a toolbar at the top of the window that they can customize in the usual way? No. (The only people who think that way are longtime Mac developers like me.)

Birchfeed allows you to set up an email address to receive newsletters which appear as feeds in the app. However, some people (including me) would actually like to see these in their email inbox as well. Now you can enable this in the Newsletters settings in the app.

For spam reasons, you can't just forward these emails anywhere, so they go to your account's email by default, and you can change it to something else, but you need to verify ownership of that email as well.

Birchfeed is fundamentally a backend service that you will mostly use through a third-party client, such as Unread, Reader Classic, or NetNewswire. I always want that primary use case to be really solid, and I think it is right now.

However, one of the reasons I wanted to build an RSS sync service was that I thought there was more I could do to help people have a better experience. Since launch, the most popular feature outside of the core sync functionality has been the daily briefing, which most users have enabled. This sends you a daily email with the most notable stories across your feeds, as well as a few highlights I think are worth checking out. Maybe you don't have time to go through the hundreds of posts that have come in today, but you can see the big headlines in 15 seconds.

Catch up

Today, I've launched a new feature aimed at getting you caught up, which is called "catch up". This will appear when you have over 100 unread items, and it will try to find stories and individual articles that stand out from everything else and presents it in a landing page format. If Reddit's old slogan was "the front page of the internet", Birchfeed's can be "your front page of the internet".

How it technically works

Similar to yesterday's update to Best-o-Masto, this uses Jev to rank the interest of hundreds of recent articles. Then GPT-6 Luna groups them and writes quick summaries.

Availability

The catch-up feature is available for all users on a free trial or paid subscription. For now, I'm limiting this feature to two runs every 24 hours while I monitor costs, and will loosen it up if it makes sense to.

Every single app and app update released in the App Store goes through this review process, and the review process is largely a black box. Developers submit, and then wait. They are given no specific timeline or indication of how long the review will take, and it’s inconsistent. Some reviews happen in hours. Some take days. When you’re rejected, you can reply to Apple, make fixes and resubmit, or appeal — and whichever path you pick, you’re waiting again, with no specific timelines provided from Apple.

The unpredictability of app review is definitely one of the core annoyances with it. I never know how long a review is going to take. Sometimes it's a couple hours, sometimes it's a couple weeks. Sometimes an app will be stuck in review for several days, and I wonder if something's gone wrong or if it's just taking a long time or if the reviewer has simply forgotten to drag their ticket to done yet. It's impossible to tell. The one thing you're definitely feeling is that no matter how long it's stuck in there, you don't necessarily want to cancel it and start over because you might have to go through this whole wait again.

I'm not arguing for boycotts, I know that people are bound to different platforms for different, compelling reasons. What I am arguing for is that, given the opportunity, you try and reduce the value they can extract from you. That's very often your data, but it can also be a direct financial relationship.

Be the guy who only buys the loss-leaders.

As of today, you nerds who like to read later can do so from your terminal with the Quick Reads CLI. Install it with:

brew install mattbirchler/tap/quickreads

And from then on, it will update with brew upgrade like everything else.

Okay, what does it do?

It does a lot, actually. When you run it, it opens straight to your reading queue, just like the app and the web do. You can read whatever you want. You can add highlights. You'll see highlights already added. You can look at your to-do list and archive. You can search across your entire account. Most of the things you can do on the app/web are here.

But why?

I don't pretend to think that this will be the most common way people interact with Quick Reads. Clearly not. However, there are times where it is useful to have a command line interface. Quick Reads aims to be the most flexible and developer-friendly read-later service out there, and that means meeting people where they are, even if they're in a niche. With this update, you are able to interact with the service through the iOS app, on the web via Apple Shortcuts, directly with a fully functional API, an MCP server, or now, a CLI. That's something simply nobody else in this space can match.

Best-o-Masto is my website for finding the best stuff from your Mastodon and Bluesky feeds quickly. It's not an algorithmic feed like you'd see on something like X or Threads. It's a very simple thing that finds the post getting the most engagement in your feed and serves those first.

The iOS app has had a feature since launch called "hidden gems", and the idea of Hidden Gems is that not all of the posts you might want to see are going to get the most boosts and favorites. Hidden Gems attempts to surface these interesting posts that maybe didn't get as many engagements, but you still probably want to see. That feature has been powered by Gemini since launch, and it works fine, but it's slow and costs real money to run. As such, I've always made it available exclusively as a bring your own API key situation rather than something just built into the app.

But recently, a new model came out called Jev, which is not a language model – it's effectively a decision engine which can (relatively) intelligently classify things for you. It's also incredibly fast and incredibly cheap. The metrics vary by what exactly you're doing, but we're talking in the order of being 200x faster and 400x cheaper in some cases.

Of note, this feature is completely opt-in for users, so if you have no interest in this sort of feature, just don't use it.

The feature is in beta as I monitor costs/reliability.

How it actually works

This might be interesting because it is different from other LLMs. In a way, integrating to a large language model is the simplest API you've ever used because you just kind of toss in whatever text you want and it figures it out, giving you text back.

We're about to get into the weeds, but I think showing actual code is going to be helpful here to understand how this works. Using some completely made up posts, here's an example of what the request looks like when I look for hidden gems.

{
  "model": "typesafe/jev-1.13",
  "state": "POST 1\nFinally finished the quilt I started in 2019. Four moves and one pandemic later.\n[2 images, alt: A blue and white patchwork quilt draped over a chair]\n\nPOST 2\ngood morning everyone",
  "questions": {
    "p1": {
      "type": "score",
      "instructions": "Consider POST 1 only. How interesting would this social media post be to a reader who follows the author, ignoring how popular it is?",
      "criteria": [
        "Mundane, low-effort, a bare link, a greeting, or a reply that needs missing context",
        "Mildly interesting but forgettable",
        "Worth reading: a good joke, real insight, personal story, life event, or creative work",
        "A standout the reader would be sorry to have missed"
      ]
    },
    "p2": {
      "type": "score",
      "instructions": "Consider POST 2 only. How interesting would this social media post be to a reader who follows the author, ignoring how popular it is?",
      "criteria": [
        "Mundane, low-effort, a bare link, a greeting, or a reply that needs missing context",
        "Mildly interesting but forgettable",
        "Worth reading: a good joke, real insight, personal story, life event, or creative work",
        "A standout the reader would be sorry to have missed"
      ]
    }
  },
  "provider": {
    "data_collection": "deny",
    "zdr": true
  }
}

This sample only sends two posts, but in reality I pass in the text of several hundred posts in the state variable, then I pass questions where it looks at specific posts in the state, and it determines a score for each one. Each post can get a score from 0-3, with 3 being the most likely hidden gem. Because Jev is not a language model, it doesn't generate text in its response. All it does is take a look at the state, the instructions, and decides which criteria it meets. It does that across every single question provided.

Here's an example response:

{
  "model": "typesafe/jev-1.13-20260917",
  "answers": {
    "p1": {
      "type": "score",
      "score": 2,
      "legend": {
        "0": "Mundane, low-effort, a bare link, a greeting, or a reply that needs missing context",
        "1": "Mildly interesting but forgettable",
        "2": "Worth reading: a good joke, real insight, personal story, life event, or creative work",
        "3": "A standout the reader would be sorry to have missed"
      },
      "probabilities": { "0": 0, "1": 0.01, "2": 0.98, "3": 0.01 },
      "confidence": 0.98
    },
    "p2": {
      "type": "score",
      "score": 0,
      "legend": { "...same four lines..." },
      "probabilities": { "0": 1, "1": 0, "2": 0, "3": 0 },
      "confidence": 1
    }
  },
  "usage": {
    "input_tokens": 555,
    "output_tokens": 32,
    "cost": 0.00002331
  },
  "id": "gen-dec-1790707300-J2N6sJCCxL9IWgYlVnr5",
  "provider": "TypeSafe"
}

Here in the response, we can see that each question was scored. The first was scored a two, the second scored zero.

You can also see that there are probabilities assigned to each score, giving you an idea for what the odds are it falls into each category. There's also a confidence score of how confident it is in its assessment. Both of these were pretty straightforward, but as you get more complex content, the answers may be a bit fuzzier.

As a developer, the next step is pretty darn easy. Now I have a list of posts with scores attached to them, and I can just sort from biggest to smallest, displaying the 3s, then the 2s, and the 1s. The idea of this product is not to show you every single post in your feed, so it cuts off after the first 15.

Future Plans

I've always really enjoyed the feature in concept on iOS, although I've always felt a little bit disappointed by it in execution, largely because I require users to bring their own API key since I'm not able to absorb the costs, and it's just fundamentally slow because you're passing a lot of information into a language model and waiting for it to generate a full response with the post IDs it thinks are interesting. This has led to me personally not using this feature much.

This new implementation is really interesting because the results seem quite good in my testing so far, the performance is radically better, and the cost is seemingly negligible. I'll be closely monitoring my spending to make sure it doesn't get out of control, but it looks like this is something I can just offer for free on the web. If it stays okay, it'll be something I bring to the iOS app as well.