In late April, I discovered exe.dev through “I am building a cloud,” a widely shared blog post by its co-founder, David Crawshaw.¹ Since then, I have been playing around with VMs on exe.dev. In this post, I share my experience and some thoughts about it. (If seeing David Crawshaw’s name was already enough to convince you, there’s an invite link at the end of this post.)

Users can create multiple VMs on exe.dev and let AI agents run in them without worrying that agents might break their local machines. There are many cloud VM options on the market, but exe.dev takes a very different approach to how VMs are positioned and used, and the result is surprisingly easy to use. I’m not a programmer. However, even I can use it after reading a few lines of their documentation—yes, no AI help needed here.

In the past few weeks, I mostly experimented with moving projects to different VMs, letting agents work on them, and building out my dotfile setup. At first, I didn’t really use exe.dev’s built-in coding agent, Shelley. It’s an agent that can use models such as Claude Opus and other leading LLMs. Users can also bring their own LLM provider API key or ChatGPT subscription, and use Shelley through the web interface.

A few days ago, I decided to use Shelley to build something useful. First, I cloned a template VM that I had created for the dotfile management practice with a single command: ssh exe.dev cp [my-source-vm-name] [new-vm-name], and in a few seconds, I got a new VM for development. Next, I asked Shelley to use Astro to build me a personal website and host it on another exe.dev VM. My spec was simple: using the style of this website (the one you are reading) and referencing another website for the structure. Shelley then asked me a couple of questions for clarification, such as whether I wanted one or two columns and where the navigation should go. The only thing I had to do manually was create another VM for the production site.

Once everything was set up, Shelley began to work. And that’s it. In just a few minutes, I got a website with all my content copied from this blog, and I could view it through a private link without additional configuration. I can later make it public under my own domain. By that point, it had cost about $4 in credits. (My plan includes $20 in credits per month, plus a one-time $100 credit that doesn’t expire. I can purchase additional credits if needed. You can check the pricing page for the latest plan details.)

Although there are still parts of the website I’d like to refine, I’m impressed by how quickly the whole thing came together. Shelley can capture screenshots of the page as it works and use them as feedback during development, or simply show them to you after a change—just like the feedback loop I wrote about in this post. My original plan was to put together a thorough plan with Codex or Amp and then let one of them do the job. I also expected to spend a lot of time reviewing the output. Not to mention all the infrastructure-related decisions, such as hosting, networking, and security, especially since I wasn’t planning to make the site public yet.

I know this is not a perfect comparison, because I was used to working with agents under conservative permission settings, while Shelley is designed to require fewer permission prompts.² And because I mainly wanted to try Shelley, I gave it a fairly simple spec.

Building the website was impressive, but what ultimately got me interested in exe.dev wasn’t the website itself. It was the idea that my agents could have their own computers.

Your Agent Needs a Computer

Before exe.dev existed, David Crawshaw and Josh Bleecher Snyder were already building what we would now call a coding agent. One thing they learned from that work was that agents needed their own isolated environment instead of running directly on a developer’s machine.

At first, they thought containers were the answer. But as they brought the product to more companies, each one seemed to expose a new reason why containers weren’t quite enough.³ Eventually, they concluded that agents needed their own computers. And that became one of the reasons they built exe.dev. It went online in late December 2025.

Don’t get me wrong. exe.dev is not just a disposable sandbox. The VM can host a database, run services, keep files around, and serve as a long-lived workspace for either a developer or an agent.

What makes it different is how lightweight it feels. When I need a VM for a quick experiment, I can get one instantly and it is ready to go. Creating a VM on exe.dev feels more like creating a new folder on my computer than provisioning a new server. Crawshaw wrote this in his post that I mentioned earlier:

A Linux VM is a process running in another Linux’s cgroup, I should be able to run as many as I like on the computer I have.

I think that captures the philosophy behind exe.dev.

