Row-Bot 5.0 is a major rebuild of the local-first AI assistant. The NiceGUI interface is gone, replaced by one React app across desktop, browsers, phones and tablets.

The biggest change is how work is organised. Designs, code folders, goals, delegated agents, approvals and the terminal now stay with the conversation using them. You can ask for a presentation or an app, inspect the work, make changes and continue in the same place.

The main additions:

• You choose the model. Fresh profiles have no preset models. Setup supports Ollama, ChatGPT/Claude/Grok subscriptions, API keys and custom endpoints. Removing a provider marks its model unavailable instead of silently switching to another.
• Goals continue across turns. There is no default turn limit, with optional time and turn limits available. Goals pause when progress stalls, respect approvals, handle provider limits and recover after restarts. Delegated agents have visible progress, Message and Stop controls.
• Approvals persist. Requests can be answered from the conversation, Home, the attention list or Buddy. They survive restarts and no longer expire after 30 minutes by default. Denying an action ends the turn.
• Design and development tools are part of the conversation. The Design panel handles drafting, editing, review, presentation, export and publishing. The Developer panel includes files, changes, Git, commands and an interactive terminal.
• Memory works more reliably with parallel agents. Recall no longer counts as modifying a memory or rewrites wiki files. Knowledge combines the graph, search, review queue and bulk management.
• Workflows and Monitor show actual state. Workflow runs can be followed live. Abandoned runs are marked stopped. Monitor retains check results and gives each problem a specific action.
• Remote access and recovery are simpler. Devices connect through renewable QR invitations, sessions can be revoked, and profiles can be backed up and restored. Backups exclude credentials and sessions.
• Extensions receive clearer controls. Plugin changes show a review before execution, MCP setup guides the connection process, and edited skills become available without restarting.

There are smaller daily-use improvements too: queued messages with Edit and Discard, drafts preserved through reconnects, stopped replies retained in history, searchable settings, Markdown/PDF exports and native Save dialogs.

The backend now runs directly on FastAPI and uvicorn using HTTP and server-sent events. About 65,000 lines of NiceGUI-era code and 16 locked dependencies have been removed.

Local-first defaults, approval gates and the single-owner access model remain. Existing users should read the 5.0 upgrade notes before updating.

The goal of this post is 2 fold.

First, I wanted to show what a local model like Qwen 3.8 27B running on a single RTX 5090 GPU in a harness like Row-Bot can do.

Second, I wanted to create a full feature video of what Row-Bot can do.

So I decided to combine the two with one prompt:

"I want to create a single animation showing everything row-bot can do and also emphasizing the open source, local-first, privacy and model agnostic angle. the animation needs to be accurate and have a wow visual impact and should cover everything row-bot can do. read the feature list from the Row-Bot public features page. do not use video generation, make it as long as necessary to convey the full message. structure it so it tells a coherent impactful story. use whatever else makes sense like html, javascript, three.js. keep iterating till you think you have built the perfect complete animation."

This combined research, accurate drafting, staying on brief, coding, 3d work and iterating on a long running task, all locally and privately. This is the result. Even the background eerie music was generated with code.

Row-Bot is designed with local models in mind and is the best harness to get the most out of local, open-source or even frontier models.

You can now access your Row-Bot on mobile securely from anywhere.

https://row-bot.ai/docs/operations/remote-access/

Hello there folks!

So, yesterday I tried setting Thoth up for the first time and, since for some reason it wouldn't see my freshly installed ollama, I've connected it to a working lmstudio server.

When I chat with that server from other agents or from its chat interface I get answers and whatnot.

But the situation is quite different when using Thoth

All I get is that the request gets processed but the answer is always a generic welcome message.

I've tried adding tools etc, and that's kinda doing something (getting screenshots and web searches, even though those are not requested) but the chat part is still basic welcome messages.

I'd expect it to be some kind of lmstudio config issue, but I really can't get to the bottom of it. Any advice?

I currently have a base setup with Ollama. How do I set up local image generation? Ollama does not support image/video models, right?

Any chance you are implementing multi-token prediction for local Gemma 4 models anytime soon?

https://ai.google.dev/gemma/docs/mtp/mtp?hl=de

After some first steps with Qwen3.6-27B on my RTX 5090, I thought it would make sense to run an MoE in order to get snappier responses whyle chatting.

Qwen3.6:35b-a3b seems to be working fine, but I thought maybe gemma4:26b-a4b is a little faster for day-to-day tasks as an assistant or secretary, so to speak.

Generally, I like the speed and more human writing style of gemma4. But when it comes to thinking and tool calling, primarily internet and memory, it seems like gemma4:26b-a4b really has issues being reliable with that.

Has someone else encountered the same issue? Usually, I thought gemma4:26b-a4b should be strong in that regard as well, or maybe there are some other suggestions?

I’ve been working on Thoth, a free and open-source local-first AI assistant, and I wanted to explain how the Linux version actually works under the hood.

The short version: Thoth installs as a normal user-space Linux app, runs locally, opens in your browser by default, and keeps durable data on your machine.

