Run Frontier Models Anywhere with DeepSeek TUI

DeepSeek TUI, a terminal user interface for DeepSeek's models, has gained nearly 33,000 GitHub stars in two weeks. The tool can run against other providers including local models via Ollama or oMLX, and developers can install it using Flox or Nix environments for reproducible setups on Linux, macOS, and Windows/WSL2.

Run Frontier Models Anywhere with DeepSeek TUI, Nix, and Flox DeepSeek TUI rocketed to almost 33,000 stars on GitHub https://github.com/Hmbown/DeepSeek-TUI within two weeks of launching. Its creator https://github.com/Hmbown describes it as a terminal user interface TUI harness for DeepSeek https://www.deepseek.com/en/ ’s local and cloud models, much as Claude Code is for Anthropic’s and Codex is for OpenAI’s models. But like these harnesses, DeepSeek TUI can run against other providers—including local models. With a local Ollama or oMLX model server, you can run DeepSeek TUI against Qwen v3.6 and other cutting-edge local frontier models. This article shows two simple patterns for installing and running models locally using DeepSeek TUI as a harness. It showcases how to use CLI coding harnesses DeepSeek TUI against local Qwen 3.6 models optimized for CUDA and MLX, Apple’s open-source machine-learning array framework for Apple Silicon. The first pattern has two variations: - Run DeepSeek TUI using a pre-packaged, pre-configured Flox runtime environment ; - Run DeepSeek TUI as a Nix flake against the remote GitHub repo. The second pattern, attached as an Appendix , shows software engineers how Flox and Nix drop right into their workflows. It uses Flox and Nix standardized development environments to reproducibly build and run DeepSeek TUI from source on Linux, macOS, and Windows/WSL2. It's a proof of concept for using Flox or Nix dev environments to work with Rust and other projects. In both patterns, the same declarative environment can run reproducibly in local dev, CI, or production. No containers required. Running DeepSeek TUI Against Local Models This pattern has two distinct variations. The first uses a Flox environment, the second a Nix flake. 1. With Flox The Flox variation of this pattern uses a pre-built deepseek-tui package. Flox itself tracks the upstream DeepSeek TUI project, rebuilding from source and republishing the package as new releases ship. It's an example of a Flox runtime environment, bundling DeepSeek TUI and its dependencies, along with a custom-built package that provides setup automation and wrapper helper functions. deepseek-tui Note : This environment composes modular, platform-specific Flox environments for Ollama https://github.com/ollama/ollama and oMLX https://github.com/jundot/omlx . If either is already installed on your system, run the command below without the -s switch, which is used to start services. You can view the manifest for this environment https://hub.flox.dev/flox-labs/deepseek-tui/manifest on FloxHub. To run Deepseek TUI on Flox, first do: This environment ships with handy prebuilt wrapper functions. So on macOS or Linux, running ...starts DeepSeek TUI with the requested model using Ollama on Linux, oMLX on macOS. If the requested model doesn’t already exist on the local system, the wrapper transparently pulls it from the correct upstream provider Ollama on Linux, HuggingFace on macOS before starting the TUI. On macOS, the wrapper also 1 prompts the user for their HuggingFace token if not already set and 2 transparently restarts the oMLX model server so that it picks up the new model. This changes the workflow from... ...to: It’s an effective demonstration of the types of user-friendly affordances you can build into Flox environments. Optionally, you can skip the separate activation step and run: This activates and runs DeepSeek TUI from FloxHub without putting the user “in” to the Flox environment. To run the latest Qwen3.6 on Linux, just run: On macOS run: 2. With Nix The upstream Nix flake has two tests that fail in the Nix build sandbox; we've submitted a PR https://github.com/Hmbown/DeepSeek-TUI/pull/1844 but we’ll need to run against our fork until it merges: Note : The failing tests only affect nix run and the Nix runtime environment: it’s possible to use the upstream flake as a dev environment to build and run the bin with deepseek . cargo A key difference with the Nix variation on this pattern is that you’re building DeepSeek TUI from source and then running it. The Flox environment ships it as a defined, pre-packaged dependency, so there’s no build step. The Nix pattern must fetch, build, and realize DeepSeek TUI in the Nix store. This takes several minutes on a 32-core/64-thread system, and even longer on a less beefy machine. That being said, what if you want to build DeepSeek TUI from source? For example, to checkout and build our forked/fixed branch? The Appendix walks through doing this with both Flox and Nix. Standardize Your AI Workflows from Local Dev to Production Standardized Flox and Nix environments declare all you need to reproducibly build and run projects like DeepSeek TUI. But this same pattern generalizes to any AI workflow that depends on a mix of model servers, CLI harnesses, language runtimes, native libraries, services, and platform-specific acceleration. With Flox and Nix, you can declare, govern, and share AI workloads across local laptops, CI, and production. The operational payoff is clear: In local dev everyone uses the same Flox environment; if something breaks, teams can see what changed and when; When it's time to ship code , the same Flox environments run reproducibly across machines, platforms, and time, at every stage of the SDLC; As teams operationalize AI environments , platform teams can version and legibly govern standardized dev or runtime environments; For audits, incident response, and release review , security and compliance teams can more easily identify where specific package versions are used. This isn’t magic, and it works a little differently between Flox, which is built on Nix, and Nix by itself. It's worth exploring how Flox and Nix differ ... and why. For example, the upstream DeepSeek TUI https://github.com/Hmbown/DeepSeek-TUI repo ships with a Nix flake. Comparing its flake.lock with Flox’s yields the following: manifest.lock https://github.com/flox/deepseek-tui/blob/main/.flox/env/manifest.lock - The Nix pins three upstream flake inputs to specific Git revisions and content hashes. You always get the same source trees, but not necessarily the same package versions. flake.lock - The Flox for the DeepSeek TUI runtime environment pins every individual package on every target platform Linux or macOS; x86-64 or ARM to a specific version, derivation, and set of Nix store paths. In other words, it records the environment’s manifest.lock complete, resolved dependency graph . In the bare Nix model, you can pin nixpkgs , individual sources, or package overrides, then evaluate the closure https://nix.dev/manual/nix/2.25/glossary.html?highlight=closure gloss-closure to inventory the resulting package set. In Flox’s model, package names, versions, target platforms, derivations, outputs, and store paths get automatically recorded. Plus with FloxHub https://hub.flox.dev you get the ability to generate authoritative SBOMs for individual packages and runtime environments. Flox turns a standardizd runtime from something teams can reliably reproduce into something they can also inspect, diff, audit, govern, publish, and query across local dev, CI, and production. Run, Share, and Govern AI Environments with Flox As AI environments morph from one-off local experiments into shared platform assets, the operational question changes from “How do I run this?” to “How do I understand, audit, and reproduce exactly what ran?” Flox makes the dev or runtime environment visible and legible : e.g., you can diff two lockfiles and see that openssl advanced from v3.6.0 to v3.6.1, rather than only seeing a change e.g., a new Git commit to a flake input. It all starts with FloxHub https://hub.flox.dev . Generate authoritative, indexable SBOMs for dev and runtime environments. Reference and run them locally, in your CI pipelines, or your Kubernetes pod specs. Create and share your own managed environments, or activate prebuilt environments like DeepSeek TUI https://hub.flox.dev/flox-labs/deepseek-tui/manifest , Rust dev https://hub.flox.dev/flox-labs/rust-dev/manifest , Ollama https://hub.flox.dev/flox-labs/ollama/manifest , oMLX https://hub.flox.dev/flox-labs/omlx/manifest the same way: remotely, reproducibly, anywhere. Appendix: Building and Running DeepSeek TUI from Source This pattern also has two variations. One uses a Flox standardized dev environment for working with Rust. Nothing special; no DeepSeek TUI-specific adaptations. You can use this pattern to work with any Rust project. Two uses the flake.nix that’s included with the repo to build and run the DeepSeek TUI app. If you have Nix or Flox, which installs Nix by default , you can build and run the flake. 1. Building with Flox Whether using the Flox environment or Nix flake, first clone the upstream repo to your local system: Then change into the directory and run: This runs a remote FloxHub environment thus the -r switch called . rust-dev Note : Flox ships a canonical Rust example environment: flox/rust . This environment includes an essential, common-sense set of Rust dependencies; however, it lacks common cross-language and/or cross-platform dependencies. It’s a canonical example that you can take and customize as your own. The flox-labs/rust-dev environment adds platform-specific compilers, a package, and python3 for Linux. The dbus section defines all of the packages available in the activated environment: install The hook exports onto $FLOX ENV/lib on Linux so Rust crates that call LD LIBRARY PATH at runtime like dlopen and openssl can find shared libraries. The dbus sets profile to RUST SRC PATH , where the $FLOX ENV package installs the standard library source. This enables go-to-definition and inline docs in rust-lib-src . rust-analyzer With Flox, you build DeepSeek TUI just like you’d build any other Rust project: You could combine this with the Flox activation step— flox activate -r floxlabs/rust-dev -- cargo build --release , or even —to run the flox activate -r floxlabs/rust-dev -- cargo run –release CLI. Before doing this, however, you’ll want to make sure you have a local model server installed: deepseek Ollama https://github.com/ollama/ollama on Linux; Ollama or oMLX https://github.com/jundot/omlx on macOS. We show a simple way to do this in Section 3 , below. 2. Building with Nix The DeepSeek TUI repo includes a Nix flake. If you’re curious about what this flake looks like, you can view it here https://github.com/Hmbown/DeepSeek-TUI/blob/main/flake.nix . Once you’ve cloned the upstream repo, cd into the directory and run: Once Nix evaluates and realizes the environment, run: This uses cargo to compile the project in the Nix dev environment. The failing tests defined by the only affect flake.nix which builds and tests inside an isolated sandbox. We could also run: nix run Note, however, that running DeepSeek TUI directly from the repo... ...won’t work unless or until DeepSeek TUI’s maintainers fix the broken flake tests. But before running DeepSeek TUI from its repo, make sure you’re running a local model server, like Ollama on Linux or Ollama / oMLX on macOS. The next section gives you a simple way to do this. 3. Getting a local model server You can run DeepSeek TUI against DeepSeek models in the cloud, but what’s the fun in that? Local model serving is where it’s at, and model servers like Ollama, oMLX, and LM Studio https://github.com/lmstudio-ai give us powerful options for local inferencing. We’ve tested DeepSeek TUI against Ollama and oMLX; you can probably run it against LM Studio, too. If you don’t already have either model-serving platform installed, just run... or ...within the DeepSeek TUI repo. This runs a remote FloxHub environment on-demand, layering https://flox.dev/docs/tutorials/layering-multiple-environments/?h=layering it on top of the repo. The Flox-managed Ollama or oMLX services are available so long as you’re in this remote environment. Your prompt will change such that it’s prepended by flox flox/ollama or . Once you quit this environment, Flox automatically shuts down the service s it defines. flox flox/omlx 4. Running DeepSeek TUI from the repo First pull your model of choice. On Ollama do: If you prefer oMLX , downloading models is slightly less straightforward. oMLX doesn’t provide its own ollama pull -like command to fetch them, so you’ll need to pull them from HuggingFace, which means a you’ll need to use the HuggingFace CLI, which is bundled with oMLX, and b you’ll need a HuggingFace token. Export this token as an env var, then do the following to download your model… … and then restart the Flox omlx service to pick it up: Finally, you’re ready to fire up the deepseek CLI with the Qwen 3.6 model. For Ollama run: For oMLX, run: Nix users can build and run from the Nix dev shell: If all of this seems quite a bit more involved in a dev setup, it is. But this is what software engineers do several times daily to build, test, debug, and ship the packages and runtime environments we rely on. It all starts with FloxHub https://hub.flox.dev . Why not flox activate -r and take Rust https://hub.flox.dev/flox-labs/rust-dev , C/C++ https://hub.flox.dev/flox-labs/cxx , Go https://hub.flox.dev/flox/go , Python https://hub.flox.dev/flox-labs/python3 , Ruby https://hub.flox.dev/flox/ruby , Zig https://hub.flox.dev/flox-labs/zig , JavaScript/Typescript https://hub.flox.dev/flox-labs/node , Erlang https://hub.flox.dev/flox-labs/erlang , or one of our other reproducible dev environments for a test-drive?