As I learned more about exe.dev and its co-founders, I found that David Crawshaw and Josh Bleecher Snyder both worked at Tailscale; Crawshaw was even one of the co-founders and the CTO of Tailscale. If you have read this blog for a while, you probably know I really like Tailscale. In this post, I described how I use Tailscale:

When I take a break between bouldering sessions, believe it or not, I sometimes use the Termius app on my iPhone to SSH into my Mac at home, check Claude Code’s work, or assign it new tasks via tmux running in Ghostty on my Mac.

I want to access my computer and manage my agent anytime I want when I’m on mobile. In this case, I can access my exe.dev VMs in the same way I mentioned above, or just using exe.dev’s mobile web. But now we have a new option with a better experience: an iOS app.

Voice Mode in the iOS App

I’ve been in their TestFlight since mid May, and it’s now in the App Store. The app’s quality is pretty good. There is a special feature I want to talk about: the voice mode.

The voice mode is a voice interface between the user and Shelley, powered by OpenAI’s Realtime API. When I tried this feature for the first time, I thought: why bother? I can just use dictation in the text chat interface with Shelley. But later I realized that the voice mode is different. I can simply tap the microphone icon and start talking, then the voice assistant relays my words to Shelley. When Shelley is done, I get a notification with the result. Most importantly, it can run in the background. In this way, the interaction feels more natural. I don’t have to pick a VM or open a new conversation with Shelley first. Just one tap and start talking.

The only thing I’d like to see improved is what happens after Shelley finishes a task. Right now, I need to come back and ask the voice assistant for an update. It works, but it feels slightly less natural than the rest of the experience.

Interestingly, if I ask something like, “Is there anything that needs my attention?”, the voice assistant can already answer me. From what I understand, it isn’t even talking to Shelley at that point. It’s simply reading from the system’s attention list. That’s why I can’t help but wonder how much more seamless the experience would feel if the voice assistant could proactively surface those updates instead of waiting for me to ask.

My agents now have their own computers, and I can access and manage them from anywhere, by text or by voice. I think it’s great!

Further Reading

You might also be interested in these two posts:

• Proxies all the way down.
• Building the exe.dev iOS app

If you’d like to try exe.dev, you can use my invite link because it will give you a 30-day trial (normally it’s a 7-day trial), and if you upgrade to a paid plan later, we will both get an extra 6 GB of RAM! (The referral reward may change in the future.)

When I was developing my little Mac app with Claude Code, I took many screenshots and shared them with the agent as feedback. You know the drill: press the keyboard shortcut to capture the screenshot directly to the clipboard, and then paste it into Claude Code’s message composer. Sometimes I have to capture many screenshots at once. However, there is no built-in feature that allows you to save multiple screenshots as separate items and then paste them individually into the message composer. I have to pick the images I need in Finder, copy and paste each image.¹ When things aren’t going well, that process becomes especially painful.

About ten days ago, I saw a post on X from Thorsten Ball, an engineer at Amp. He said:

I didn’t quite understand what he actually did at the time, because I missed his follow-up post.² But it sounded really compelling. A few days ago, he mentioned the feedback loop again on X. This time, I did find the Amp thread he shared, but I thought the --capture flag was from a custom command or an MCP. I couldn’t figure it out. However, I believe he would talk about it on a live stream someday.

And here it comes, Thorsten Ball and his colleague, Ryan Carson, did a live stream on X. One of the topics is about Thorsten Ball demonstrating how the agent uses the feedback loop to make his terminal emulator correctly display the colors (around 22:43). And I finally understand, in broad strokes, what the --capture mode actually is and how the feedback loop works. As someone who isn’t an engineer, I found this genuinely eye-opening.

What Thorsten Ball did was asking Amp to build a feedback loop for itself, so it could see what was rendered on the GPU. And the result is not an external script or a MCP; it is built into the codebase, the terminal emulator that Thorsten Ball was developing. It is a feature built into the terminal emulator for the agent to use, not for the user.

