DEV Community: Nathan

Getting Agentic Harnesses Out of the Terminal

Nathan — Tue, 25 Aug 2026 16:58:20 +0000

I love agentic coding harnesses, but they shouldn’t be primarily terminal-based. The terminal is great for quick and precise commands, but information density is extremely low and UI affordances are minimal. Maybe provision of TUIs is worthwhile for occasional use (when establishing a tunnel is too annoying, or something), but it feels very strange for this to be the default modality. It took a long time for dynamic language REPLs to break out of the terminal (Jupyter notebooks and similar); I hope we don’t have to wait as long for the harnesses.

— Patrick Collison, co-founder of Stripe

Collison isn’t alone in this. At some point you stop wanting an AI client that just talks and start wanting one that does real work: writes and runs code, installs a package, builds a project, produces a PDF. The default answer has been to reach for a terminal and an existing harness like Claude Code or OpenClaw. That works well if you’re already comfortable living in a shell. It gets a lot less comfortable if you’re used to a normal app with a UI, like ChatGPT, and have never typed npm install in your life.

More people are asking for the UI version of that terminal workflow: something that gives an AI real execution capability without requiring you to become a terminal user first. Here’s how we built that in Elvean.

The building block: a real VM, not a container in the usual sense
Apple publishes containerization, a Swift package built on top of the Virtualization framework. This matters more than it sounds like it should. A normal container (Docker on Linux, for instance) shares the host kernel and isolates processes with namespaces and cgroups: real isolation, but at the OS level. Apple’s containerization package instead boots each container as its own lightweight virtual machine on Apple Silicon, with the Virtualization framework doing the hardware-level separation. Boot times stay in the sub-second range, so it behaves like a container in practice, but the isolation boundary is a real VM, not a shared kernel.

That’s the difference between “the AI probably can’t touch my machine” and “the AI is running on hardware-isolated infrastructure that literally cannot touch my machine, short of a hypervisor-level exploit.”

What we built
Every Elvean Project gets its own Alpine Linux container, running on that Virtualization-framework foundation. It’s the execution environment the model gets when it needs to run a command, install a dependency, build code, or produce an artifact. A real Linux machine, scoped to that one project, isolated from your Mac and from every other project’s container.

┌─────────────────────────────────────────────────────────────────────┐
│ macOS Host                                                          │
│                                                                     │
│  ┌──────────────────┐                 ┌──────────────────────────┐  │
│  │ Elvean           │                 │ Alpine Linux VM          │  │
│  │                  │                 │ (one per Project)        │  │
│  │ Project          │                 │                          │  │
│  │ Container Card   │ live terminal   │ Apple                    │  │
│  │  [Terminal] icon │  ◄──────►       │ Virtualization.framework │  │
│  │                  │                 │                          │  │
│  │ AI / Model       │  ───────►       │ shell, build tools,      │  │
│  │  (runs in chat)  │   commands      │ packages, network        │  │
│  └──────────────────┘                 └──────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘

Two design choices matter here beyond the isolation itself:

You can watch it work, live. Click the terminal icon on a project’s container card and you see exactly what the model is doing, in real time, as it happens: not a summary after the fact, the actual shell output. You can also type into it yourself if you want to intervene or just poke around. This is a deliberate choice: the isolation means we don’t need to hide what’s happening from you, so we don’t.

It has a shared workspace and network access, on purpose. The container mounts a workspace folder shared with your Mac, and it has network access. That’s what lets the model work autonomously (install a package, pull a dependency, write a file you’ll actually see) without stopping every few seconds to ask permission for something that, in a fully isolated VM, carries none of the risk it would if it were running directly on your machine.

Here’s what that looks like in practice: the model running Google Flights and Airbnb CLIs inside the isolated Linux container, live, to plan an actual trip.

Video

Why this is the right tradeoff
The usual agentic-AI safety story is a wall of permission prompts: approve this file write, approve this command, approve this network request. That’s a reasonable response to running an agent directly on your host machine, where every action really is a risk. It’s also exhausting, and it’s the main reason “just use a terminal harness” doesn’t work for anyone who isn’t already deep in that world.

Hardware-level isolation changes the calculus. Once the AI is running inside a real VM that can’t reach your actual filesystem or processes, most of those prompts stop being necessary. You get the autonomy that makes agentic AI actually useful, without the constant interruption, and without the exposure, because the thing the AI can affect isn’t your Mac. It’s a disposable Alpine box that exists for exactly one project.

