I Built Perplexity Computer. You Can't See It.

Perplexity shipped Perplexity Computer and my first thought was that they'd shipped my side project.

I opened the landing page. Left sidebar: Tasks, Files, Connectors, Skills, Use cases. I stared at it for about ten seconds before I realized I'd been building the same five things for the last six months, just without the labels on them.

Nanika has Missions. Perplexity has Tasks. Nanika has Workspaces. Perplexity has Files. Nanika has Plugins. Perplexity has Connectors. Nanika has Skills. Perplexity has Skills. Nanika has Personas. Perplexity has Use cases.

Same sidebar. Different product. The difference is that one of them you can see.

Their sidebar is my feature list

Before I get to the part where I explain why I'm not racing to build a new interface, I have to do the honest comparison. I ran a research mission through my own orchestrator to audit both products sidebar-by-sidebar against what I already shipped in nanika. It produced a 42KB gap analysis grounded in a direct-read audit of the nanika repo and a dossier of Perplexity Computer pulled from their blog, Reddit threads, and hands-on YouTube demos.

The core of what Perplexity Computer does is this: decompose a task, spawn parallel sub-agents across Firecracker microVMs, let them share a filesystem, resume asynchronously, route across nineteen different models, and deliver an artifact. Tasks, Files, and Skills are the shapes. Connectors are the integrations. Use cases are the starting points.

Here's what nanika does: decompose a task via pre-decomposed PHASE lines or an LLM decomposer with routing-memory hints, spawn parallel workers across git worktrees with trust-boundary sanitization, share a scratchpad protocol between phases, resume from checkpoint, run a gate on every output, run a review loop that fails closed on malformed reviews, and deliver an artifact.

Sidebar for sidebar:

• Tasks ↔ Missions. Both decompose, both parallelize, both do artifact-oriented output. Nanika has a CheckGate that refuses empty or too-small outputs and an expectedPaths glob check. It also has a review loop that fails closed when reviews come back malformed — a phase can't sneak through on a broken gate. Perplexity has no documented equivalent.
• Files ↔ Workspaces. Both are per-task shared filesystems. Nanika's are directories under ~/.alluka/workspaces/<id>/ that I can cd into, grep, and rerun. Perplexity's are inside the web app.
• Connectors ↔ Plugins. Perplexity has 20–25 named connectors (the "400+" number is marketing). Nanika has 20 plugin directories. The direct overlap is Gmail, LinkedIn, YouTube, Reddit, Substack, Discord, Telegram, Obsidian, and GitHub via git operations — eight or nine major connectors, most of which hands-on reviewers say are the only ones that work reliably on Perplexity.
• Skills ↔ Skills. Perplexity ships four built-in skills: Slides, Research, Research Report, Chart. Nanika has about forty entries in the worker-visible index — twenty-two files under .claude/skills/ plus twenty plugin-provided skill docs. Roughly ten times the catalog depth. I'm missing the three output skills Perplexity ships, which is a concrete gap I'll come back to.
• Use cases ↔ Personas. This is where the comparison stops being flattering. Perplexity's Use cases are eight primer chips the user can click. Nanika's Personas are ten internal role definitions the decomposer uses to assign workers. These are not the same concept. Theirs answers "what can I ask for." Mine answers "who does the work."

On engine, I match or exceed them on almost every axis. On the user-facing surface, I don't have one.

Where mine is actually ahead

I want to be specific about the places where nanika is already the better product, because I'm going to spend the rest of the article talking about what I'm missing, and I don't want to undersell what I already have.

Debugging visibility. A hands-on review I read while auditing dinged Perplexity Computer specifically on "zero debugging visibility" — the biggest single deduction in the whole review. Power users report failed tasks still burn credits with no mid-task alert. Nanika's entire workspace is a directory tree. I can cd ~/.alluka/workspaces/<id>/workers/<phase>/, read the scratchpad, read the worker output, read the review, and rerun the phase with one command.

