
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


Hello everybody.

Some of you might know [this video here from two something years ago](https://www.youtube.com/watch?v=OqT_kIhz8Dc), where I presented the concept for 'open-chat' and said: *"So I'm only developing on this project in my free time and cannot make any promises on the development speed, but I'm very motivated to help bringing out stuff that lets us run models locally."*

Well, it was quite silent since then - except for maybe some heard that I shut down the original [beta.msgmate.io](https://msgmate.io) due to time constraints - now today I'm finally back with a *serious update*.

In my free time I've fully re-written [open-chat](https://github.com/msgmate-io/open-chat-go) in Go lang, especially to prepare for portability, cross-device compatibility and scalability.

So now open-chat is everything that I need, that you as a product "AI" user / developer may need, that a company rolling out "AI" products to their employees needs - and anything I ever wanted in an actual "AI" orchestration tool, while being fully sovereign, private and self-hostable. Fully self-controlled "AI" orchestration for you.

Open-chat bundles all the functions and strives to be able to do anything any other fancy LLM provider online chat interface or local Codex app or Claude app can do - *while being different*: open-chat is local-first, open-chat is multi-user first, open-chat is control and sandbox integration by itself, open-chat has built-in governance, built-in automation and is an orchestration tool at once. This sort of tool never existed in my opinion - so I created it.

And I want to offer it to everybody. Of course such a tool and such an application is highly complex, but bit by bit I think I'll be able to make this accessible to anyone. Open-chat is fully extensible, it may compile in custom integrations, and you can of course also develop your own private integrations.

I've designed open-chat in such a way that it fulfills any criteria that any OSS tool has missed for me. I've tested a lot of them - ask my friends, I was switching "AI" and automation tools every 3 days. They all somewhat work and of course have their use case and niche, but there were always some things that my software architecture / DevOps / platform engineering mind was missing. So I kind of re-thought the concept and created what I think is the right solution here.

In my opinion such a tool has to be a platform, an "AI" orchestration tool and an "AI" runtime - but it may never contain any external services or binaries. It shall only interface with any other tool, application, app or service.

The tool itself MUST BE PORTABLE, IT MUST BE COMPOSABLE, IT MUST BE SELF-HOSTABLE, and it must not ever write any custom client code - the clients must always be derived and generated from the back-end API specification. Yeah, I know, strict rules - but these come with a lot of power: if the tool orchestrates, ports and builds itself, it may *evolve itself*. And we can already see that with open-chat actually now developing itself in its own code base, using open-chat.

That's just a taste of the possibilities. For example, see how easy it is to set up an [MCP](https://modelcontextprotocol.io) connection to a Google Workspace with three clicks - and suddenly your local LLM at home can search, edit and work on your Google files fully privately (well, Google has the data, of course). I've tested this, it definitely works - I've hosted and deployed open-source models on [my private cluster](https://blog.t1m.me/blog/building-own-private-kuberntes-ai-cluster) and tested open-chat with it. And if you want to read my comment on the state of open-source "AI", [read this blog article](https://blog.t1m.me/blog/commoditization-of-ai-local-ai-and-the-future-of-europe). All of this works without any US big tech, OpenAI or Anthropic shenanigans - just with the mini PC in your own basement.

You can connect any MCP - for example throw in [Playwright](https://playwright.dev) and start controlling your browser sandboxes with any model. This ain't limited to anything, really.

Open-chat is already taking over development. Open-chat has voice input, open-chat can do image processing - and any imaginable thing that can be done out there with some open-source model can be integrated with open-chat.

Open-chat itself orchestrates its own sandboxes with Docker or Kubernetes (or any other backend we add in the future). It allows for full access control definition for any multi-user account, fine-grained tool confirmations, executions and scopings, and it has a full async runtime with its own workers that is horizontally scalable - the distribution is directly built in. It's designed to be extensible and efficient from the ground up, and it's still a tiny binary.

For now it will be really hard to grasp what it is, but as I release more and more demos and benchmarks and announce the first company integrations (already some in the making here), things will become more clear.

For now the most important thing is that you get an idea and I get the message out there: I think having good sovereign "AI" infrastructure in Europe will be an important game changer for us - and that is what I want to contribute to.

For now open-chat's core is released under AGPL, and there are several closed-source optional integrations at the moment. Depending on requests and reception of this release, I'm planning to open-source more and more of them.

Open-chat itself is also cross-platform from the ground up. An Android app is already in the making - and contrary to any other LLM tool, the app will actually include the full server, so once local LLMs become feasible you'll be able to take all your workflows directly onto your phone. iOS is also in the making, so no worries there.

I seriously believe such a tool has massive potential, especially because it solves several access-right management and orchestration issues that I didn't really see solved anywhere else - or at least not in non-proprietary software.

And I'm very confident that the negative impact of LLMs on code quality, or for coding in general, is very controllable by introducing error-correcting tests, having good CIs, having benchmarks, having human oversight, having self-healing deployments, and so on. I'm actively rolling out these parts in my workflows already, and I'll also be publishing more and more benchmarks, tests and results.

At some point open-chat / [msgmate](https://msgmate.io) will also release its own benchmarking. I'm already testing all the open-source LLMs on all the pre-existing workflows that work, so I can verify whether any future model - or any smaller model - will also work. My aim is to provide a state-of-the-art overview of open-source LLM capabilities, and to analyze them by energy consumption, intelligence, token usage, memory usage and speed - and hopefully show how fast and when we can use open-source LLMs in which use case.

Many things said here - many things I will have to show over the next months and years. Still, my time to work on open-chat is quite limited, but depending on the interest and reception of the first release I'll make sure that development efforts can also be scaled.

I'm also very curious about possible collaborations or contracts on integrations, pilots, or from people that just want to use the tool. I'll happily offer development and integration services alongside possible talks about custom development of integrations or custom licensing for companies.

Contact me for an initial talk: tim@timschupp.de

Anyways, let's see where this goes - [check out open-chat today](https://github.com/msgmate-io/open-chat-go). Thanks for listening.

Cheers Tim


Open-chat is a portable, composable, self-hostable platform for sovereign, private and self-controlled 'AI' — now released under AGPL.

Announcing Open-Chat: A Sovereign, Local-First 'AI' Platform


> **Note on terms:** I use KI (German) and AI interchangeably at the start; from here on I keep 'AI' in quotes. Everything below is my personal opinion and could well be wrong.

Shenanigans from OpenAI and Anthropic are ever present - *in my opinion more desperation, than anything else*.
But in my opinion *the commoditization of 'AI' has started* - and it will be fast from here.

### Always an early adopter

When it comes to technology I was *always an early adopter*, [I've even kinda predicted the relevance of harnesses when I started open-chat 3 years ago](https://www.youtube.com/watch?v=OqT_kIhz8Dc).
I've used LLMs from the start, few people knew that I was even checking out GPT-2 before the public release of GPT-3.

Since I was young I've been very interested and intrigued by ML systems or generally the thought to create something 'intelligent' that could become lively even possibly.
In my mind this is something that humans would naturally try to create - *this is not a rating - I'm not saying this is a good thing*.

I've been experimenting with 'AI' programming for a while, I've tried all hyped tools, I've even played with ['aider'](https://aider.chat/) before agentic coding really became a thing.
*The twist here isn't the 'AI' models -> It is their general agentic capability + some coding knowledge*.

At the moment though I believe *'AI' is a net negative for humanity so-far* - the cat is out of the bag argument is hard to get rid of.
But I think there is a *better way to use this technology*. This better way are 'local models'.

### A better way: local models

It gives, and takes little:

- Full privacy achievable through local hardware
- DSGVO compatible European hosters popping up everywhere
- Post-alignment and fine-tuning allows custom use-case models (in the past only through provider APIs possible)
- Sovereignty from the US
- Small model training and distillation flourishes

And many more advantages, esp that possibly we have these models simply running on our own devices and we can control how they think and act.

### The threshold is finally passed

I think the threshold is finally passed.
[After running Qwen3.8](https://blog.t1m.me/blog/vllm-litellm-on-amd-strix-halo) I've now moved to using qwen3.8-next-flash (new post on this soon) this runs directly on my cluster.
My results after literally switching 100% to OSS LLMs in coding for over 2 weeks now - *I'm never going back* - are that HELL YES THEY ARE GOOD ENOUGH FOR SURE!

### The pricing and value proposition

And then if you just take a look at the pricing differences then, *you realize fast* -
if the business case from US tech companies relies *on us using their compute in their datacenters* -
somebody has to make sure there is enough value to actually use them there.
*I strongly believe this value proposition isn't working out at the moment*.

### A less dystopian path for Europe

To me all of this gives some 'hope' at least that Europe will be fine, and that *there might still be a 'less dystopian path' for the global 'AI' rollout*.
But we will see :) Anyways *things could also be made or broken with the mid-term elections in the USA*.

Anyways, I'll be using only OSS models in all my private workflows from now on!
I'll report further; but you can already see open-chat is taking over development currently, with a fully automated agent starting to make more and more changes and commits in [open-chat-go](https://github.com/msgmate-io/open-chat-go).

More on open-chat soon too — it is becoming a *seriously helpful tool*.

Cheers Tim

<p class="post-image-grid-caption">Some insights on open-chat working in its own code-base.</p>

<div class="post-image-grid">
  <img width="2114" height="908" alt="Open-chat user automation overview" src="/static/assets/commoditization_post/open-chat-coding-user-automation-overview.png" />
  <img width="1555" height="1015" alt="Open-chat coding agent running on OSS LLMs" src="/static/assets/commoditization_post/open-chat-coding-agent-oss-llms.png" />
  <img width="1483" height="982" alt="Open-chat coding contributions" src="/static/assets/commoditization_post/open-chat-coding-contributions.png" />
  <img width="1531" height="1268" alt="Open-chat benchmark summary overview" src="/static/assets/commoditization_post/open-chat-benchmark-summary-overview.png" />
</div>


Why I think the commoditization of 'AI' has started, how local and open-source models change the equation, and what that could mean for Europe.

The Commoditization of AI, Local AI and the Future of Europe

Serving Qwen3.8-27B (INT4 AWQ) and Qwen3-4B (FP16) with vLLM on my two-node k3s cluster, fronted by a LiteLLM OpenAI-compatible router.

vLLM + LiteLLM on AMD Strix Halo

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

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


I have been testing several "Agentic" code editors to understand their current capabilities and limitations. This article compares **Antigravity** (Google), **Cursor** (Anysphere), **Windsurf**, and the open-source combination of **VSCodium + Continue**.

## The Contenders

### Antigravity (Google)
Antigravity is Google's entry into the agentic coding space, leveraging their compute and model capabilities. It integrates well for complex, multi-step reasoning tasks.

**Notes:**
- **Pricing:** No official pricing model exists yet.
- **Rate Limits:** The current rate limits are low and can interrupt workflow during intensive sessions.

![Antigravity Screenshot](/static/assets/agentic_editors/antigravity_screenshot.png)

### Cursor
Cursor is a fork of VS Code built by Anysphere. It includes a "Cursor Tab" feature for predictive edits.

**Cloud Agents:**
Cursor's agents operate in a sandboxed cloud environment. They can execute terminal commands, edit files, and create/refine Pull Requests. This is useful for repetitive, dynamic tasks. For example, I used it to integrate new automatic emails for **Little World**, where the agent edited configuration files across multiple locations and restructured code, replacing a previously manual process.

**Pricing:**
The Pro plan costs approximately **€20/month**. However, it includes a limited number of "fast" agent edits; exceeding this limit results in throttling or requires purchasing usage tokens.

![Cursor Screenshot](/static/assets/agentic_editors/cursor_screenshot.png)

### Windsurf
Windsurf is another editor in this space, emphasizing a "Flow" state. Some of the original engineers behind Windsurf are now employed at Google.

### Codium + Continue
For a fully open-source stack, **VSCodium** (a telemetry-free VS Code build) combined with the **Continue** extension allows the use of own models (e.g., Claude 3.5 Sonnet, GPT-4o) while maintaining data control.

![Codium Screenshot](/static/assets/agentic_editors/codium_screenshot.png)

**Trade-offs:**
- **Privacy:** No telemetry or data egress without explicit configuration.
- **Usability:** Major vendors (like Microsoft) do not support non-official builds. Proprietary extensions like Pylance/Pylint are often disabled or broken, requiring workarounds.

[Read my guide on setting up Codium + Continue here](https://timschupp.de/blog/self-hosted-ai-code-editing)

## Verdict

These tools are useful for specific workflows, particularly repetitive tasks involving consistent steps (e.g., adding a database field, updating the API, and modifying the frontend).

### Reality Check

They are not perfect. In my experience, they produce a significant amount of incorrect output. My acceptance rate is approximately **20-30%** of the suggested code. Even accepted code often requires rewriting to match specific requirements. They function as assistants, not replacements.

## Python Tooling Note

The official **Pylint extension for VS Code is proprietary** (part of the Pylance/Python bundle) and is disabled on non-official IDEs like VSCodium.

If using an editor other than the official VS Code or Cursor, I recommend **[basedpyright](https://github.com/DetachHead/basedpyright)** as an open-source alternative.


A comparison of Antigravity, Cursor, Windsurf, and Codium + Continue for agentic coding tasks.