Phil Wheat · Singularity Innovations

Client Software Stack — The Road Not Taken

I’ve reviewed a lot of packages to find what worked best.

· Local LLMs Development

I’ve reviewed a lot of packages to find what worked best. Since finding out what didn’t work and why is as important as seeing what does work, here’s a list of some of the tools I tried — and why I don’t use them today. Some of them are really good; they just don’t meet my needs, and some just didn’t click at all. I’ll go through each of them and you can see if they might work for you even if they didn’t work for me.
(For contrast, if you missed what I use that did make the cut from these evaluations, you can find that list at Client Software Stack — What I Run

Why This Matters

If you’ve been working with LLMs, you’ve probably stuck with some of the normal hosted options. But when you step out of that world, there’s a whole world of various approaches to working with the models. Most of the server stacks have a good bit of commonality, but when you get to the clients (or harnesses as they are becoming commonly called) then your options really explode. This happens because how people use them varies a LOT so you’ll see a lot both explicit and implicit assumptions when you look at the offerings.

Claude

What it is: Anthropic’s official desktop application for Claude, built as an Electron-based native client that brings the Claude AI assistant to your desktop with native system integration, MCP (Model Context Protocol) support, and desktop extensions.

Architecture: Electron/TypeScript desktop application. Ships as a cross-platform native app (Windows, macOS, Linux) that connects to Anthropic’s Claude API endpoints. Since early 2026, it has native MCP support, making it the reference implementation that other clients follow. MCP servers are installed via Desktop Extensions (.mcpb bundle files) with a one-click install flow. The architecture follows a client-server model where the desktop app is a UI shell — all model inference and reasoning happens on Anthropic’s servers. Voice input, document upload, and multi-modal processing are handled through Anthropic’s cloud APIs. Claude Code (the terminal-based agentic variant) is a separate product built on the same model but with a CLI-first interface for software development.

Key Features:

  • Desktop Extensions — one-click MCP server installation via .mcpb bundles
  • Multi-modal input: text, images, PDFs, documents
  • Voice dictation and readback (2026)
  • Desktop context awareness (clipboard, file system access via MCP)
  • Claude Code variant with plan/build modes, skills, hooks, and parallel subagent support

Why I didn’t keep using it:
You can’t seem to go ANYWHERE these days without hearing about Claude. And I did give it a serious go, it can run against local LLMs and Lemonade (my default local server) even offers up specific Anthropic compatible endpoints. It had everything going for it except one thing. It is WELDED to Bash shell. And not even something compatible like Git Bash, but it REALLY, REALLY wants native Bash.

If you’re OK with using WSL2 on Windows, then you can probably work with this, but the fact that doing so meant all my work had to be on Localhost rather than being able to move around on my home network to access resources, I had to give Claude a pass. And honestly, I don’t really miss it much - besides not having a common experience when I talk to people about how they use LLMs for their work.

Cherry Studio

What it is: An open-source, cross-platform desktop client that aggregates multiple LLM providers into a single unified interface. Built as an Electron/TypeScript application (GitHub: CherryHQ/cherry-studio), it lets you connect to 300+ models across providers including OpenAI, Anthropic, Gemini, Ollama, and LM Studio.

Architecture: Electron/TypeScript desktop app (Windows, macOS, Linux). All usage data is stored locally — it doesn’t upload conversations to any third-party server. The client connects to any provider compatible with the OpenAI/Anthropic API format. It includes a built-in knowledge base feature that supports importing files in various formats and web page content for personal RAG-style setups. Supports MCP integration. The architecture is fundamentally a multi-provider proxy: the app acts as a routing layer that forwards requests to whatever API endpoint you configure, with local-only storage for conversation history.

Key Features:

  • Multi-model conversations (compare responses from different models simultaneously)
  • Built-in knowledge base for personal RAG (import files, web pages, PDFs, Office documents)
  • 30+ industry-specific intelligent assistants (developer, designer, writer presets)
  • AI-powered translation built in
  • Drag-and-drop conversation/agent organization

Why I didn’t keep using it:
This one was tough to cut from my list. I REALLY liked Cherry Studio. I worked really hard to make it work and become my daily driver. The primary problem I had with it was finding a good community around it and discovering its functionality. It felt like a solid client with lots of features and a stable base, but most of the communities seem to be Telegram based and not in English. If that’s not a problem for you, I’d really recommend you taking a look at it, it seems to have a lot of potential.

Msty Studio

What it is: A private AI workspace and autonomous agent platform that bridges local and cloud models. Originally launched as Msty App v1.x (a GUI for local AI with built-in model downloads), it evolved into Msty Studio — a full workspace with knowledge stacks, automations, media generation, persona conversations, and an autonomous agent called “Claw” that runs multi-step tasks with sandboxed folder-scoped execution.

Architecture: Desktop application with a dual-architecture approach: (1) local inference via built-in model downloads (for CPU/GPU on your machine) and Ollama integration, (2) cloud models via remote providers (OpenRouter, Hugging Face, etc.). Msty Stack provides centralized private inference so teams can run on-prem servers. The agent runtime “Claw” executes multi-step tasks using model-accessed tools with sandboxed, folder-scoped execution on your machine. Supports MCP, tool-enabled chats, and dynamic context pulling. Uses a knowledge stack architecture for RAG that can connect to Obsidian vaults, files, websites, and YouTube transcriptions. Context Studio (recent overhaul) manages reusable files, websites, YouTube videos, and media as a full context library with dynamic pull mode (tools search metadata first, read files on demand).

Key Features:

  • Parallel Multiverse Chats — split chat feature comparing multiple models in real-time
  • Knowledge Stack for RAG: import files, connect Obsidian vaults, add YouTube transcriptions
  • Media Studio: image, audio, and video generation
  • Context Studio: reusable context library with tree view, multi-select, and dynamic pull mode
  • Persona conversations with customizable model settings

Why I didn’t keep using it:
Msty was an app I ran across that was highly recommended in several forums. I was mainly focused on the desktop version but it just didn’t click. Part of the problem I have with it is that the desktop is really just a web app that needs a “sidecar” to actually use local resource - which is basically a custom server that you have to set up and maintain. And then while I was looking at it, the app itself seemed to be headed to a licensed focus. I’m actually OK with that, except it was a “buy before try” situation with some features I needed promised in the future.
I think if you’re a Mac user or focused on Mobile work, it might be an option. But since I really didn’t fit into the direction it was going, I’m probably not the best person to do a proper evaluation of it.

OpenHands

What it is: An open-source (MIT-licensed), model-agnostic platform for autonomous software development agents. Originally known as OpenDevin, it lets agents plan, edit code, run commands, browse the web, test changes, and produce pull requests — running locally, self-hosted, or via OpenHands Cloud. Built by a community of 188+ contributors from academia and industry.

Architecture: Python-based framework with a stateless Agent that emits Actions, a Conversation loop that maintains an append-only EventLog, and a Workspace (local process or Docker container) that executes Actions and returns Observations. LLM integration uses LiteLLM for provider portability — any LLM backend works. The flagship CodeActAgent is built around a minimal tool set: bash, Python, and a browser DSL — instead of giving the LLM 20 bespoke tools with JSON schemas, it lets the agent express anything as code. The OpenHands Software Agent SDK defines core components (agents, LLMs, conversations, tools, workspaces, events, security policies) with strict boundaries between research and deployment. Supports multi-agent collaboration, sub-agent delegation, and human-in-the-loop interaction. Sandbox execution in Docker containers for secure, isolated task running.

Key Features:

  • Model-agnostic LLM routing (any model via LiteLLM)
  • Autonomous coding: plan, edit, test, and deploy code
  • Sandbox execution in Docker containers for security
  • Multi-agent collaboration and sub-agent delegation
  • Built-in security analysis and lifecycle control

Why I didn’t keep using it:
Openhands was talked up quite a lot when I was doing my evaluations - the conversation seems to have died down a bit since then though. The focus seems to really be on the hosted options, but running it locally in a docker environment is offered and because of some of the potential, I actually made an exception to my “no docker” rule for it. I got it set up and was interested in its ability to manage its own sandboxes and do a good bit of agentic work without exposing too many local resources to risk. I love the ideas behind it, but it REALLY seems to want them to be your provider. I was able to get it connected to my Lemonade server, but even with custom work from Lemonade, it just didn’t work well. I suspect if I had gone with their hosted back end it would have been a nice environment with lots of pluses, but that’s not what I was looking for.

Askimo

What it is: A free, open-source, privacy-first AI desktop toolkit that consolidates multiple AI models into a single native desktop application. GitHub: askimo-ai/askimo. Built on Electron, it positions itself as more than a chat interface — a personal AI workbench for end-to-end workflows including chat, file search, script execution, multi-step plans, and agent skill execution.

Architecture: Electron/TypeScript desktop application (Windows, Mac, Linux). Multi-provider architecture: each session can be configured with a different provider (OpenAI, Anthropic Claude, Google Gemini, Grok, Ollama, LM Studio, LocalAI, Docker AI, or any OpenAI-compatible endpoint). All conversations and data are stored locally. RAG architecture indexes your local files and folders on the machine — no data uploaded externally — enabling search-and-chat over your own knowledge base. Supports Skills: reusable AI agents defined as Markdown files that execute via Claude Code or Gemini CLI. Includes built-in Python/Bash/JS script execution, multi-step Plan chaining, and MCP tool connections. The app has two modes: a lightweight built-in AI for quick conversations (no extra installs), and a more capable mode that runs Claude Code or Gemini CLI agents on your machine.

Key Features:

  • Multi-provider switching per session (OpenAI, Claude, Gemini, Grok, Ollama, LM Studio, LocalAI, Docker AI)
  • Local RAG: search and chat with your own files and folders without uploading anything
  • Built-in script execution (Python, Bash, JavaScript)
  • Multi-step Plan chaining for workflow automation

Why I didn’t keep using it:
This is one of those tools that I think might have worked, but I started working with it while I was testing OpenCode and Hermes Agent, and Roo was going through its issues. So I probably didn’t give it a fair shake. I did like the ease of setup and how it seems to work, but I never really ran it through its paces. I mention it here because it did make the cut to get an install and nothing jumped out as bad - I just ran out of attention and it kind of languished as my toolset formalized. I’m happy to hear if others had good or bad experiences with it.

Roo Code

What it is: An open-source AI coding agent extension for Visual Studio Code and JetBrains IDEs. Built as a fork of Cline, it gave developers a “whole dev team of AI agents” inside their editor through a mode-driven workflow. The project hit 3 million installs before being shut down and archived by Roo Code, Inc in May 2026 when the company pivoted to a cloud product (roomote.dev).

Architecture: TypeScript-based VS Code/JetBrains extension. The architecture follows the Cline family pattern — an agentic loop where the extension communicates with external LLM APIs (not bundled models). Its defining architectural feature was the mode system: five distinct personas — Code, Architect, Ask, Debug, and Custom — each with its own system prompt and model assignment. You could assign different models to different modes (e.g., Gemini 2.5 Pro for Architect mode, a cheaper model for Ask mode), making it cost-controllable. The extension maintained a conversation state with the LLM and could execute file edits, run terminal commands, and use MCP servers. Roo Code forked from Cline (the original upstream project) and was itself forked by the community as ZooCode after shutdown.

Key Features:

  • Mode-driven workflow: Code, Architect, Ask, Debug, and Custom Modes
  • Per-mode model assignment (mix and match models for cost/performance balance)
  • Custom Modes for team-specific or project-specific behavior
  • File editing, terminal command execution, and browser use within the IDE
  • .roomodes and .roo/rules/ configuration files for project-level mode definitions

Why I didn’t keep using it:
I’m a bit sad to put Roo on here as it was my absolutely Go To tool when I started working with my local server. I was coming from Github Copilot and Roo brought the proper mix of what I was used to plus new capabilities and worked locally which Github Copilot didn’t do at the time. It got updated well, and had a great community.
The issue was that the team doing it pivoted to doing a subscription service and shut down the client. While I completely understand the need to make a living, this was the factor that really started me evaluating tools seriously. My current mix works well enough that by the time ZooCode got set up, I had already shifted my workflow. I can’t comment on ZooCode, but I will say that I suspect it works well - it just fell into the same situation as Askimo. When it came into play, my workflow was already consolidating around my current tools.
It is a great example though of how you should always be prepared to pivot, even with paid tools. Directions change, economies shift, and in a space this fast moving - be prepared for your tools to go in a direction you aren’t heading and have a plan for if that happens.

GitHub Copilot

What it is: GitHub’s AI-powered coding assistant, built by the GitHub/OpenAI partnership. Originally launched as an autocomplete tool in 2021 powered by OpenAI’s Codex, it has evolved into a full AI coding assistant with chat, agent mode, code review, CLI integration, and a cloud agent — available across VS Code, JetBrains IDEs, Neovim, GitHub.com, and GitHub Mobile.

Architecture: Cloud-hosted SaaS service that integrates as an extension in development environments. Uses a multi-model backend — initially OpenAI Codex, now supporting GPT-5.4, Claude Sonnet 4.6, and Gemini 2.5 Pro depending on your plan. The core architecture is a token-by-token autocomplete engine that sits in your editor, suggesting code completions as you type. Copilot Chat provides conversational AI inline in the editor, while Agent Mode (introduced more recently) transforms it into a task-executing tool that can plan, edit, execute, and iterate across your codebase through Copilot Chat in VS Code. Copilot consumes GitHub AI Credits for agent mode, code review, CLI, and chat operations. The free tier offers 2,000 completions/month.

Key Features:

  • Copilot Chat for conversational AI within the IDE
  • Agent Mode — autonomous task execution (plan, edit, execute, iterate)
  • Copilot CLI and Copilot Cloud Agent for terminal-based workflows
  • Code review integration with pull requests
  • Integrated across VS Code, JetBrains, Neovim, GitHub.com, GitHub Mobile

Why I didn’t keep using it:
The tool I started with for LLM assisted development and I still have my legacy subscription. But I rarely use it anymore - it is primarily for if I actually need to do something on Github itself when working with projects there. At the time I got started with my local LLM journey, that wasn’t supported with the client version. It has been added, but as with the Roo/Zoo situation, it settled down after I had already moved my workflow to my current toolset. And honestly, I find it rather lagging from the other tools. It is useful at times and has some features - but almost all those features are tied to cloud/hosted items. I keep it around because you really can’t avoid GitHub these days and with my legacy plan, the cost isn’t horrible. But that’s about all I use it for.

The lay of the land

One of the biggest issues I have run into with evaluating tools is that you either get a CLI tool written in an interpreted language - and the performance that implies - or an Electron or Flutter app which has the normal problems with that approach of accessing local resources. Finding a local, native tool that works with local servers really narrows the options a LOT.
Many (most?) offerings happen like OpenWebUI which bridge the local/hosted options by simply offering Docker containers that run on local servers. That does limit things a lot - simple things like “review this local git repo” become much more difficult with that model. You can make it work, but it’s not just the tool’s container you have to deal with, but now you’re probably looking at a locally hosted Git server, some kind of identity system, the list keeps growing. Doable, but a lot more work than you initially thought.
There’s also the predominance of Bash as the required shell. WSL2 makes this possible, but as I’ve mentioned several times, the networking issues that WSL2 has when trying to access interfaces it hosts from other computers make that much less interesting to me. Not to mention the slowness of passing files into and out of WSL2 from the host computer.

Wrap-Up

So hopefully some of these might be helpful for you or at least help you set up your own criteria for how you evaluate clients yourself. There are a LOT of offerings out there and it seems more every single day. The tools change constantly, being introduced, abandoned, forked. It is an incredibly dynamic time, and you can spend far too much effort constantly evaluating new items.
My best recommendation is to set out your specific criteria that you’ll need, then evaluate to see which tools best fit that - hopefully you’ll find some that fit all of them but be prepared to have to make some compromises. Then lean into your choices, once you’ve got a set of tools, dig in and set your workflow to them until given a reason to change. There will always be something shiny coming out - don’t get distracted with those vs actually getting something done.

And on that note, this wraps up my series on what I use. And now to take my own advice, the next set of articles will be on how to actually build something. Keep an eye out for the project description and how I plan to show not just the tools in use but hopefully end up with something that might be interesting to use.

And if I missed something you think I should have looked at (within the constraints I’ve mentioned) or you think I haven’t given something a fair evaluation, please let me know. Things change and there’s always something more to learn.

Originally published on Substack on July 17, 2026.