The Agentic Stack Is Now a Hardware Problem — and Cross-Border Ops Teams Are Paying for It
Every operator I know who runs an AI-heavy back office has quietly become an amateur thermal engineer. The moment you wire Claude Code or Codex into your listing-optimization workflow, your PPC bid-tuning loops, your supplier-email triage, or your returns-disposition logic, the MacBook that used to sit quietly on the desk starts sounding like a leaf blower. Activity Monitor is useless here: it shows you forty node and compiler processes and exactly zero degrees. That is the gap WhoIsCooking is trying to close, and while it is nominally a developer tool, the underlying lesson — you cannot optimize an agent fleet you cannot attribute — is one every cross-border seller running automation is about to learn the hard way.
Why this matters to a seller, not just a coder
Here is the uncomfortable truth about the 2025–2026 tooling stack: the same agentic workflows that let a three-person DTC team punch like a fifteen-person one also concentrate compute risk onto a single laptop or a single cheap VPS. When your Shopify catalog sync, your Amazon Seller Central repricing jobs, and your Klaviyo flow QA all run through LLM agents on the same machine, a thermal throttle during a flash sale is not a developer inconvenience — it is a missed reprice window and a margin leak. WhoIsCooking’s premise, that per-agent attribution is the missing primitive, is the right frame. The product itself is small; the mental model is not.
What WhoIsCooking Actually Solves
The maker, Andrew Wilson, describes the origin problem plainly: he runs Claude Code and Codex on a MacBook, it kept getting hot, and there was no way to tell which agent was responsible. Activity Monitor, in his words, shows dozens of node and compiler processes and no temperature at all. WhoIsCooking puts chip temperature in the notch or menu bar, groups each agent session with everything it spawned into a single row, and offers a “Cool down my Mac” button that migrates busy work to efficiency cores — crucially, without killing or freezing anything.
That last design choice is the one I want cross-border operators to internalize. The maker reports that on his M5, four processes running flat out dropped from roughly 83°C at full speed to about 48°C cooled, with the work simply running a bit slower. He is upfront about the limits: it cannot cool GPU work or Apple’s own processes, and it requires Apple Silicon (M1 to M5) on macOS 14 or later. Pricing is a one-time $5, signed and notarized, no account.
The attribution primitive is the real product
Commenter JC, builder of Haplo AI, nailed why this lands: grouping everything under one row per agent is what makes it usable, because Activity Monitor tells you the Mac is hot but never answers which agent session is responsible or which builds, tests, and dev servers belong together. That is an observability argument, and it is exactly the argument I would make about your fulfillment and ad-automation stack. If you cannot attribute cost and load to a specific automation, you cannot govern it.
How It Differs From the Incumbents You Already Run
The obvious comparison is Activity Monitor itself, and the maker’s critique is fair: process-level granularity without thermal context. The second comparison is the broader Mac monitoring category — iStat Menus and Stats both give you temperature and per-process CPU, and both are excellent. What neither does is the session-grouping: they show you processes, not agents and their children. A third comparison is the cloud route — if you are running agents on AWS or Google Cloud, you already have per-instance metrics and autoscaling, and this tool is irrelevant to you. WhoIsCooking is specifically for the local-first operator who has not yet moved agent workloads off the laptop.
Why Amazon sellers should care more than Shopify ones
Shopify-first DTC brands tend to run their automation in cloud functions or a managed app layer — Shopify Flow and third-party apps absorb the compute, and the laptop stays cool. Amazon FBA operators are the opposite: repricing, listing QA, and review-response drafting are frequently run as local scripts or agent loops because the Seller Central API surface is fiddly and teams hack together their own tooling. If your repricer is a Python agent on a MacBook, thermal throttling is a revenue event, not a comfort issue. That is the seller segment where a $5 menu-bar utility earns its keep.
What Cross-Border Operators Should Borrow From This
Three transferable ideas, in descending order of usefulness.
First, per-agent cost attribution. The single-row-per-session model is the right abstraction for your automation budget. If you are paying for OpenAI or Anthropic API tokens across a dozen workflows, you should be able to see, per agent, what it spawned and what it cost. Most teams cannot, and they discover the runaway loop only when the invoice arrives.
Second, graceful degradation over hard kills. The “move to efficiency cores, don’t kill” philosophy maps directly onto how you should configure your ad-spend guardrails. When a bid-management agent misbehaves during peak, you want it throttled and flagged, not terminated mid-write. Commenter Keesan’s suggestion — a thermal timeline per session marking what was running (build, tests, dev server, verifier) when the spike hit — is the same pattern you want in your automation logs: timestamped context so you can distinguish a healthy long compile from a runaway loop.
Third, honest scope disclosure. The maker states his limits up front: no GPU cooling, no Apple processes, Apple Silicon only. That is how you should write your own internal tooling docs and your SOPs for third-party automation vendors. The $5 one-time, no-account model also deserves a nod — for a utility this narrow, subscription pricing would be absurd, and operators should push back harder on seat-based pricing for tools they use intermittently.
Where the math breaks
The 83°C-to-48°C figure is a single anecdote on a single M5 with four processes. It is not a benchmark, and the maker does not claim otherwise. More importantly, the tool does nothing for the operator whose agents run on a $6/month VPS — which is most of the serious ones. And “runs a bit slower” is fine for a compile, less fine for a time-sensitive repricing job during a Lightning Deal. If you are doing latency-sensitive automation, cooling is the wrong lever; moving the workload off the laptop is the right one.
Where My Judgment Says It Falls Short
I like the product’s thesis and I am skeptical of its addressable audience. The overlap between “runs Claude Code and Codex locally on Apple Silicon” and “runs a cross-border e-commerce operation” is real but narrow, and it is shrinking as teams migrate agent workloads to managed runners. The tool also stops at the machine boundary: it tells you which agent is hot, not which agent is worth the compute. For an operator, the more valuable dashboard is cost-per-outcome — dollars of API spend per recovered cart, per reprice, per resolved return — and nothing in this launch addresses that.
The missing temperature history that commenter Ida Hansen asked about is a genuine gap, not a nice-to-have. Without a timeline, “cool down” is a reaction, not a decision — Keesan made exactly this point. The maker explicitly invited feedback on what else it should show per agent, which suggests history is on the roadmap but not shipped. And the Apple-Silicon-only, macOS-14-plus constraint quietly excludes the Windows-heavy ops teams that dominate 3PL and warehouse-side workflows.
What I’d Watch / Test Next
This week, do three things. One: audit where your agent workloads actually run. If more than a handful of revenue-touching automations execute on a laptop, that is your real risk register, and a $5 thermal utility is a bandage, not a fix — start pricing a move to a managed runner. Two: instrument per-agent cost. Even a spreadsheet that logs tokens and dollars per workflow will teach you more than any menu-bar widget, and it is the prerequisite for the attribution model WhoIsCooking is selling. Three: if you do run local agents on Apple Silicon, buy the tool and use it as a forcing function — watch which session spikes during your peak hours, then ask whether that job should be running on your machine at all. The product is cheap; the discipline it implies is the actual purchase.
