The terminal is not the tool — the attention tax is
If you run social accounts for a living, you’ve already lived the problem Farol is trying to solve, even if you’ve never opened a terminal in your life. The maker, Lucas Neves Pereira, built it because he was juggling three or four Claude Code and Codex sessions at once and kept losing track of which one was stuck waiting on him. Swap “Claude Code session” for “scheduled post,” “client approval,” or “draft waiting on a legal review,” and the shape of the pain is identical. Every social media operator I know is running some version of this: five platforms, three clients, two contractors, one content calendar, and a brain that can only hold about four open loops before something falls out. The interesting thing about Farol isn’t that it’s a terminal. It’s that it treats attention routing as the product, and that’s a lesson the social tooling world has been slow to learn.
What Farol actually is, stripped of the framing
Farol is a native macOS terminal built specifically for running multiple AI coding agents in parallel. It’s free, MIT licensed, has no account and no telemetry, and requires Apple Silicon on macOS 14 or later. The core mechanic: each agent session gets a dot in the sidebar that shows one of three states — working, waiting for you, or done — and that same state surfaces in the menu bar or at the notch, so you can be in another app and still see when an agent needs your input. The maker describes it as the terminal he built to stop cycling through tabs looking for the one stuck on a permission prompt. The name is Portuguese for “lighthouse,” which is a nice bit of naming discipline — the whole product is about a signal you can see from far away.
A few other things it does, per the launch post: you can describe a new task or pick a GitHub issue or Jira ticket, and it opens a git worktree on a new branch and starts the agent with the task as its first prompt. There’s a review panel that shows everything a session changed since it left main as one diff, then lets you commit, push, and open the PR. And when a rebase or merge stops, there’s a three-column conflict resolver built in. Under the hood it uses libghostty, the engine behind Ghostty, so it renders like Ghostty and reads your Ghostty config. The app around it is native Swift. The maker is upfront that it’s early and to expect rough edges.
That’s the whole product. Now let me tell you why I think it matters, and where I think it doesn’t.
The real problem: parallel work breaks attention, not throughput
Here’s the thing most social media tooling gets wrong, and it’s the same thing most AI coding tooling gets wrong. When you give a person more parallel capacity, you don’t get proportionally more output. You get a new class of failure: the dropped thread. The agent finishes, the session goes idle, and nobody notices for forty minutes because you were heads-down in a different window. In social media terms, this is the post that was supposed to go out at 9am that’s still sitting in draft at 11am because the approval notification got buried under three Slack pings and a TikTok comment thread.
The incumbents in the social scheduling space — Buffer, Hootsuite, Later, Metricool — have all converged on the same UI metaphor: a calendar grid, a queue, a list of scheduled items with status chips. That metaphor is fine for planning. It is genuinely bad for monitoring. A calendar tells you what’s supposed to happen. It does not tell you what’s currently stuck. When I scheduled thirty posts across five platforms last month, the failure mode wasn’t “I forgot to schedule it.” It was “the platform rejected the asset at publish time and the notification went to an email I don’t read.” That’s the same failure Farol is solving for agents: the work is done, the handoff is blocked, and the human doesn’t know.
Farol’s answer is a persistent ambient indicator — the dot, the menu bar, the notch. That’s a design pattern social tools should steal wholesale. Not the terminal, not the Swift, not the git worktrees. The ambient status signal. If your scheduling tool surfaced a single always-visible indicator of “items currently blocked and waiting on you,” you would catch a meaningful fraction of the publish failures you currently catch by accident.
Why TikTok creators should care more than LinkedIn ones
This is a judgment call, not a sourced fact, but I’d bet the ambient-status pattern matters far more on high-frequency, high-volatility platforms than on low-frequency ones. A LinkedIn post that goes out four hours late is usually fine. A TikTok that misses its window in a trending sound cycle is dead on arrival. If you’re posting three to five times a day on TikTok and Instagram Reels, the cost of a dropped thread is much higher than if you’re posting twice a week on LinkedIn. The more parallel sessions you’re running — multiple clients, multiple platforms, multiple formats — the more you need a lighthouse, not a calendar.
What the review panel teaches about content repurposing
The feature I keep coming back to is the review panel: everything a session changed since it left main, shown as one diff. That’s a genuinely good mental model for content repurposing, and I don’t think the maker intended it that way.
Here’s the analogy. When you repurpose a long-form YouTube video into a TikTok, a LinkedIn carousel, an X thread, and a Pinterest pin, you’re not creating four independent pieces of content. You’re creating four deltas from a source asset. Most repurposing workflows treat each output as a fresh creation, which is why they drift — the TikTok says one thing, the carousel says another, and nobody can tell you which one is canonical. A diff-based view forces the question: what changed from the source, and why?
I’ve started doing this manually in my own workflow, and it’s changed how I brief repurposing. Instead of “make me a TikTok from this video,” I write “here’s the source, here are the three claims that must survive, here’s what you’re allowed to cut.” That’s a diff spec. It’s not glamorous, but it catches the failure mode where a repurposed asset quietly contradicts the original. CapCut and Canva make the production of repurposed assets trivially easy. They do nothing to keep the semantics aligned. That gap is where I’d expect the next wave of repurposing tools to compete.
Where the math breaks
I want to be honest about a limitation here, because the maker was honest about one himself. In the Product Hunt comments, Gal Dayan — who builds a competing product called Dial — raised a sharp point: separate worktrees solve the file-conflict half of running agents in parallel, but not the half where two tasks touch the same API contract or shared schema from different worktrees, and neither agent can see the other’s change until someone opens both diffs side by side at merge time. He asked whether Farol flags overlapping files or symbols before you’re staring at a nasty rebase.
The maker’s answer was refreshingly direct: Farol doesn’t flag overlap between tasks yet, so today that’s still on the human. What does help is that the review panel shows everything a session changed since it left main, so comparing two tasks is two clicks instead of two PRs side by side. The roadmap item is letting agents see each other’s sessions so one can check what another is changing before it touches a shared schema.
Dayan pushed back again, and this is the part I’d frame on my wall: a file-level warning would catch most of it — cheap check, probably 80% of real cases — but the harder version is two agents editing different files that both call the same function signature, where there’s no file overlap at all but the contract still breaks. “Same file” and “same symbol” are different bars, and the second one is where the actually nasty bugs hide.
That exchange is the most useful thing on the page, and it maps directly onto social media operations. “Same file” is two posts scheduled for the same slot. Easy to catch with a calendar. “Same symbol” is two posts making contradictory claims about your product’s pricing, published a week apart, on different platforms, by different people. No scheduling tool catches that. No content calendar catches that. It’s a semantic conflict, and the only reason it doesn’t blow up more often is that most brands aren’t publishing enough for the contradiction to surface. The ones that are — the ones running real multi-platform operations — know exactly what I’m talking about.
What creators and social teams can borrow from Farol
Three patterns, in order of how quickly you could implement them this week.
One: ambient status over inbox status. The dot in the sidebar is the whole product. If you’re running a content operation, pick one surface — a shared doc, a Slack channel, a Notion dashboard, a literal physical whiteboard — and make it show only the items currently blocked on a human. Not everything in flight. Just the blocked ones. The reason most dashboards fail is that they show everything, which means they show nothing. Farol’s sidebar works because at a glance you can tell which of four sessions needs you and which three don’t.
Two: diff-based briefs for repurposing. Stop briefing repurposed assets as standalone creations. Brief them as deltas from a canonical source. What must survive, what can be cut, what must not be added. This is a small writing discipline with an outsized effect on brand consistency across platforms.
Three: task-to-branch thinking. Farol’s “new task” flow — describe it or pick a ticket, it opens a worktree on a new branch, it starts the agent with the task as its first prompt — is a workflow that maps cleanly onto content production. Every content request should start from a clean context with the request as the first input, not from “hey can you also make a version of that thing we did last month.” The reason content operations get messy is that requests arrive as fragments attached to other requests. A clean-room start per task is a discipline, and tools that enforce it are worth studying.
The platform-algorithm angle nobody’s talking about
I’d be remiss not to connect this to the broader algorithm story. Every major platform has spent the last two years pushing distribution toward consistency and volume — more posts, more often, more formats. That’s the same pressure that pushes creators toward running more parallel sessions. The tooling response has been to make production faster: CapCut templates, Canva bulk resize, AI caption generators, AI video editors. Almost nobody has built the attention routing layer that makes running five parallel production streams actually survivable. Farol is a terminal for coding agents, but the design insight — ambient status, diff review, clean task starts — is the missing layer in social tooling. I’d bet the next serious scheduling tool to gain traction will be the one that stops competing on calendar features and starts competing on “how fast can you tell me what’s blocked.”
Where my judgment says it falls short
Let me be specific about the limitations, because the maker was specific about his and I should return the favor.
First, the obvious one: Farol is macOS-only, Apple Silicon-only, macOS 14 or later. If you’re on Windows or Linux or an Intel Mac, this is not for you, full stop. The maker says so directly.
Second, it’s a terminal for coding agents. It is not a social media tool, and it will never be one. The reason I’m writing about it here is that the design patterns transfer, not the product. If you read this and think “great, I’ll use Farol to manage my social calendar,” you’ve missed the point entirely. It manages Claude Code and Codex sessions. That’s it.
Third, the overlap-detection gap is real and the maker admits it. If you’re running agents that touch shared schemas or shared contracts, Farol won’t catch the conflict before you’re in the rebase. The roadmap item — agents seeing each other’s sessions — is the right fix, but it’s a roadmap item, not a shipped feature. If your workflow depends on that, wait.
Fourth, it’s early. The maker says “expect rough edges” and uses it as his daily terminal anyway. That’s an honest signal. Free, MIT licensed, no telemetry, no account — those are all trust positives, but they also mean there’s no support contract, no SLA, no company behind it in the traditional sense. Not disclosed whether there’s a monetization plan. For a personal terminal, that’s fine. For a team dependency, that’s a question you’d want answered before standardizing on it.
And fifth, the thing I keep circling: this is a tool for people who already run multiple AI agents. If you run one Claude Code session a day, you don’t have the problem Farol solves. The product is a lighthouse for a specific kind of operator — someone running three or four parallel sessions who’s tired of tab-cycling. That’s a real and growing audience, but it’s not everyone, and the launch post doesn’t pretend otherwise.
What I’d watch / test next
Three things I’d actually do this week if I were running a content operation, plus one thing I’d watch from the sidelines.
Test the ambient-status pattern on your own stack. Pick your single biggest source of dropped threads — probably scheduled posts that fail at publish time — and build one always-visible surface that shows only the blocked items. A pinned Slack message, a Notion widget, a phone widget, whatever. The point isn’t the tool. The point is finding out whether ambient visibility actually reduces your dropped-thread rate, or whether you just ignore the indicator the way you ignore most notifications. My guess is it depends entirely on whether the indicator shows only blocked items. A dashboard that shows everything is noise. A dashboard that shows one number — items currently waiting on you — is a lighthouse.
Rewrite one repurposing brief as a diff. Take a source asset you’re about to repurpose into three formats, and instead of briefing each output, write one brief that specifies what must survive, what can be cut, and what must not be added. See if the outputs come back more consistent. This costs you twenty minutes and might change how you brief everything.
Watch the Farol roadmap for the cross-session awareness feature. The maker said the next step is letting agents see each other’s sessions so one can check what another is changing before it touches a shared schema. If that ships and works, it’s a meaningful step toward the semantic-conflict problem Dayan described. If it doesn’t ship, the file-level warning is the cheap 80% fix and probably worth doing anyway.
And the thing I’d watch from the sidelines: whether any social scheduling incumbent steals the ambient-status pattern. Buffer, Hootsuite, Later, and Metricool have all been competing on calendar features, analytics depth, and AI caption generation for years. None of them, as far as I can tell, has made “what’s currently blocked and waiting on you” a first-class, always-visible surface. That’s a gap. The first tool to close it — properly, with a single number and a single click to resolve — will win a meaningful chunk of the operator market. I’d bet on it. But I’ve been wrong before, and the incumbents have distribution advantages that a clever UI pattern doesn’t overcome on its own.