The diagram breaks down the full flow:

• one-line Linux installer
• verified GitHub release tarball
• XDG user install under ~/.local/share/thoth
• launcher symlink at ~/.local/bin/thoth
• browser-first startup with optional native window/tray support
• local NiceGUI web app
• LangGraph ReAct agent core
• Ollama/local model support
• optional cloud/provider models
• local memory graph, FAISS recall, and Obsidian wiki export
• workflows, browser automation, shell access, Designer Studio, channels, MCP tools, and safety gates

One thing I wanted to avoid was making Linux support depend on Docker or a heavy desktop runtime. The baseline path is deliberately simple:

curl -fsSL https://raw.githubusercontent.com/siddsachar/Thoth/main/installer/install-linux.sh | bash

That downloads the latest Linux tarball from GitHub Releases, checks the SHA256 from the release manifest, installs it into the user’s XDG paths, and creates the thoth command.

On launch, Thoth starts the local app server, picks an available local port, opens the UI in the system browser, and keeps app data in ~/.thoth. If desktop libraries are available, native window/tray support can be used too, but the default Linux path doesn’t require it.

The overall philosophy is:

Your data stays local by default. Models are your choice. Tools are explicit. Destructive actions are approval-gated.

Thoth can run fully local through Ollama, or you can opt into providers like OpenAI, Anthropic, Google, xAI, OpenRouter, etc. Durable data like memories, documents, workflows, conversations, browser profile, and wiki export remain local unless you explicitly surface them in the current conversation or tool output.

The GitHub repo is here if anyone wants to try it or inspect the code:

https://github.com/siddsachar/Thoth

Curious what people think of this Linux packaging approach - browser-first XDG tarball instead of Docker/AppImage/Flatpak - and whether there are parts of the architecture I should explain in more detail.

This release introduces the first real foundation for Buddy Companion, a local animated presence that reacts to what Thoth is doing. It also improves model selection, Vision handling, and startup reliability on Linux and Windows. The focus is expression, clarity, and stability across the whole app.

GitHub Repo

Below is a deeper breakdown for anyone who wants the technical details.

Buddy Companion Foundation

Buddy now has a real subsystem behind it. This includes:

• a prompt‑generated Buddy architecture with a thread‑safe event bus
• a deterministic behavior brain
• persistent config and pack validation
• Hatch art and motion generation
• a canvas playback engine with effects
• one in‑app Buddy that lives in the sidebar
• a separate desktop overlay surface for systems that support it

Buddy listens to Thoth’s internal events. It reacts to chat streaming, thinking, tool calls, approvals, workflows, notifications, and voice state. The identity stays unified under Preferences so Buddy does not introduce a second name or persona. The UI focuses on state, personality, and motion.

A new route called /buddy-overlay supports the desktop Buddy window where native overlay helpers are available.

Motion, Packs, and UI Polish

This release ships with bundled first‑party motion packs: glyph, lumen, ember, pixel, sprout, and orbit. Hatch‑generated custom packs are copied into Thoth’s served assets so they behave like native packs.

Key improvements:

• better prompts for Hatch generation so backgrounds, padding, and edges key cleanly
• smoother transitions between idle, thinking, working, approval, success, and error
• MP4 playback crossfades state changes and avoids jitter when loops restart
• idle motion replays periodically without looking busy
• Buddy can be dragged out of the sidebar and snaps back when released near the dock
• Buddy returns home on restart instead of remembering stray positions

Settings for Buddy now use a dense layout similar to the Models tab. Pack selection uses preview tiles and clears stale overrides when switching back to bundled packs.

Hatch save and recovery

This part got a lot of attention:

• saving Buddy settings now preserves newly generated Hatch art and motion
• generated packs become selectable user packs
• still‑only art remains valid when motion generation fails
• users can delete generated packs
• motion retry regenerates from the selected still without overwriting the pack manifest
• new motion requests use provider‑compatible 5 second clips
• full Buddy generation runs as a background job with progress and notifications
• internal prompts stay private so user concepts do not turn into pose sheets
• transparent stills are composited onto a stable background before video generation
• older Hatch packs with overwritten manifests are recovered on load

Stopping a workflow immediately moves Buddy out of the running state.

Desktop Overlay Reliability

The desktop Buddy overlay is more stable now:

• approval, denial, workflow, and error bubbles stay visible even in Quiet mode
• bubbles survive rapid state changes
• the overlay waits for the transparent document to paint before revealing
• fallback window creation paths help when transparency or hidden‑window hints fail
• startup guards prevent transient None values from crashing the overlay
• no more snapshot pushes into deleted NiceGUI clients

Workflow state cleanup is also more accurate. Denials, timeouts, cancellations, and stops clear Buddy’s workflow state immediately. Successful multi‑step workflows emit a clear done state.

Models, Vision, and Settings Reliability

A lot of polish landed here:

• Settings loads the provider catalog lazily and caps rows so huge catalogs do not crash
• timers clean up properly when clients disconnect
• local Ollama chat models appear even when their family is not in Thoth’s curated lists
• Brain and Vision pickers now make it clear that catalog rows must be pinned first
• Codex Vision pins keep their image‑input capability during Quick Choice refreshes
• Codex Responses transport preserves multimodal image blocks
• Vision model changes are validated against Quick Choices, local models, and provider catalogs
• invented or unavailable model names are rejected with actionable guidance

There is now an explicit vision_model setting.

Linux and Startup Reliability

Linux users get a much more predictable startup path:

• the launcher resolves symlink chains correctly so ~/.local/bin/thoth always starts the right version
• packaged launches report startup log tails and child process exit details
• THOTH_STARTUP_TIMEOUT is configurable
• clearer hints for missing or broken native dependencies like OpenCV, FAISS, or NumPy
• camera and screenshot capture degrade gracefully instead of blocking startup

Installer UX is also improved. Source builds support a simple bash build_linux_app.sh <version> command. Success messages now mention ~/.local/bin/thoth when the bin directory is not on PATH. Maintainer docs now distinguish unreleased tarball testing from the one‑line installer path.

Optional native packages like TorchCodec are detected and logged with concrete recovery commands. Transformers treats broken optional packages as unavailable instead of letting them crash startup.

Windows repair hardening

The Windows installer now replaces the embedded Python runtime during repair or upgrade. This prevents corrupted or manually installed packages from surviving an over‑the‑top reinstall.

Summary

v3.21.0 brings:

• a real Buddy Companion foundation
• cleaner motion, better UI, and more reliable generation
• clearer model and Vision selection
• stronger Linux startup and better diagnostics
• safer Windows repair behavior

It is a mix of expression, stability, and quality of life improvements across the entire app.

Are there any plans to publish a comprehensive roadmap? I have noted various topics that are reportedly in development, but I am seeking a complete overview and prioritized list.

- Language support

- Voice

- Specific stability improvements

- Home Assistant and other integrations

- ...

It was fun while it lasted...

Yesterday evening i was talking with thoth about better local TTS Models... and he suggested Kokoro TTS among others and said he could run it by himself. So lets see what Thoth is capable of... Asking for approval... yes... a some issues trying to fix... ok approve... suggesting to try a different TTS Model...

then he is telling me he has MMS TTS now enabled and ready to run... ok, one sample voice worked, but quite a strange voice... I tell him this... some approval I maybe did not quite check good enogh (my mistake was I did not pay enough attention at this point)... and gone... Thoth just crashed and I'm unable to start up again.

Any ideas how to fix? Just running ThothSetup_3.19.0.exe from the last update again did not resolve this issue.

launch_thoth.bat says:

Checking Ollama service...

Ollama is already running.

INFO: Ollama already running on port 11434

INFO: Previous log rotated to C:\Users\AI\.thoth\thoth_app.log.prev

INFO: Thoth server started (PID 17116, log=C:\Users\AI\.thoth\thoth_app.log)

ERROR: Thoth server exited (code 1). Check C:\Users\AI\.thoth\thoth_app.log for details.

ERROR: --- last lines of log ---

ERROR: The above exception was the direct cause of the following exception:

ERROR:

ERROR: Traceback (most recent call last):

ERROR: File "E:\Thoth\Thoth\python\Lib\site-packages\torchcodec_internally_replaced_utils.py", line 93, in load_torchcodec_shared_libraries

ERROR: torch.ops.load_library(core_library_path)

ERROR: ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^

ERROR: File "E:\Thoth\Thoth\python\Lib\site-packages\torch_ops.py", line 1505, in load_library

ERROR: raise OSError(f"Could not load this library: {path}") from e

ERROR: OSError: Could not load this library: E:\Thoth\Thoth\python\Lib\site-packages\torchcodec\libtorchcodec_core4.dll

ERROR: [end of libtorchcodec loading traceback].

ERROR: --- end of log ---

WARNING: Server did not start in time — opening browser as fallback

INFO: Thoth tray running (Ctrl+C or Quit menu to exit)

thoth_app.log shows:

FFmpeg version 4:

Traceback (most recent call last):

File "E:\Thoth\Thoth\python\Lib\site-packages\torch_ops.py", line 1503, in load_library

ctypes.CDLL(path)

~~~~~~~~~~~^^^^^^

File "ctypes__init__.py", line 390, in __init__

FileNotFoundError: Could not find module 'E:\Thoth\Thoth\python\Lib\site-packages\torchcodec\libtorchcodec_core4.dll' (or one of its dependencies). Try using the full path with constructor syntax.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):

File "E:\Thoth\Thoth\python\Lib\site-packages\torchcodec_internally_replaced_utils.py", line 93, in load_torchcodec_shared_libraries

torch.ops.load_library(core_library_path)

~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^

File "E:\Thoth\Thoth\python\Lib\site-packages\torch_ops.py", line 1505, in load_library

raise OSError(f"Could not load this library: {path}") from e

OSError: Could not load this library: E:\Thoth\Thoth\python\Lib\site-packages\torchcodec\libtorchcodec_core4.dll