Cost transparency. Perplexity's real-world pricing is $200 a month sticker for Max, with power users reporting spend between $500 and $2,200 a month once the credit burn kicks in. Failed tasks still billed. Nanika bills my Anthropic API directly, has a quota gate that skips phases which would exhaust quota, and writes every mission's cost to a local metrics.db I can query.

Fail-closed review logic. This one matters more than it sounds. I had a bug where a review would come back as malformed JSON and the orchestrator would treat it as a pass. I fixed it two weeks ago by making the review loop fail closed — if the review can't be parsed after retries, the phase fails and I decide. Perplexity has no visible gate or review step at all, so there's nothing to fail closed on.

Self-improvement loop. Nanika has a subsystem called nen. Yes, the whole project is a Hunter x Hunter reference. It runs observers that watch what's happening in the repo, a proposer called shu that writes improvement tickets into a local tracker, and a daemon that can dispatch approved improvements through a scheduler. Nothing like that exists in Perplexity as far as any public source shows.

Local-first by construction. Every file is on my SSD. Every memory is in plain markdown or a local SQLite. Every plugin is a Go or Rust CLI I own. If Perplexity turns off tomorrow, their users lose their files. If nanika breaks tomorrow, I git checkout the last good commit and keep going.

Those are real advantages. None of them are visible from a screenshot.

The one thing they have that I don't

So where's the gap?

It's in the last row of the mapping. Use cases vs Personas. That was the row I flagged as "the comparison stops being flattering." Here's why.

Perplexity's Use cases are a gallery of click-to-run primer chips. "Navigate my taxes." "Monitor the situation." "Help me learn." "Create a prototype." "Lead generation." "Recruiting." "Organize my life." "Build a business." Eight chips. You click one and it pre-populates the input box with a concrete starter prompt like "Prepare my 2025 taxes for my review."

A new user sitting in front of Perplexity Computer sees eight chips they can click.

A new user sitting in front of nanika sees a blank terminal.

I built ten worker personas with rich capability contracts and methodology blocks. I built forty skills that include language-level references for Go error handling, Postgres performance, and Vercel React patterns. I built twenty plugins with a uniform query protocol. But the thing I did not build is the one sentence that tells the user what they can ask for.

A YouTube reviewer I watched while auditing Perplexity said this, and I keep coming back to it: "I love building all these tools. It's fun to play with. And that's the thing. I'm just playing. I'm not actually using the tools for what I want them to do. I'm just sharpening my axe. Whereas with Perplexity Computer, there was no axe to sharpen. It just was already there. And frankly, I don't need more tools. I realized that I need a box."

That's the gap. Nanika ships the engine of the box without the walls the user sees. The axe is sharp. The user is holding it by the blade.

Why I'm not building a new interface anyway

The obvious move from here is to scope a CLI TUI in Bubble Tea and spend four to six weeks building a primer gallery, a live missions pane, an artifact browser, and a + New task composer. The gap analysis I ran explicitly recommends this as "highest leverage per dollar" — closes four of the five UX gaps, zero habit friction, in-repo Go code, no platform churn.

I'm not doing it.

Here's why.

A TUI is a four-week commitment to an idea I have not yet proved is valuable. The assumption underneath the TUI is that a primer gallery will change how I start sessions. Maybe it will. Maybe I'll still ignore the gallery and type orchestrator run "whatever I was going to type anyway". I don't know, and I can find out cheaply before I commit.

I've made this mistake before. A few weeks ago I looked at whether to build a plugin for a different problem and the audit came back saying "probably, eventually — but first go prove the habit manually for a month." I deferred the plugin and told myself I'd take notes by hand for a month. The habit never stuck. The plugin would have been four weeks of sharpening the axe on a problem I didn't actually have.

The principle I keep running into is this: build the label before the box. The label is a sheet of markdown. The box is four weeks of Bubble Tea code and an ongoing maintenance commitment. The label costs nothing. If the label works, the box writes itself from real usage. If the label doesn't work, the box was going to be a tax on a problem that didn't exist.

What I'm shipping instead

The minimum viable version of a primer gallery for nanika is five markdown files. That's it.