Ryan Carson asked him, “how long did it take you to build the --capture feedback loop? Was that like a day?” “No, this was 20 minutes,” Thorsten Ball answered.³

Did I say that I found it eye-opening?

You need to watch the demo yourself to feel it. The agent not only wrote the code but also took screenshots to verify that its implementations worked as expected.

Thorsten Ball also made another fun demo. They called it a “prompt shootout” (around 44:47). He opened two terminal windows with Amp running in them, side by side. And then he made two different prompts for each agent, to ask them to fix an htop displaying issue in his toy terminal emulator. He asked one agent to use the feedback loop in the first prompt. And in the second prompt, he didn’t mention there is a --capture mode for the agent to use. You can see that the results are worlds apart, especially for this kind of task.

While I was watching the video, I couldn’t help thinking about my little Mac app’s settings window. Would it have been less painful if I had built a feedback loop—a --capture mode—into the codebase when I was vibe coding the app?

From my perspective—and maybe this analogy is imperfect—it’s like: I know FSD (Full Self-Driving) is a thing, and it’s getting better and better. But it’s another thing entirely when you actually see a car find its own parking spot after you get out, then drive itself back to pick you up when you need it.

At the end of the video, Thorsten Ball said, “I think that’s how codebases are going to change.” “… you want the ability for the agent to get feedback about what it’s working [on] and that’s not just good for the agent; it’s good for the human.”

At this point, if you think I’m exaggerating, hear Ryan Carson’s reaction: “… oh my God, I just—I never thought I’d get goosebumps talking about code, but I just did.”

“I think with these models getting better, I’ve been starting to think that the goalposts have shifted again,” Thorsten Ball said.

No wonder that Zed Industries, the company behind the Zed editor, wants to develop a new kind of database for future collaborations between human engineers and AI agents.³

It’s a great time to witness the AI-driven evolution—if not the outright revolution—of human–computer interaction. I can only imagine how dramatically things will change in the next few years (or months).

