
Alexander is a writer, traveler, and serial digital entrepreneur. He’s the founder of the Tushi, the Gen X personal growth newsletter Further, and offers small business advice at Unemployable.

Twitter

Linkedin

Facebook

Director and Chief Evangelist

Alexander Hipp


Anil is a content-obsessed marketer who loves driving organic traffic for outstanding companies. He is also the creator of Hack the Content, co-host of The Runner, and owner of several digital commerce sites.

Managing Partner

Anil Vugels


Monika is a writer, musician, and content strategist with a passion for language. When she isn’t helping clients, you can find her writing songs, hiking in a northern forest, or furiously journaling.

Director of Operations

Ann Monika

Mastodon

Github

Programmer / Founder / Student

Tim Schupp


## My Titan 2 Elite Advanced Setup

I hope this doubles as a written guide on how to get Termux up and running on the Titan 2 Elite;
this is the exact setup I run daily as a pocket terminal / dev machine.

#### **1. Install tmux from F-Droid**

Get `tmux` (and Termux itself) from [F-Droid](https://f-droid.org/).
The version in the Play Store will *not* work for you; it is out of date and the required mirrors cannot be set up on it.

#### **1.5. Install Unknown Keyboard and my custom symbols layout**

For anything resembling real terminal work you need a keyboard that gives you quick access to special characters.
I use [Unknown Keyboard](https://f-droid.org/en/packages/jp.co.hi_zya.keyboard/) with this custom symbols layout:

```xml
<?xml version="1.0" encoding="utf-8"?>
<keyboard name="Symbols (1-Row)" script="latin">
  <row>
    <key c="(" ne=")" nw="&lt;" se="&gt;"/>
    <key c="[" ne="]" nw="{" se="}"/>
    <key c="=" n="+" s="-" e="*" w="/" nw="%" ne="^"/>
    <key c="\\" n="|" w="~" se="`"/>
    <key c="." n="," e="!" w="\?" ne=":" nw=";"/>
    <key c="&quot;" n="'" e="_" w="-"/>
    <key c="\@" n="\#" e="&amp;" s="%"/>
    <key c="$" ne="€" se="£" sw="¥"/>
  </row>
</keyboard>
```

Also, for my optimal usage, I apply the following key mappings:

- `alt` -> `shift`
- `left shift` -> `alt`
- `home` -> `ctrl`
- `right shift` -> `tab`
- `space` -> `home`

Now you should be able to manage and navigate everything similar to a regular keyboard.
*Note that the Unknown Keyboard will still be required for some special chars!*

#### **2. Set up your Termux package mirrors**

```bash
termux-change-repo
```

Then update and prepare the packages:

```bash
pkg update
pkg upgrade
```

#### **3. Set up Termux storage**

```bash
termux-setup-storage
```

#### **4. Install some helpful packages**

```bash
pkg install git
pkg install gh
pkg install neovim
```

<img width="807" height="900" alt="Termux setup on the Titan 2 Elite" src="/static/assets/titan_setup/02_termux_screenshot.png" />

#### **5. Set up opencode**

I run [opencode](https://opencode.ai/) on the phone via the Termux port from [Hope2333/opencode-termux](https://github.com/Hope2333/opencode-termux).
Grab an `opencode` binary from the [release page](https://github.com/Hope2333/opencode-termux/releases), then:

```bash
apt install -y glibc-repo
apt update
apt install -y glibc openssl-glibc

dpkg -i /path/to/opencode_<version>_aarch64.deb
```

If you want to configure it for local llm usage, check out [my article on usability with local llms](https://blog.t1m.me/blog/opencode-with-local-llms).

#### **6. Running a local llm**

Multiple options here; for now the simplest one: download [Ollama](https://play.google.com/store/apps/details?id=com.ollama) from the Google Play Store.

#### **7. Setting up QEMU**

Termux ships QEMU packages, so we can run a *full Linux VM* right on the phone.
Since Android won't expose KVM on an unrooted device, the guest runs fully emulated as x86_64 through TCG (`-machine q35,accel=tcg`);
slower than native virtualization, but completely functional and headless (`-nographic`), which is all I need inside tmux.

I scripted the whole flow and attached all scripts to this post; grab them straight into Termux:

```bash
for s in setup-host start-installer start-vm postinstall-alpine kill-vm reset-vm; do
  wget "https://github.com/tbscode/tims-blog-posts/raw/main/assets/titan_setup/scripts/$s.sh"
done
chmod +x *.sh
```

Each script is also linked inline below, so you can read exactly what it does before running it.

#### **8. Preparing the host: `setup-host.sh`**

One script does all host preparation: [`setup-host.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/setup-host.sh)

It will:

1. install the required packages (`qemu-system-x86_64`, `qemu-utils`, `wget`)
2. create the host shared directory at `~/docker_shared`
3. create a 50G `alpine.qcow2` disk image (if missing)
4. download the `alpine-virt-3.20.2-x86_64.iso` (if missing)
5. make the helper scripts executable

```bash
bash setup-host.sh
```

#### **9. Installing Alpine inside QEMU**

Now boot the installer with [`start-installer.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/start-installer.sh);
it boots the ISO from the qcow2 disk, forwards `2222 -> 22` and `8080` to the host, and exposes `~/docker_shared` to the guest via a 9p `hostshare` mount:

```bash
./start-installer.sh
```

Then inside the VM:

1. log in as `root` (no default password)
2. run `setup-alpine`
3. select the `vda` partition and `sys` as the installation type
4. set a strong root password
5. `poweroff` once the install completes

Here's the disk & install step; you can also see the extra-keys row and my custom symbols keyboard in action, which make navigating and typing the installer prompts feel almost like a real terminal session:

<img width="540" height="602" alt="setup-alpine selecting the vda disk with sys install type in Termux" src="/static/assets/titan_setup/03_alpine_setup_vda.png" />

Boot the installed system with [`start-vm.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/start-vm.sh) (same flags, minus the ISO), log in as `root`, and run [`postinstall-alpine.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/postinstall-alpine.sh) inside the guest
(it is already visible under `/mnt/shared` once you mount the share, or just paste its contents):

```sh
sh /mnt/shared/postinstall-alpine.sh
```

The script hardens and provisions the base system in one pass:

- enables the `community` repository and installs `sudo`, `docker`, `docker-cli-compose`, `shadow`
- creates your user, adds it to the `docker` group and grants full sudo access
- enables the Docker daemon at boot
- configures the 9p share as a persistent auto-mount at `/mnt/shared`, owned by your user

Verify everything works from inside the VM:

```bash
su - <your-user>
docker run --rm hello-world   # docker works without root
sudo apk update               # sudo works
touch /mnt/shared/test.txt    # file appears on the host in ~/docker_shared
```

That's it: a persistent Alpine with Docker, reachable from the host via SSH on port `2222`, sharing files through VirtFS.

And it's genuinely usable for real work; here I'm building [this very blog](https://blog.t1m.me) through the shared folder inside the VM:

<img width="540" height="602" alt="docker compose build of the blog running inside the Alpine VM via the shared folder" src="/static/assets/titan_setup/04_docker_compose_build.png" />

##### Day-2 helpers

- [`kill-vm.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/kill-vm.sh) — stops any running QEMU VM process (graceful, then forced)
- [`reset-vm.sh`](https://github.com/tbscode/tims-blog-posts/blob/main/assets/titan_setup/scripts/reset-vm.sh) — wipes and recreates the qcow2 disk when you want a clean slate

---

That's it for now; the phone happily sits in my pocket running tmux, neovim, opencode, a local model — and now a full Alpine VM with Docker, this blog's dev server included:

<img width="540" height="602" alt="docker compose up of the blog frontend inside tmux on the Titan 2 Elite" src="/static/assets/titan_setup/05_docker_compose_up.png" />


A hands-on guide on turning the Titan 2 Elite into a real pocket dev machine with Termux, tmux, opencode, a local LLM and a full Alpine Linux VM under QEMU.

My Titan 2 Elite Advanced Setup: The Pocket Terminal Conversion

A hands-on experiment building a self-managed at-home AI cluster with k3s, Ollama, and LiteLLM.

Building a private LLM Cluster


<img width="1906" height="917" alt="OpenCode blog cover" src="/static/assets/opencode-blog-cover.png" />

[Opencode](https://opencode.ai/) is a pretty cool and neatly composable terminal based llm coding agent.
For a project at [tb-software](https://timschupp.de/) and also private personal use in general I'm especially interesting in the usage of open-code or similar tools with local llms, hosted on own hardware. See [my article on running and testing local llms on a 128gb strix halo setup here](https://blog.t1m.me/blog/local-llms-on-strix-halo-128gb-shared-ram).
This article will describe my personal setup as well as some hints how to manage it using a nix-flake - this functions more as future reference - than direct instructions. But it may help someone configure open-code for local llm usage.

### Configuring Open-Code

Just create a `opencode.json` like this:

```json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": { ... },
}
```
Then start adding your providers, fistly the local llm one, e.g.: you could use here [ollama]() though there are probaly some better and more performant options out there ( _these I still have to test again / with newer models_ ). But project like localai lammacpp, ... come to mind. Anything that host api compatible with the openai api schema really.

```json
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "ollama-local",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": { ... }
```
e.g.: to test the models from [my latest benchark](https://blog.t1m.me/blog/local-llms-on-strix-halo-128gb-shared-ram) i added. _Of course you will have to pull the models and corretly setup and start the local lmm server first ( check my other post for an example using ollama on vulkan + nix )._

```json
        "qwen3-coder-next": { "name": "qwen3-coder-next" },
        "mdq100/Qwen3-Coder-30B-A3B-Instruct:30b": { "name": "qwen-code-instuct-small"},
        "nemotron-3-nano": { "name": "nemotron-3-nano" },
        "glm-4.7-flash": { "name": "glm-4.7-flash" },
        "gpt-oss:120b": { "name": "gpt-oss:120b" }
```

<img width="1906" height="917" alt="OpenCode post starting prompt example" src="/static/assets/open-code-post-starting-prompt.png" />

### Usability / Review

As already stated in my benchmark post I was impressed by the performance and usability of the small llms, especially on small simple task like file editing, moving things around, manipulating issues, making simple commits and more. *So it is definitely somewhat hopeful that these open models do seems to perform for some use-case*; So I would say with care and good guardrails they can applied for certain tasks; especially when fully private data processing is required.

Also for the full potential of open-code and priming agents to be able to perform certain tasks in certain environments; you should definitely checkout and learn [how open-code mcps](https://opencode.ai/docs/mcp-servers/) and [agent skills](https://opencode.ai/docs/skills/) are set-up. I my experience the small local models perform best with easy; repeatable and easy to verify tasks - especially when given the right context clues and tools to use - but tasks that involve steps hard to statically automate ( e.g.: text based decision; complex semi autonomous task; browser use; search etc... ). Also it is possible to build in restrictive confirmation based tools for oversight.

### External Providers

Also if you want to use other remove non local providers to test oss models, you could add the following. _Note the api keys are taken from environment you don't need to include them in the config_.

#### 1. Deepinfra

```json
    "deepinfra": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "DeepInfra",
      "options": {
        "baseURL": "https://api.deepinfra.com/v1",
        "apiKeyEnv": "DEEPINFRA_API_KEY"
      },
      "models": { ... }
```

#### 2. groq

```json
    "groq": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Groq",
      "options": {
        "baseURL": "https://api.groq.com/openai/v1",
        "apiKeyEnv": "GROQ_API_KEY"
      },
      "models": { ... }
```

#### a complete config example

```json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3-coder-next": { "name": "qwen3-coder-next" },
        "mdq100/Qwen3-Coder-30B-A3B-Instruct:30b": { "name": "qwen-code-instuct-small"},
        "nemotron-3-nano": { "name": "nemotron-3-nano" },
        "glm-4.7-flash": { "name": "glm-4.7-flash" },
        "gpt-oss:120b": { "name": "gpt-oss:120b" }
      }
    },
    "deepinfra": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "DeepInfra",
      "options": {
        "baseURL": "https://api.deepinfra.com/v1",
        "apiKeyEnv": "DEEPINFRA_API_KEY"
      },
      "models": {
        "nvidia/Nemotron-3-Nano-30B-A3B": { "name": "nvidia/Nemotron-3-Nano-30B-A3B" },
        "moonshotai/Kimi-K2.5": { "name": "moonshotai/Kimi-K2.5" },
        "Qwen/Qwen3-235B-A22B-Instruct-2507": { "name": "Qwen/Qwen3-235B-A22B-Instruct-2507" },
        "MiniMaxAI/MiniMax-M2.5": { "name": "MiniMaxAI/MiniMax-M2.5" }
      }
    },
    "groq": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Groq",
      "options": {
        "baseURL": "https://api.groq.com/openai/v1",
        "apiKeyEnv": "GROQ_API_KEY"
      },
      "models": {
        "moonshotai/kimi-k2-instruct": { "name": "moonshotai/kimi-k2-instruct" },
        "qwen/qwen3-32b": { "name": "qwen/qwen3-32b" }
      }
    }
  }
}
```

### Managing a global open-code install via nix

<img width="1906" height="917" alt="OpenCode performing git push" src="/static/assets/open-code-performing-git-push.png" />

To mange my local open-code installation and configuration I've setup a simple nix flake, in a git sub-module that stores and pulls my open-code configuration and makes it globally available on configuration update.

```nix
{
  description = "Install opencode.json as a global OpenCode config";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };

  outputs = { self, nixpkgs }:
    let
      opencodeJsonPath = ./opencode.json;

      commonOptions = { lib, ... }:
        {
          options.opencodeOllamaLocalSetup = {
            enable = lib.mkOption {
              type = lib.types.bool;
              default = false;
              description = "Whether to install the OpenCode config file globally.";
            };
          };
        };

      nixosModule = { config, lib, ... }:
        let
          cfg = config.opencodeOllamaLocalSetup;
          defaultUsers = lib.attrNames (lib.filterAttrs (_: user:
            (user.isNormalUser or false) || ((user.uid or null) != null && user.uid >= 1000)
          ) config.users.users);
          targetUsers = if cfg.users == null then defaultUsers else cfg.users;
          existingUsers = lib.filter (name: lib.hasAttr name config.users.users) targetUsers;
          userRules = lib.concatLists (map (name:
            let
              user = config.users.users.${name};
              homeDir = user.home or "/home/${name}";
              groupName = user.group or name;
            in [
              "d ${homeDir}/.config/opencode 0700 ${name} ${groupName} -"
              "L+ ${homeDir}/.config/opencode/opencode.json - ${name} ${groupName} - ${opencodeJsonPath}"
            ]
          ) existingUsers);
        in
        {
          options.opencodeOllamaLocalSetup.users = lib.mkOption {
            type = lib.types.nullOr (lib.types.listOf lib.types.str);
            default = null;
            description = "Users to receive ~/.config/opencode/opencode.json (null = all normal users).";
          };

          config = lib.mkIf cfg.enable {
            systemd.tmpfiles.rules = userRules;
          };
        };

      homeManagerModule = { config, lib, ... }:
        let
          cfg = config.opencodeOllamaLocalSetup;
        in
        {
          config = lib.mkIf cfg.enable {
            xdg.configFile."opencode/opencode.json".source = opencodeJsonPath;
          };
        }
    in
    {
      nixosModules.default = { ... }: {
        imports = [ commonOptions nixosModule ];
      };
      homeManagerModules.default = { ... }: {
        imports = [ commonOptions homeManagerModule ];
      };
    }
}
```

<img width="1906" height="917" alt="OpenCode blog section edit example" src="/static/assets/opencode-blog-section-edit-example.png" />


Testing and configuring opencode for usage with local llms

Opencode; Usability with Local LLMs on iGPU w 128GB vram: My Tests


## Local LLMs on Strix Halo; [AMD Ryzen™ AI MAX+ 395](https://www.amd.com/en/blogs/2025/amd-ryzen-ai-max-395-processor-breakthrough-ai-.html) with 128GB Shared Ram: My Tests

LLMs are sometimes stupid, sometimes impressive, often unpredictable and almost never private.
Bigger models are generally hosted in clouds and proprietary, sometimes you can limit access or censor data presented to model providers but almost never you can restrict access fully or be really sure how and when your data is being used.

These are just some of the reasons why you might want to run models locally. But hardware especially graphics cards that can run these models are very pricey and the vram requirement for the more 'mid-range' models just exceeds what is possible with local models.

For some time Apple had an alternative to expensive graphics cards with their m-chip lineup allowing shared VRAM with integrated graphics and CPU, but the prices for higher RAM Mac configurations are still ridiculously high. 
But now there is a 'cheaper' option available for consumers. For a [tb-software](https://timschupp.de/) project I tested the highest available 128GB RAM configuration of a mini PC with the new strix-halo chip to test it and its ability for running local LLMs.

This article reports our early findings and summarizes some configuration steps and the measurement setup I used.
To this point I've tested 5 LLMs and more tests are coming. I also investigated the use and usability of local agents with OpenCode in a companion post: [Opencode; Usability with Local LLMs on iGPU w 128GB VRAM](https://blog.t1m.me/blog/opencode-with-local-llms).

### Setting up ollama with vulkan

First I needed to allocate VRAM to the integrated graphics card, I have not played with the 'dynamic' setting here yet. ( _I have now tried extending VRAM to 94GB more below_ )
For these tests I have chosen to set the VRAM to `65536 MiB` so there is about `67 GB` RAM still available to the CPU. We can also test influence on load speed and inference of varying the available amount of VRAM in the future.

<img width="1451" height="234" alt="Image" src="/static/assets/strix-halo-vram.png" />

Tests were run on NixOS and to access all the libraries required to use the Ollama Vulkan backend I had to install some additional packages and libraries, specifically I added `vulkan-loader` to the NixOS system libraries and ran Ollama with `OLLAMA_LLM_LIBRARY=vulkan OLLAMA_VULKAN=1 ollama serve`. I used `amdgpu_top` to monitor the VRAM and graphics usage ( _It feels like there are still some performance gains to be made, also VRAM is not fully utilized, especially by the smaller models_ ).

### The Test Setup

To test the LLMs for now I just wanted to know basic results for load speed and completion speeds.
I've created a simple fork of [ollama benchmark](https://github.com/aidatatools/ollama-benchmark) ( here [my fork without telemetry](https://github.com/tbscode/tims-ollama-bench-fork) ) to measure the results based on a running Ollama backend.

If you had the exact same hardware, system and configurations, tests could be replicated via:

```bash
python3 -m venv venv
source venv/bin/activate
pip install git+https://github.com/tbscode/tims-ollama-bench-fork.git
tims_llm_benchmark run --custombenchmark=<your-model-config>.yml
```

With models file:

```yaml
file_name: "<config-name>.yml"
version: 2.0.custom
models:
  - model: "<model-name>"
```

And run them all via

```bash
tims_llm_benchmark run --custombenchmark=model-configs/qwen3-coder-next.yaml
tims_llm_benchmark run --custombenchmark=model-configs/nemotron-3-nano.yaml
tims_llm_benchmark run --custombenchmark=model-configs/glm-4.7-flash.yaml
tims_llm_benchmark run --custombenchmark=model-configs/gpt-oss-120b.yaml
tims_llm_benchmark run --custombenchmark=model-configs/qwen-3.5-122b.yaml
```

<img width="1906" height="917" alt="Image" src="/static/assets/ollama-benchmark.png" />

### Test Results

Based on this benchmark and personal prompts and agents tests I've created this table to summarize the results.
There are many more tests to be done and likely also performance improvements through improved configuration, these are just my initial findings and a preliminary review. *But I can definitely say that there are functional local models out there that can definitely complete simple tasks locally on this hardware!*

| Name | Size (GB) | Quality | Load Speed | Tokens / sec |
|--|--|--|--|--|
| **qwen3-coder-next** | 61GB | 👾👾👾👾👾 | Fast | `35.094` |
| **nemotron-3-nano** | 34GB | 👾👾👾👾 | Very Fast | `63.566` |
| **glm-4.7-flash** | 40GB | 👾👾👾👾 | Slow | `50.098` |
| **gpt-oss:120b** | 70GB | 👾👾👾👾 | Very Slow | `31.532` |
| **qwen-3.5:122b** | 81GB | 👾👾👾👾 | Very Slow | `19.158` |
| **qwen-3.5:9b** | 6.6GB | 👾👾👾👾 | Very Slow | `29.52` |

All these models are usable for smaller and simpler local agentic and coding tasks, involving basic files manipulations and tool calls e.g.: via open-code. I was especially impressed by how well `qwen3-coder-next` performed, and also `nemotron-3-nano` that was incredibly fast and smart for such a small thinking model.

### Testing new qwen-3.5 with increased 94gb vram

Now I've updated the bios to allocate 94GB VRAM to allow larger models to run entirely in VRAM.

<img width="1451" height="234" alt="BIOS VRAM settings for 94GB allocation" src="/static/assets/strix_halo_increase_94gb_vram.png" />

Here's the active usage with 94GB VRAM allocated:

<img width="1906" height="917" alt="94GB VRAM active usage showing model loaded in VRAM" src="/static/assets/strix_halo_94gb_vram_active_usage_strix_halo.png" />

With the increased VRAM, I was able to download and run qwen-3.5:95b entirely in VRAM:

<img width="1451" height="917" alt="Downloading qwen-3.5:95b model with Ollama" src="/static/assets/ollama_downloading_qwen122b.png" />


Strix Halo 128GB RAM, 100% local LLM agents, my tests

Ollama

My Titan 2 Elite Advanced Setup: The Pocket Terminal Conversion

Building a private LLM Cluster

Opencode; Usability with Local LLMs on iGPU w 128GB vram: My Tests

Local LLMs on Strix Halo 128GB Shared Ram: My Tests