.claude/skills/primers/
├── content-publishing.md    # engage + article + substack
├── research-intelligence.md # scout + orchestrator research missions
├── financial-tracking.md    # ynab + gmail
├── inbox-and-comms.md       # gmail + linkedin + discord + telegram
└── dev-automation.md        # orchestrator + tracker + scheduler

Each file has a category name, three or four example prompts, the plugins it touches, and the entry command. No TUI. No Bubble Tea. No new binary. Just markdown.

Then I'm wiring the primers into my existing orchestrator hooks preflight command, which is the thing that runs at the start of every Claude Code session and injects an operational brief into context. The brief already has scheduler status, tracker tickets, learnings, and nen health. I'm adding a "Starting points" section that rotates a few primer categories by day of the week. Five more lines in the rendered brief. Zero new code in the binary surface.

Finally I'm adding a /primers slash command that lists all the primer files inline when I'm in a Claude Code session. That's one more SKILL.md under .claude/skills/primers/. Not a new surface. A user-invocable skill that prints markdown.

Total build cost: an afternoon. Maybe two if I write the primers well.

I'm running this for four weeks.

What I'll know in four weeks

I won't know if I was right or wrong about interfaces. I'll know whether the primer gallery changed what I actually asked for.

If I find myself starting missions from primer prompts instead of blank terminal commands, the idea is validated and the CLI TUI becomes the obvious next step — except now the scope writes itself from real usage, not from a gap analysis. I'll know which primers I actually used. I'll know which plugin combinations I never reached for. I'll know whether live progress visualization matters or whether a rotating brief is enough.

If I find myself ignoring the primers and typing the same commands I always typed, the primer concept was wrong and a TUI would have been a four-week tax. I'll have an afternoon's worth of markdown to delete instead of four weeks of Bubble Tea to maintain.

Either outcome is fine. The expensive version of being wrong is building the TUI first and finding out afterward. The cheap version of being wrong is writing five markdown files and learning something.

Solo builders build engines. Products build labels.

The broader thing I keep noticing is that solo builders like me build engines first because we can. We enjoy it. The gate logic, the review loop, the memory pipeline, the trust boundary, the routing memory — those are fun problems. They have crisp right answers. They compile or they don't. You can unit test them.

Labels are not like that. A label is a sentence that convinces a user they can ask for something. It has no right answer. It has no test. You ship it and see if someone clicks. Most of the labels you write will be wrong and you'll rewrite them six times before one lands.

Perplexity built the labels first because their business requires it. A venture-backed product has to be legible from a screenshot. The user has to see what the thing does in five seconds or the user leaves. The engine can be a leaky mess as long as the sidebar reads well.

Nanika built the engine first because my constraints are the opposite. I'm the only user. I'm the only support. I'm the only person reviewing the code. I don't need the sidebar to read well in five seconds — I need the worktree to not break, the review loop to fail closed, the memory pipeline to not poison itself. The label can come last because there's only one reader and I already know what it does.

But that asymmetry is also the reason I didn't see the primer gap until Perplexity shipped their product and held up a mirror. I built the engine because the engine was interesting. I skipped the label because the label was obvious to me. The label is obvious to me because I wrote the code. It is not obvious to anyone else, including future-me sitting at a blank terminal on a Monday morning wondering where to start.

That's the whole lesson. I've been sharpening the axe for six months. Perplexity built the box in six weeks. And the thing between us is not a better engine. It is a label on a folder that says "Use cases."

I'm writing the labels this weekend. The box can wait.

Sources. All four are in the nanika mission workspace under ~/.alluka/missions/assets/eval-perplexity-computer/:

• DOSSIER.md — the full Perplexity Computer feature dossier with source citations from Perplexity's own blog, hands-on YouTube reviews, and Reddit commentary
• NANIKA-INVENTORY.md — a direct-read audit of the nanika repo as of 2026-04-11
• GAP-ANALYSIS.md — the sidebar-by-sidebar comparison and the interface-option evaluation
• RECOMMENDATION.md — the opinionated memo that led to the primer gallery decision

The tracker issue for the primer gallery work is trk-8F56 with three subtasks. The four-week validation starts the day I finish writing the primers.