That’s the bet we made with the sandbox: don’t ask the user to trust the model, build an environment where trusting the model isn’t the thing that has to hold.

Best AI Client for Mac (2026): Elvean vs Jan vs Msty vs LM Studio

Nathan — Thu, 11 Jun 2026 01:13:01 +0000

If you use AI on your Mac, you've probably noticed there are suddenly a lot of apps that claim to do the same thing — run models locally, connect to cloud providers, keep your data private. It's hard to tell them apart without installing all of them.

We built Elvean — so we're biased. But we also use the others, because they exist for a reason and each one does something well. This is an honest look at four Mac AI clients in mid-2026: what they're good at, what they're not, and which one fits which kind of user.

The contenders

	Elvean	Jan	Msty	LM Studio
Native macOS	Yes (SwiftUI)	No (cross-platform)	No (cross-platform)	No (Electron)
Platforms	macOS	macOS, Windows, Linux	macOS, Windows, Linux	macOS, Windows, Linux
License	Proprietary	Open source (Apache 2.0)	Proprietary	Proprietary

Jan — free, open source, beautiful UI

Jan is the most polished open-source AI client available. Built with Tauri, it's lighter than Electron apps and has a genuinely clean, minimal design — the kind where you notice the absence of clutter rather than the presence of features. It runs local models through llama.cpp and MLX, has native MCP support, an extension system, and an OpenAI-compatible API server at localhost:1337 so you can point other tools at it.

Best for: people who want a free, open-source desktop app with a great UI, strong local model support, and an API server. If you're philosophically committed to FOSS and want something that looks good doing it, Jan is the clear pick.

Caveats: the UI has a ~800MB-1GB RAM overhead on top of model memory, CPU inference is sometimes slower than Ollama, and extensions can break between updates. Cloud model support exists but isn't the primary focus.

Price: Free.

Msty — the power-user Swiss Army knife

Msty is the most feature-dense client in this comparison. Its headline feature is split chats — run the same prompt across multiple models simultaneously and compare the outputs side by side. It also has Knowledge Stacks (RAG with local embeddings), conversation branching, a Persona Studio for custom AI assistants, Crew Conversations (multiple personas collaborating in one chat), and Turnstiles for multi-step workflow automation. MCP tool support is built in. It works with local models via Ollama/llama.cpp/MLX and all major cloud providers.

Best for: power users who want maximum flexibility — split comparisons, workflow automation, and deep customization. If you regularly A/B test prompts across models or build multi-agent workflows, Msty is the most capable option.

Caveats: the feature density comes at a cost — the UI can feel cluttered. Many of the most interesting features (Turnstiles, Forge Mode, unlimited Knowledge Stacks) are behind the Aurum tier.

Price: Free tier (core features). Aurum is $149/year or $349 lifetime one-time.

LM Studio — the best local inference engine

LM Studio is the reference standard for running local models. It's not really an "AI client" in the workspace sense — it's a local inference engine with a chat UI attached. Its MLX backend on Apple Silicon is noticeably faster than Ollama for many models, especially on larger ones, though both now use MLX on Mac so the gap has narrowed over time. The built-in model browser lets you discover, download, and run models from Hugging Face without touching a terminal, and the quantization preview shows VRAM impact before you download. It has a headless daemon mode (llmster), MCP client support, and a local API server at localhost:1234. SDKs are available for Python and TypeScript.

Best for: running local models as fast and efficiently as possible. If your primary need is "download a model and run it locally with the best performance," LM Studio is the tool for that job.

Caveats: it's local-models-only — no built-in cloud provider support. It's not trying to be a full workspace with projects, threaded conversations, or cloud tools. MCP support requires wiring things up yourself (no built-in tool catalog). It's an Electron app, so it uses more RAM than native alternatives. Proprietary software.

Price: Free for personal and commercial use.

Elvean — the native Mac workspace

Elvean is a native SwiftUI app built for macOS. It runs local models (built-in, or via Ollama/LM Studio/MLX) and connects to 300+ cloud models through your own API keys — you pay providers directly, no markup. It's the only client in this comparison that's fully native (not a web UI in a wrapper), so it launches instantly and stays light on memory.