→ Flowing with agents with Beyang Liu, CTO of Sourcegraph (Changelog Interviews #658)

When working with a coding agent, do you consciously keep the conversation short and start a new thread for a new task?

In September, Sourcegraph’s co-founder and CTO Beyang Liu took an interview on the podcast, Changelog Interviews.¹ In the show, he shares his observations on how senior software engineers use coding agents. Compared with how non-engineering users tend to use them, he offers the following advice:

I would actually recommend… you should treat threads sort of like one-and-done, rip-off notes. Rip them off frequently rather than do the whole… like You don’t need to build the entire app inside a single thread. In fact, I would probably recommend against doing that, because you will get lower quality, higher latency, and more cost if you do that.

I am writing this post as a reminder to myself, because I was one of those people who kept working with the coding agent in the same thread, even when the tasks weren’t related, until we ran into the context limit.

A couple of months ago, I used ChatGPT to turn an idea into a little Mac app. I first used ChatGPT’s web app, and I made a workable prototype in an afternoon. (It’s incredible!) Later, I started using ChatGPT’s Mac app alongside Xcode. Eventually, I switched to Claude Code because of its reputation for coding.

I had been working with Claude Code in the same thread the whole time, handing it one task after another, until auto compact kicked in. Back then, I knew the thread would need compaction once we got close to the context limit, and I never really thought about why there was even a command to compact the conversation manually. Then one day I realized something was off: Claude Code suddenly seemed “dumber.” Even though we were still in the same thread, it seemed to have forgotten what we had talked about earlier and the tasks it had already completed. It was frustrating.

That was the moment I understood that the thread itself had become the problem.

Now I get it. After I listened to the podcast, I changed the way I work with coding agents. When I normalize my news database and build things on top of it with Amp, I keep threads short and, when possible, start a new one or use Amp’s handoff feature.

If you have the same issue I had, you can also read this guide on managing context from Amp. As the guide puts it, “The longer your conversation goes on, the higher the chances are the model goes ‘off the rails’: hallucinating things that don’t exist, failing to do the same things over and over again, declaring victory while standing on a mountain of glass shards.” It clearly explains why the user should manage context consciously, illustrated with diagrams created in Monodraw. And if you happen to be an Amp user, the guide also provides a series of features for working with the context window in Amp.

I’ve been following the news about technology, startups, and venture capital firms for a long time. Every once in a while, I try to keep track of the names, the people and companies involved, and what they did when I’m reading tech news. But it always ended up like my childhood attempts at news clipping: I eventually gave up because it was too time-consuming and labor-intensive.

I still take notes when I read the news. However, if I could extract that kind of structured information from the news, that would be a good add-on.

Like many others, I’ve been playing around with AI since ChatGPT came out. One day, I read a post from Simon Willison. Through the links in it, I learned about LLM, a CLI tool and Python library he developed for interacting with LLMs (large language models). (To avoid confusion, I will refer to this tool as “LLM CLI” throughout the post.) As I read through the user manual, I discovered an interesting use of LLM CLI in the Schemas section, and eventually, I put together an AI-powered news clipping workflow.

In this post, I want to share how I built my AI-powered news clipping workflow. I’ve been using and tweaking this workflow from time to time since the end of May, when I started using LLM CLI. I’ll walk through the tools I used and how the system is structured, and hopefully this post will inspire you to adapt the idea for other types of news that interest you. If you are familiar with CLI tools, I think it would be easy to build. If you’re not, with some help from ChatGPT or Claude, it could also be done. (I’m the latter one.)

How it Works

Basically, I want to have an LLM to do the news clipping job for me.

It’s like hiring an intern to read the news I assigned, make news clippings, and organize them into collections that I can easily refer to whenever needed.

What I built is an automatic workflow of extracting and classifying information of tech news, especially the news about tech startups and VC firms, using the LLM I chose. Here is a simplified overview of my workflow, and I will leave some details for later:

1. I read a tech news article about a startup that raised funding from several venture capital firms. Then I decide whether to add those persons, organizations, and incidents into my database. You may wonder why I don’t record as much startup news as possible without reading it first. I will address this question later.
2. I send the news text to a remote LLM, such as ChatGPT or Gemini, through LLM CLI. The model extracts structured information from the article, including the people and organizations mentioned, whether they are VCs, their roles, and the actions they took, and returns it in valid JSON format.
3. I review and import the extracted data into a SQLite database, which I can later query or review as needed.

Take this news article, 〈Zed Raises $32M Series B Led by Sequoia to Scale Collaborative AI Coding Vision〉, as an example. The returned structured data looks like the following:

After importing, it will look like the following screenshot in a database:

Eventually, I combined parts 2 and 3 into one command. If I want to skip the review step, I can just read the news and send it to an LLM, and the news clipping job gets done.

Why I Built This Workflow and How I Use It

Before we move on, I must emphasize that I only apply this workflow to news articles I have personally read. I’m not inclined to process as much news as possible just because it can all be done quickly and automatically. I built this tool to give myself a “sort of” reliable source that helps me keep a close eye on tech and the VC industry.

Another thing I hope you keep in mind is that my workflow is not intended to achieve 100% accuracy. And that’s why I say this workflow is “sort of” reliable.

In my experience, an LLM often succeeds in determining whether someone is a VC based on news content, but for various reasons it sometimes misses. The LLM’s accuracy can never reach 100%. For that reason, I don’t count on it to generate 100% correct data. And that’s why I only use it to process what I read, not what I didn’t read. 

After all, I have some confidence in remembering what I read. If I need to check something, the database is always a few keystrokes away. I can retrieve the source (the news article I read) from it.

A good way to think about LLMs is to treat them like interns. Sometimes you feel grateful for their contribution and think they have a lot of potential, and sometimes you feel you should have done the work yourself. As technology analyst Benedict Evans often compares AI to interns, he once said:¹

If you have 100 interns, you can ask them to do a bunch of work, and you would need to check the results and some of the results would be bad, but that would still be much better than having to do all of the work yourself from scratch.

The Workflow Breakdown

Now, let’s take a closer look at how my workflow operates. The workflow consists of the following steps:

1. Read a news article
2. Prepare the text content of the news articles I’ve read
3. Pipe the news content text to LLM CLI. It will treat the piped content as part of the prompt it’s about to send with other things/arguments to the LLM you designated.
4. Apply the schema and template. They are the keys to our workflow. We need a way to make sure that the LLM will return the right structured data we need in valid JSON format. To achieve it, we use LLM CLI’s schema and template features. We will talk more about them later.
5. Get the LLM’s response in a valid JSON format
6. Import the data into a SQL database
7. Review, query, or update the data as needed

What We Need

Most parts of my workflow run in the terminal shell. I use zsh in Ghostty. And to build up this news clipping workflow, we also need:

• An LLM API key (or you can use a local LLM)
• A tool that can fetch the news content. I use the Readwise Reader API to retrieve the full text of the articles I’ve saved and their metadata. There are other options, such as Instapaper’s Full Developer API or Jina AI. In the LLM CLI user manual, Simon Willison uses strip-tags in an example. LLM CLI also supports attaching a PDF with a prompt and sending it to the LLM. So if, for some reason, I can’t extract the text, I can use PDF as a fallback
• A database. I use SQLite, which comes with macOS. I also use sqlite-utils and Datasette to work with the database, both developed by Simon Willison.

Step-by-Step Guide to Building the Workflow

Now we have all the ingredients, let’s make the workflow work. Here is an overview of the steps:

1. Get the Text

The first step is to get the full text of the news article I’ve read. I ask ChatGPT to write me a zsh function that I can use Readwise Reader’s tag feature or the article ID to designate which article I want to use, or use the latest article I saved, and then pipe the full text with some metadata, such as title and date, to LLM CLI.

If you just want to try it quickly, you can use Jina AI to get the full text of an online post (although it won’t be as clean as the results I got from Readwise Reader):

curl "https://r.jina.ai/https://www.example.com"
# replace `https://www.example.com` with the url of the news article you want to process

The cleaner the full text of the news article you send to the LLM is, the higher the chance you’ll get high-quality output. Or you can simply use a powerful (and usually more expensive) LLM to get a better output.

2. Install and Set Up LLM CLI

Before we move to the next step, you need to install LLM CLI. You can find the instructions on the website. I used pipx to install LLM CLI. But I’m considering using uv instead. If you want to use Homebrew to install LLM CLI, please read the warning note.

pipx install llm

After installation, you need to set up an LLM API token. If you want to quickly test many different LLMs and find the right one that can return the result you need, you need to install some plugins to use those remote LLMs from Anthropic or Google Gemini.

llm keys set openai

Then you will be prompted to enter the key like this:

% llm keys set openai
Enter key:

The default model is gpt-4o-mini. But you can change it as you want. With the corresponding plugin installed, you can use many models other than OpenAI’s.

After that, you can start designing and setting up the schema and template. Later, you can add the template as an argument to the -t option. You can find very detailed tutorials on setting up LLM CLI and other things we need on its website.

3. Design the Schema and the Template

The most crucial part is to make sure the LLM does precisely what you ask and returns the data in the correct format. And that, for LLM CLI, means designing the right schema and template, which determine what and how the LLMs extract information from the article and return it to you.

Fortunately, Simon Willison already provided a good foundation in the Schemas section of LLM CLI’s user manual. I basically added a few more items and tried it with different models to see what I got from the news articles.

As Simon Willison wrote in the Schemas section of LLM CLI’s documentation, “Large Language Models are very good at producing structured output as JSON or other formats. LLM’s schema feature allows you to define the exact structure of JSON data you want to receive from a model. [in this context, “LLM” refers to Simon Willison’s LLM CLI]”

In LLM CLI, a schema defines the exact JSON structure you want the model to return, including fields such as name, organization, role, and so on.

A template A template builds on top of that schema and includes the system prompt, model selection, and other options. By combining these parts, it tells the LLM what to extract and how the model should perform the extraction.

In practice, you can use a template to ask an LLM to extract specific information from a news article and return it as structured JSON data, which can then be imported into a database. Together, the schema and template features make it possible to reliably extract structured data from unstructured text.

Here, you can define a schema for what we want the LLM to return and save it as a template:

llm --schema $'items:\n  name\n  organization\n  role\n  is_vc bool\n  learned\n  article_headline\n  article_date' \
  --save people

Next, you can edit the template we just saved to tell the LLM how we want it to do the news clipping job. To edit a saved template, we can run:

llm templates edit people

This opens the template in your default shell editor (for example, the editor specified by $EDITOR or $VISUAL). After saving and closing the editor, the template is updated. The edited template may look like this:

system: |
  Extract all people and organizations from a startup funding article.
schema_object:
    type: object
    properties:
        items:
            type: string
        name:
            type: string
        organization:
            type: string
        role:
            type: string
        is_vc:
            type: boolean
        learned:
            type: string
        article_headline:
            type: string
        article_date:
            type: string
    required:
    - items
    - name
    - organization
    - role
    - is_vc
    - learned
    - article_headline
    - article_date

There are some interesting challenges for LLMs in extracting the correct information. For instance, sometimes Readwise Reader parses the commercial text in an article, and the text happens to be about VCs and startups. To prevent the irrelevant content from contaminating the data, you can added one line in the template: “Do not include any information that comes from advertisements, sponsored content, or promotional material.”

4. Pick a Model

The quality of the output we got (using the same template) depends on what model we use. LLM CLI provides a handy interface that lets us quickly switch between many LLMs via its plugin system.

After several iterations, I found that gpt-4o-mini is quite suitable for its cost, and of course, you can use a more powerful LLM like GPT5 to get better results, but it’s way more expensive. Considering the API cost and the quality of the results, I think Google’s Gemini 2.5 Flash Light is also one of the best choices. With these two models, I consistently get good results across different news articles from various outlets.

Because I don’t see the LLMs as 100% accurate tools, I think the key is to find the balance between cost and good-enough results.

If you want to check the LLM’s output before importing the data into the database, you can split the workflow into two parts and make the LLM’s return the breaking point.

5. Import the Data

LLM CLI has a great feature: it automatically logs every conversation to a SQLite database. (It can be turned off.) This means we don’t need to capture the model’s output immediately after receiving the returned data, because we may want to ask the LLM to modify the data or try another LLM. Later, we can extract the structured JSON directly from the logs and import it into our own SQLite database using sqlite-utils. (Here’s a link that explains how to work with the LLM CLI logs.)

To set up the uniqueness key and import the data:

# 1. Retrieve the structured JSON from the most recent LLM response
llm logs -c --schema t:funding_people --data > /tmp/funding.ndjson

# 2. Insert it into our SQLite database using a unique constraint
sqlite-utils insert data.db people_orgs /tmp/funding.ndjson --nl \
  --unique name organization article_headline

Using --unique here is intentional. Because we may need to make further adjustments in the near term, a unique constraint provides duplicate protection without forcing the table to use a rigid primary key. This makes the pipeline safe to rerun and easier to adjust as the structure of your extracted data changes over time.

Putting everything together, here is a one-liner that demonstrates how all of these individual steps come together. This example fetches the article, strips the HTML, applies the template, sends it to the remote LLM, and finally imports the returned structured data into your SQLite database using the logged result:

curl "<ARTICLE_URL>" | \
  uvx strip-tags | \
  llm -t people > /dev/null && \
  llm logs -c --schema t:people --data-key items --data | \
  sqlite-utils insert data.db people --nl --unique name organization article_headline

This compact pipeline shows the entire workflow executed in one command: retrieve the full text, clean it, extract structured data using your template, read the result back from LLM CLI’s logs, and load it into your database with a unique constraint.

6. Play with the Database

After that, you can use Datasette to review the database in my web browser：

datasette "<PATH_TO_DATABASE>"

It will show you something like:

INFO:     Uvicorn running on http://127.0.0.1:8001 (Press CTRL+C to quit)

Then you can open the URL in a browser to interact with the database.

Now that we have a database, we can run some queries. For now, what I need is simple: filtering out VC people and assembling them into a table. So I wrote some scripts using the query to display that information quickly in my terminal. Later, I happened to learn about Nushell and really like the way it displays data. I’ve included two screenshots for reference: one shows the data extracted from the Zed fundraising news as rendered in Nushell, and the other shows part of the list of VC people in the database.

In an ideal circumstance, I would export the data into separate tables such as founders, venture capitalists, startups, and VC firms. I could take it a step further by asking an LLM to return another JSON array describing the funding activities, including the amount of money, the valuation if mentioned in the article, the round type, and so on. For now, I am keeping everything in a single table because the data is still fairly simple.

Just as some readers may think when they read this series of commands, I found it a bit cumbersome to type them all manually. Therefore, I asked ChatGPT to write some scripts to automate everything, and then I made the scripts into zsh aliases. Now my whole workflow is:

1. Read the article
2. Send it to Readwise Reader with a tag using a web browser extension or a single Alfred command
3. Open Ghostty’s quick terminal and input the alias. Done

I think I can even make this shorter by combining steps 2 and 3 via a self-made Alfred Workflow.

Some Remaining Issues and Future Potential

And considering the other well-known characteristics of LLMs: they can’t produce deterministic results, which means we can’t expect the LLM to generate precisely the same role title in the same writing style for the same person or organization. For instance, some articles refer to the firm as “a16z,” while others use its full name, “Andreessen Horowitz.” Similarly, even for the same role, such as “CEO,” an LLM might output ”ceo” in lowercase or spell it out as “chief executive officer,” not to mention the inconsistency in capitalization. An LLM just can not retain the memory in the way I use the API. (There are many traditional solutions for these kinds of issues, though.)

Recently, I’ve been playing with Sourcegraph’s coding agent Amp Code. It’s a very good product, the pace of the team’s product development is incredible. I used its smart mode to normalize my flat table, then kept building on it using its free mode. I already completed the database migration and started to build a new version of my workflow. For instance, I can now get information like “Who is involved in Zed Industries’s latest round of fundraising?” more efficiently.

Or even better, with this database, I can use LLM CLI’s plugin like llm-tools-sqlite to ask an LLM questions about the data in natural language, and the model will generate the necessary SQL queries to retrieve the answer. I can also connect this database to Claude Desktop using an MCP server, which allows me query it in natural language directly from the app.

A Byproduct of Learning

I’ve spent more and more time in the terminal and shell environment after I started playing with Raspberry Pi a few years ago. By building up this workflow, I got familiar with LLM CLI and a bunch of other new tools. I’ve learned that shell scripts and Python scripts are nimble and versatile. With the help of ChatGPT and coding agents like Claude Code or Amp Code, I can quickly experiment with many ideas to improve the workflow. In the end, this AI news clipping workflow is more like a byproduct of my learning to use the software. It is really fun.

Again, I don’t use this workflow to process as many articles as possible. I use it as a reference to what I’ve already read. It’s more like a pitcher’s pitch-by-pitch tracking data: it doesn’t capture the whole game, and it certainly doesn’t replace the conversation between the pitcher and the pitching coach. The core is still the same: reading the news, taking notes, and writing down my own thoughts.

As I mentioned earlier, it’s possible to apply this workflow to many other kinds of news, like professional sports player trades, business, or politics, once you can break down the news content into structured elements, such as people, organizations, events, and so on. If you have tried it, I’m happy to learn how things are going.

In July, I came across a thread on Mastodon about a new app called Macrowave. It is “a native macOS & iOS app that makes it easy and fun to share system audio with friends to listen to music together,” as the co-creator, Lucas Fischer, said in this toot. A few days ago, Macrowave officially launched.

What caught my eye at first was, of course, the retro-style visual design. It resembles a portable radio and reminds me of the Apple Podcasts app from 2012. I don’t know the two developers behind Macrowave personally, but I bet they had fun designing it.

But the real deal for me is the ability to easily share my Mac’s system audio, which means I can run my own station. I’ve always been into audio broadcasting: not only have I been a long-time radio and podcast listener, but I also produced and hosted several podcasts.

Three Steps to Start Your Station

Macrowave streams audio via low-latency WebRTC peer-to-peer connections.¹ Its Mac app has two modes: the “Broadcaster” is lets you stream audio, and the “Receiver” is for listening to stations.

If you want to make a live audio broadcast, you just need three steps:

1. Sign up using Apple Account
2. Set up a username
3. Give your station a name and a short description

After that, you can share the link to your station with others to let them tune in. If your audience has enabled notifications, they will be notified when your station is on air. People can listen to the station through Macrowave’s Mac and iOS apps, or via a webpage.

You can choose what audio to stream—whether it’s the system audio (everything you normally hear from your Mac), audio from a specific app, or even from a single window. (Important: you must use this app wisely, as Macrowave states at the bottom of its website, “broadcasters are responsible for obtaining appropriate licenses for any copyrighted content they stream.”)

In an update released shortly after launch, Macrowave revealed its subscription pricing for broadcasting: $3 per week (with a three-day free trial), $8 per month, and $60 per year.

I’ve been using Rogue Amoeba’s Audio Hijack for years. One of its features, the Broadcast block, can stream audio from your Mac to an internet streaming server powered by Shoutcast or Icecast,² allowing you to run a live broadcast. While powerful, it requires more setup and technical know-how. Macrowave, on the other hand, makes the process far simpler and more approachable for casual broadcasters.

My Experience

From my brief experience using the app, I found that it doesn’t work well with my Audient iD4 audio interface. The mic input works fine, but for some reason, I couldn’t get the music playback to work in conjunction with it. However, if you use the Mac’s built-in mic (or something like EarPods connected via the audio jack), it works well.

As mentioned earlier, people can listen to your station via a link. In the first version, changing your username didn’t automatically update the link, but yesterday’s update (version 1.0.2) fixed this. If you encounter this issue, make sure you’re running the latest version.

Since broadcasting your Mac’s system audio requires specific permissions, you might wonder why it asks for “Screen & System Audio Recording” instead of just “System Audio Recording.” According to Lucas Fischer, this is due to a technical limitation of their upstream provider, despite the app only using audio from the screen sharing. They are working on it and plan to release a new version that requests only the “System Audio Recording” permission, but they must wait for the necessary changes from their provider.³

Thoughts and Questions

Macrowave has been officially available for less than a week, yet I already have many questions about where it’s headed. Will it become a two-way audio platform like Clubhouse or X Spaces, or stay as a simple broadcasting app? Will it introduce a text-based chatroom alongside each station? How does the app help users discover new stations? While I don’t think Macrowave is necessarily destined to be a major hit, there’s certainly room for a niche product like it.

Some aspects of the interface and visual design could be improved. For instance, the app lacks safeguards to prevent accidental quitting while broadcasting, and certain UI elements like button shadows don’t feel right to me. Still, Macrowave is genuinely a fun and intuitive app to use.