DeepSeek TUI rocketed to almost 33,000 stars on GitHub within two weeks of launching. Its creator describes it as a terminal user interface (TUI) harness for DeepSeek’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 and 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 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 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 repo ships with a Nix flake. Comparing its ** flake.lock** with Flox’s yields the following:
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’smanifest.lock
complete, resolved dependency graph.
In the bare Nix model, you can pin ** nixpkgs**, individual sources, or package overrides, then evaluate the
closureto inventory the resulting package set. In Flox’s model, package names, versions, target platforms, derivations, outputs, and store paths get automatically recorded. Plus with
FloxHubyou 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. 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, Rust dev, Ollama, oMLX 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
Ollamaon Linux; Ollama or
oMLXon 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.
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 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 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, down 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?