Three things Elvean does that no other client in this comparison can:

Apple ecosystem integration. It renders Apple Maps, pulls live forecasts from WeatherKit, and connects to your Calendar — all inline in the conversation. None of the other apps integrate with macOS at this level; they're cross-platform by design and can't.
Linux sandbox for AI agents. A full Linux container runs inside the app — no Docker, no remote VM, no setup. AI models can write and execute code safely on your Mac, install CLI tools, and run real workloads without touching your host filesystem. This is uniquely Elvean.
Interactive content, not just text. Even with local models, Elvean renders charts you can click, tables you can sort, Mermaid diagrams, and photo galleries — all inline. Most local-model chat UIs give you plain markdown.

It also has threaded conversations with @mention model switching (swap between local and cloud models mid-conversation), ChatGPT and Claude conversation import, a prompt library, voice input, and a built-in demo key so you can start chatting immediately with no setup.

Best for: people who want one AI workspace that does everything on a Mac. Local models when you want privacy, cloud models when you need power, and tools (maps, charts, weather, calendar, sandbox) that go beyond chat. If you want a single app that replaces several specialized tools, Elvean is built for that.

Caveats: macOS only — no Windows or Linux. Fewer users and less community content than established apps. Requires macOS 13 or later.

Price: Free (BYOK + local models). Pro is $4.99/month for web search, charts, threads, MCP servers, and exports.

Feature comparison

This table covers what each app can do out of the box in mid-2026. "Yes" means the feature ships with the app. "Limited" means it's available with configuration or via a plugin. "No" means it's not present.

Features unique to one app in this comparison are highlighted.

	Elvean	Jan	Msty	LM Studio
Native macOS app	✅ Yes (SwiftUI)	No (Tauri/web)	No	No (Electron)
Local models (built-in)	Yes	Yes	Yes (via Ollama)	✅ Yes (primary focus)
Cloud models (BYOK)	✅ Yes (300+)	Yes	Yes	No
Demo key (zero setup)	✅ Yes	No	No	N/A
MCP tool support	Yes	Yes	Yes	Yes (manual setup)
Web search	Yes (Pro, DuckDuckGo)	Via extension	Yes (Aurum)	No
🆕 Apple Maps, Weather, Calendar	✅ Yes (Pro)	No	No	No
🆕 Linux sandbox	✅ Yes	No	No	No
🆕 Interactive charts, Mermaid, tables, galleries	✅ Yes (Pro)	No	No	No
🆕 @mention model switching	✅ Yes	No	No	No
🆕 Import from ChatGPT & Claude	✅ Yes	No	No	No
Threaded conversations	Yes (Pro)	No	✅ Yes (branching)	No
Split chat / multi-model	No (threads instead)	No	✅ Yes	No
RAG / knowledge base	Yes (Projects + KB)	Extensions	✅ Yes (Knowledge Stacks)	Yes (documents)
Prompt library	Yes	No	Yes	No
Voice input	Yes	Via extension	No	No
Local API server	No	✅ Yes (localhost:1337)	No	✅ Yes (localhost:1234)
Headless/CLI mode	No	✅ Yes	No	✅ Yes
Export (Markdown, HTML, PDF)	✅ Yes (Pro)	No	No	No
🆕 Edit responses in Markdown	✅ Yes (Pro)	No	No	No
No account required	Yes	✅ Yes (open source)	Yes	Yes
Price	Free / $4.99mo	Free	Free / $149yr	Free

Which one should you use?

It depends on what you need, and being honest about that is more useful than pretending any one app wins for everyone.

Get Jan if you want a free, open-source desktop app with a polished UI and you don't need macOS-specific integrations. It's the best FOSS option in this space.

Get Msty if you're a power user who wants split-model comparisons, workflow automation, and the deepest feature set — and you're willing to pay for it.

Get LM Studio if your only goal is running local models as fast as possible. Its MLX backend and model browser are the best in class for local inference.

Get Elvean if you want a native Mac workspace where local and cloud models work together alongside real tools — maps, charts, weather, sandbox, calendar — in one app. If you're tired of juggling multiple specialized tools, this is what it's for.

All four apps are under active development. The landscape in mid-2026 moves fast, and the right choice six months from now may look different. The best thing you can do is install the one that matches how you actually work and see if it fits.