Pine vs Town, and the widest gap on this bench

Pine vs Town is the most useful pair to put side by side, because they sit at opposite ends of the one property you cannot change after you choose: where the agent runs. Pine executes nothing of substance on your computer. Town ships a native Mac application that reaches your messages, your contacts, your screen and your audio. Everything else about them, the price, the tool count, the surface you type into, follows from that and can be argued about. This one cannot.

• One of them never touches your machine in a way that matters. The other has a real foothold on it. That is the whole comparison.
• Both route the actual thinking through a server, so neither is private in the sense people usually mean.
• Their tool surfaces differ by a factor of forty, and the larger one is deliberately hidden from its own assistant.
• Both let something other than you start the work, which is where the foothold question stops being theoretical.

The two runtimes, side by side

Where each one actually runs

Pine runs server-side. Neither the web app nor the Mac app runs the model. When browser work is needed it is handed to a separate agent on your own machine, and the cloud alternative leases you a remote desktop that you watch over VNC. Two execution places for two kinds of work, inside one product.

Town also handles sync and session work on a server, but its Mac application is native and genuinely reaches into the system. Messages, contacts, screen and audio are within range.

Read those two paragraphs again and notice what they are not saying. Neither product runs its model on your laptop. The difference is not local versus cloud intelligence. It is how much of your machine the cloud intelligence can reach, and there the gap is as wide as it gets on this bench.

That is why the axis matters rather than being an architecture trivia question.

An agent working in a leased remote desktop can do the wrong thing inside a box that is thrown away afterwards. The damage is bounded by what was in the box. An agent with a native foothold doing the wrong thing is doing it to your actual messages and your actual contacts, in a place where the result stays after the task ends.

Town's reach buys something real. An agent that can see your screen and read your messages has context no API hands over, and that is the whole argument for building it that way. The cost is that the blast radius of a bad decision is your computer rather than a container.

Forty times the tools, most of them hidden

Pine exposes 26 tool names to the client, grouped by job, and never ships their schemas. Computer use bypasses that list completely, which means the published count does not describe what the product can actually do.

Town catalogues 1105 tools and narrows them in four stages before anything is offered. Its main assistant is shown 177. One background writer is allowed 17.

The headline is the ratio, but the interesting part is that both products hide most of their surface, by opposite methods. Pine withholds the schemas, so you can see the names and not the shapes. Town withholds the tools themselves, showing its own assistant a sixth of the catalogue. In both cases the number a comparison article would print, 26 against 1105, is the least informative number available.

Memory you can open, and memory you cannot

Town keeps a wiki, a memory store and a people model on the server, and its personality is a document you can open and edit rather than a line buried in a prompt. That last part is rare. Most products treat the agent's disposition as vendor configuration.

Pine gives you no file to edit. There is a server-side persona and a structured fact layer queried on demand.

The practical difference is correction. When Town has the wrong idea about you, there is a surface where that idea lives and you can go and change it. When Pine has the wrong idea about you, the fact layer is queried on demand and you are asking the product to forget something rather than editing a document.

Four front doors against two

Pine answers to four request shapes under one brand: web, Mac, outbound phone calls, a voice copilot, and a REST endpoint that other people's agents can call. That last one deserves a second look, because it means Pine is a component other software can drive, not only a product a person uses.

Town gives web and Mac equal weight, and routines can be started by a clock, an email or a calendar entry rather than by you typing.

Both therefore run without you present, which is the point at which the foothold question stops being theoretical. Town's clock can wake an agent that reaches your messages. That is the combination to think about, rather than either half alone.

What neither of them will confirm

Both pages on this site carry a section for what we could not establish, and the two lists are instructive.

For Pine we could not get the production instruction text, after roughly 126 probes that all came back empty, nor the calling tool's schema, nor which carrier places the calls, nor whether work is split across a fast and a slow model. For Town we could not get the full instruction set, because the member-facing interface refuses it, nor where the personality document is spliced in, nor the execution bodies of four newer routines.

The shape of the two gaps is similar and it is not an accident. In both cases the thing we could not reach is the instruction text, which is the part that decides behaviour. Everything else about an agent is observable from outside with enough patience. The prompt is the part the product protects, and a comparison that does not say so is pretending to more certainty than anyone has.

One of them makes phone calls, which is its own category

Pine phones companies on your behalf about bills, refunds and cancellations. Town does not do this, and almost nothing else on this bench does either.

It is worth separating from the rest of the comparison because it is the only capability here that reaches outside software entirely. Every other difference between these two products is about which machine runs code and what that code can see. A phone call puts an agent into a conversation with a person who did not agree to talk to a machine, on a recorded line, about your account.

That changes the failure mode again. A tool call that goes wrong leaves a log. A call that goes wrong leaves a human on the other end with an impression of what you authorised, and the only record is whatever the carrier kept. We could not establish which carrier places the calls, which is one of the gaps listed below, and for a capability of this kind that gap is larger than it sounds.

It also explains the four front doors. A product that treats a phone call as a first-class action needs a way to be triggered by something other than a person at a keyboard, and the REST endpoint is the logical end of that thought.

Which one the choice actually comes down to

Strip out everything that both products claim and two questions remain.

The first is whether you want an agent that can see your computer. If the work you have in mind depends on context that lives on your screen and in your messages, Town's foothold is the feature and Pine cannot substitute for it. If it does not, the foothold is exposure you are carrying for nothing.

The second is whether the errands you care about end in a conversation with a company. Cancellations, refunds and billing disputes often do, and Pine is built around that. Town is built around operating your own machine well.

Those two questions are nearly independent, which is why the completion rates on our scorecard are a poor way to choose between them. A rate averages across a task set that mixes both kinds of work. The products are not competing on the same axis, whatever a single number implies, and the parts of each that we could not establish sit in the same place for both.

What the numbers do and do not say

Our scorecard carries a completion rate for both, with an interval and a task count, and the two are not close. It is still not a ranking, and this page is not an argument that one of them is better.

A completion rate measures whether an errand finished. It cannot tell the difference between an errand that finished inside a leased remote desktop and one that finished through a native application holding your messages open. Those are different products to live with, and the rate is blind to the distinction this entire page is about. Read the rate for what it measures and read where it runs for the rest.

FAQ

What is the main difference between Pine and Town? Where the work happens. Pine runs nothing of substance on your computer and leases a remote desktop when it needs a browser. Town's Mac application is native and reaches messages, contacts, screen and audio.

Does either of them run the model on my machine? No. Both think on a server. The difference is how much of your machine that server-side intelligence can reach, not where the intelligence lives.

Which has more tools? Town catalogues 1105 and shows its main assistant 177. Pine exposes 26 names and no schemas, and its computer use bypasses that list anyway. Neither count describes what the product can do.

Can I edit what either one remembers about me? Town's personality is a document you can open and edit, alongside a server-side wiki, memory store and people model. Pine gives you no file: a server-side persona and a fact layer queried on demand.

Can either one act while I am not there? Both. Town's routines can be started by a clock, an email or a calendar entry. Pine exposes a REST endpoint that other software can call, along with outbound phone calls.

Did you test these or read about them? We took both apart at the runtime level. Everything on this page is from those teardowns, Pine and Town, including the lists of what we could not establish.