Model Recommendations

Local model recommendations / Lokale Modell-Empfehlungen

English · Deutsch

English

Model recommendations — when a release suggests a different local text model

The local text model. bastra models shows the local text model behind keyword expansion, reranking and the draft check, plus what this machine's RAM tier can carry (below 16 GB: none). bastra models set <tag> pulls a model and stores the choice in ~/.bastra/cli-settings.json; the environment variables BASTRA_EXPAND_MODEL / BASTRA_RERANK_MODEL override the stored choice. The embedding model is a separate thing (bastra embeddings) and is not touched by anything described here.

What a new install is offered, and what runs without a choice. These are two different things. The installer suggests tev1:4b (4.5 GB download) from 16 GB of RAM, offers gemma4:12b (8.1 GB) as the more accurate, slower alternative from 24 GB, and suggests gemma4:12b from 32 GB; it pulls and stores what you pick. That tev1:4b fits a 16 GB machine next to the embedding model is derived from its size — the comparison behind the suggestion ran on one 24 GB machine. An install that never stored a choice keeps running gemma3:4b, the built-in fallback, exactly as before: the new suggestion switches nothing on an existing install. It shows up there as the recommended: line of bastra models and as the recommendation described below. Where no recommendation is open, bastra models prints a to switch: hint under that line; it always names the model on the recommended: line, and where a tier has a heavier alternative, it follows on a line of its own, alternative:.

What a recommendation is. A release can carry a recommendation: per hardware tier (16 GB, 24 GB, 32 GB and up) a model, its download size, and one sentence on what gets better with that model. It ships inside the release, so showing it needs no additional network access. A release without a recommendation shows nothing and changes nothing.

The current recommendation. Since 1.1.0 the release carries one, named 2026-10-tev1:

RAM of the machine	Recommended model	Download	What the notice says gets better, compared with gemma3:4b
below 16 GB	none	–	–
16 GB to under 32 GB	tev1:4b	4.5 GB	fewer wrong verdicts in the draft check, much harder to steer with injected text, a more accurate reranker; similar draft-check/reranker answer times, but slower keyword expansion and more notes without phrases
32 GB and up	gemma4:12b	8.1 GB	fewer wrong verdicts in the draft check, harder to steer with injected text, a clearly more accurate reranker — at about three times the answer time

The numbers behind these sentences are in the local model comparison, measured against gemma3:4b on one 24 GB machine with invented data. The sentence compares with gemma3:4b, also when you run a custom model. If you already use any model named in the active recommendation, no automatic switch notice appears, regardless of the tier: a 24 GB install using gemma4:12b is not prompted to move to tev1:4b, and a 32 GB install using tev1:4b is not prompted to move to gemma4:12b. The comparison ignores letter case and accepts a tag starting with a listed tag followed by - (for example gemma4:12b-it-q4_K_M). Bare names, :latest, and other sizes do not count as that model. bastra models still shows the tier’s pick and a manual switch command. Keyword expansion took 1.5 s instead of 0.9 s with tev1:4b, and 16 of 180 notes received no phrases instead of 1; the similar answer times refer to the draft check and reranking.

Never switched automatically. bastra never changes your model on its own — not on update, not with update.mode auto, not through the agent. New installs are simply offered the recommended model by the installer. Existing installs are told, and the answer is yours.

When the notice appears. All of these have to hold:

• the installed release carries a recommendation, and it has an entry for this machine's tier;
• the machine is at or above the 16 GB tier (below it, no text model runs);
• a text model is in use on this install: Ollama is the embedding provider (only then does the daemon run trigger expansion, the draft check and the search copilot), or you set a text model up yourself — stored with bastra models set or pinned by environment variable — which bastra bridges harvest uses whatever the embedding provider is;
• the model in effect is not already any model named in the active recommendation;
• update notices are not switched off (see "Switching it off" below);
• you have not answered yet — or you answered later and 7 days have passed, or the release carries a new recommendation.

When it does not appear. If any of the points above fails. In particular: once a model of the active recommendation is in effect, after switch, after dismiss, and for 7 days after later. A model outside that set gets the notice even if you chose it yourself.

Where it appears. Five places, all reading one shared note of your answer in ~/.bastra/cli-settings.json, so an answer given in one place silences the others:

1. bastra update asks at the end. On a terminal it waits for one of three keys; without a terminal it only prints the notice and never waits.
2. The catch-up question. An update is run by the updater that was installed before it, and an updater from before this feature cannot ask. So the first bastra command you run on a terminal afterwards asks instead — after the command's own output, without changing its exit code, and once per recommendation. It does not ask when bastra update already asked, or when you already answered in the chat or on the command line. It never asks without a terminal on both ends (so not in pipes, scripts, hooks or background runs), and never after --json, --help, --version, bastra update, models, config, token, completion or uninstall. Enter, or anything it does not recognise, counts as later. Ctrl-C or end of input records no answer: the other places keep asking, the terminal does not ask a second time. An answer you gave elsewhere a moment earlier is never replaced by the question, and two commands finishing at the same moment ask once: the question is claimed under a lock on the settings file. If that lock cannot be had within a few seconds — another bastra process holds it, or one was interrupted and left it behind — nothing is asked and nothing is written; the question comes with the next command.
3. bastra models shows the recommendation at any time, also after you dismissed it.
4. The agent's session start carries the notice normally once per UTC calendar day per user, shared by Claude Code and Codex across all sessions, until you have answered. Its own marker is ~/.bastra/model-session-hint-shown.txt, independent of the CLI line: neither path suppresses the other. The day is marked only when the block is included in the prepared hook response. A fresh busy or inaccessible lock skips silently without waiting or marking. A lock older than about ten seconds gets one immediate takeover attempt; the day marker is checked under the lock before a block is inserted. If session starts simultaneously reclaim an orphaned lock, the notice can rarely appear twice on the same day. Like the CLI day marker, a new recommendation ID alone does not bypass that day's marker. The agent is instructed to tell you about it, name the download size and ask. It may run the commands below for you, but only after your explicit answer.
5. One dim line after CLI commands, on stderr, normally once per day — wherever the catch-up question does not apply. Parallel commands share the day claim. A day lock older than about ten seconds is reclaimed without waiting; if commands simultaneously reclaim an orphaned lock, the line can rarely appear twice. If the day lock is fresh or unwritable, it silently skips that call without waiting; session start, the update question and catch-up do not use that lock. Not after bastra update, models, config, token, completion, help and version. The UTC day changes at 01:00 or 02:00 local time in Central Europe, depending on daylight saving time; the CLI line and agent block use the same day boundary.

The three answers. Every notice prints the exact commands; they name the recommendation they answer (and, for a switch, the model):

bastra models switch <recommendation> <model>   # pull the recommended model, check it, then switch
bastra models later <recommendation>            # keep the current model, ask again in 7 days
bastra models dismiss <recommendation>          # keep it, never ask again for this recommendation

• switch — see "The safe switch" below. Afterwards nothing asks again for this recommendation.
• later — nothing changes; every place stays silent for 7 days and then reminds you (the session start and the dim line; the terminal question is not repeated).
• dismiss — nothing changes, and the notice does not come back for this recommendation. You may be giving up better recall quality. Every place that offers or confirms dismiss says so, and the agent tells you before it runs the command. bastra models keeps showing the recommendation, you can still switch later, and a later, new recommendation asks again.

All three work without a terminal.

An answer only counts for what you were shown. The commands carry the recommendation's name because the notice and the command can come from two different programs: a daemon that is still the previous version, and a command line that is already the new one. If the recommendation has changed in between, or the command names none, bastra refuses it, says what the current recommendation is, and changes nothing — a yes to one model never downloads another. For the same reason the answer does not depend on the shell it is typed in: if the recommended model happens to be pinned by an environment variable in your shell but not in the daemon, the answer is still recorded and the daemon stops asking.

The safe switch. bastra models switch … does these things in this order: it pulls the new model (skipped if it is already there), sends it one short real request, and only when that was answered stores the new model together with your answer — in one write, so there is never a new model without the answer or the reverse. The daemon reads the model at start, so restart it afterwards (bastra update restarts it, or restart your AI clients).

Which Ollama the switch talks to. Every request of the switch — is Ollama running, is the model there, the test request — goes to one address, worked out from BASTRA_OLLAMA_URL (default http://localhost:11434) before the first request is made. That address has to be on this machine, redirects are refused, and a query or fragment in the configured URL is left out. The switch is refused, without a single request, when the configured URL points to another machine, when it carries a user name or password (http://user:pass@host), or when it cannot be read as an http(s) URL. The refusal names at most the host — never the user name, the password, a token or the rest of the URL, in whatever spelling they were written — because what the command prints can end up in a chat transcript. In those cases bastra models set <tag> switches without the test request.

When something fails. If Ollama is not running, the pull fails or is interrupted, the test request fails or comes back empty, or the setting cannot be saved, the command prints the reason, exits with code 1 and changes nothing: your model stays as it was, and the question stays open. The same holds when ~/.bastra/cli-settings.json is not valid JSON, or is there but cannot be read (wrong permissions, for example): bastra refuses to write to it rather than replace your other settings with defaults — repair the file or its permissions first. The second case is not special to model decisions: a command that stores a setting reads the file once, changes exactly what it read, and does not write when that one read failed. A model answer or switch is also refused, with a message, when the lock on the settings file cannot be had (another bastra process holds it, or an interrupted one left it behind; it is taken over after about ten seconds) — nothing is written, and you can simply repeat the command.

Switching back. The old model is never deleted. After a switch the command prints the exact way back: bastra models set <previous tag>. Removing an unused model from disk is yours to do (ollama rm <tag>).

With BASTRA_EXPAND_MODEL or BASTRA_RERANK_MODEL set. You get the notice as well. It names the variable and says that it overrides the stored choice: a switch stores the new model, but the variable keeps winning until you remove it and restart the daemon. If the variable already names any model of the active recommendation, there is no notice. The agent's session-start notice shows your current model only when it is a plain model tag (letters, digits and . _ - : /); anything else appears as "a custom model", and the variable is named without its value.

Switching it off. BASTRA_UPDATE_CHECK=off silences the notice at the session start, after CLI commands (the catch-up question and the dim line) and at the end of bastra update; so does bastra config set update.mode off. bastra models dismiss <recommendation> silences one recommendation. bastra models always shows it, whatever is switched off.

Deutsch

Modell-Empfehlungen — wenn ein Release ein anderes lokales Textmodell vorschlägt

Das lokale Textmodell. bastra models zeigt das lokale Textmodell hinter Stichwort-Erweiterung, Nachsortierung und Entwurfs-Prüfung und dazu, was die RAM-Stufe dieser Maschine trägt (unter 16 GB: keines). bastra models set <tag> lädt ein Modell und speichert die Wahl in ~/.bastra/cli-settings.json; die Umgebungsvariablen BASTRA_EXPAND_MODEL / BASTRA_RERANK_MODEL überstimmen die gespeicherte Wahl. Das Einbettungsmodell ist etwas anderes (bastra embeddings) und bleibt von allem hier Beschriebenen unberührt.

Was eine Neuinstallation vorgeschlagen bekommt, und was ohne Wahl läuft. Das sind zwei verschiedene Dinge. Der Installer schlägt ab 16 GB RAM tev1:4b vor (4,5 GB Download), bietet ab 24 GB gemma4:12b (8,1 GB) als genauere, langsamere Alternative an und schlägt ab 32 GB gemma4:12b vor; er lädt und speichert, was du auswählst. Dass tev1:4b auf einen 16-GB-Rechner neben das Einbettungsmodell passt, ist aus seiner Größe abgeleitet — der Vergleich hinter dem Vorschlag lief auf einem einzelnen 24-GB-Rechner. Eine Installation, die nie eine Wahl gespeichert hat, läuft weiter mit gemma3:4b, dem eingebauten Rückfallwert, genau wie bisher: Der neue Vorschlag stellt an einer bestehenden Installation nichts um. Er zeigt sich dort als Zeile recommended: von bastra models und als die unten beschriebene Empfehlung. Wo keine Empfehlung offen ist, gibt bastra models unter dieser Zeile einen Hinweis to switch: aus; er nennt immer das Modell der Zeile recommended:, und hat eine Stufe eine größere Alternative, folgt sie in einer eigenen Zeile, alternative:.

Was eine Empfehlung ist. Ein Release kann eine Empfehlung mitbringen: je Hardware-Stufe (16 GB, 24 GB, ab 32 GB) ein Modell, dessen Downloadgröße und einen Satz dazu, was mit diesem Modell besser wird. Sie steckt im Release selbst, ihre Anzeige braucht also keinen zusätzlichen Netzzugriff. Ein Release ohne Empfehlung zeigt nichts und ändert nichts.

Die aktuelle Empfehlung. Seit 1.1.0 bringt das Release eine mit, sie heißt 2026-10-tev1:

RAM der Maschine	Empfohlenes Modell	Download	Was laut Hinweis besser wird, verglichen mit gemma3:4b
unter 16 GB	keines	–	–
16 GB bis unter 32 GB	tev1:4b	4,5 GB	weniger falsche Urteile in der Entwurfs-Prüfung, deutlich schwerer durch eingeschleusten Text zu lenken, eine genauere Nachsortierung; ähnliche Antwortzeiten bei Entwurfs-Prüfung/Nachsortierung, aber langsamere Stichwort-Erweiterung und mehr Notizen ohne Phrasen
ab 32 GB	gemma4:12b	8,1 GB	weniger falsche Urteile in der Entwurfs-Prüfung, schwerer durch eingeschleusten Text zu lenken, eine klar genauere Nachsortierung — bei etwa dreifacher Antwortzeit

Die Zahlen hinter diesen Sätzen stehen im Vergleich lokaler Modelle, gemessen gegen gemma3:4b auf einem einzelnen 24-GB-Rechner mit erfundenen Daten. Der Hinweis selbst erscheint auf Englisch. Der Satz vergleicht mit gemma3:4b, auch wenn bei dir ein eigenes Modell läuft. Wer bereits ein Modell der aktiven Empfehlung nutzt, bekommt unabhängig von der Stufe keinen automatischen Wechsel-Hinweis: Eine 24-GB-Installation mit gemma4:12b wird nicht zu tev1:4b aufgefordert, und eine 32-GB-Installation mit tev1:4b nicht zu gemma4:12b. Der Vergleich ignoriert Groß-/Kleinschreibung und akzeptiert einen Tag, der mit einem aufgeführten Tag und anschließend - beginnt (zum Beispiel gemma4:12b-it-q4_K_M). Bloße Namen, :latest und andere Größen zählen nicht als dieses Modell. bastra models zeigt den Vorschlag der Stufe und einen manuellen Wechselbefehl weiterhin. Die Stichwort-Erweiterung dauerte mit tev1:4b 1,5 statt 0,9 s, und 16 von 180 Notizen erhielten keine Phrasen statt 1; die ähnlichen Antwortzeiten beziehen sich auf Entwurfs-Prüfung und Nachsortierung.

Nie automatisch umgestellt. bastra wechselt dein Modell nie von sich aus — nicht beim Update, nicht mit update.mode auto, nicht über den Agenten. Neuinstallationen bekommen das empfohlene Modell einfach vom Installer vorgeschlagen. Bestehende Installationen werden informiert, und die Antwort gehört dir.

Wann der Hinweis erscheint. Alle diese Punkte müssen zutreffen:

• das installierte Release bringt eine Empfehlung mit, und sie hat einen Eintrag für die Stufe dieser Maschine;
• die Maschine liegt auf oder über der 16-GB-Stufe (darunter läuft kein Textmodell);
• auf dieser Installation wird ein Textmodell genutzt: Ollama ist der Embedding-Provider (nur dann führt der Daemon Stichwort-Erweiterung, Entwurfs-Prüfung und Such-Copilot aus), oder du hast selbst ein Textmodell eingerichtet — mit bastra models set gespeichert oder per Umgebungsvariable festgelegt —, das bastra bridges harvest unabhängig vom Embedding-Provider verwendet;
• das wirksame Modell ist nicht schon eines der Modelle der aktiven Empfehlung;
• Update-Hinweise sind nicht abgeschaltet (siehe „Abschalten“ unten);
• du hast noch nicht geantwortet — oder du hast later geantwortet und 7 Tage sind vergangen, oder das Release bringt eine neue Empfehlung mit.

Wann er nicht erscheint. Sobald einer der Punkte oben nicht zutrifft. Insbesondere: sobald ein Modell der aktiven Empfehlung wirksam ist, nach switch, nach dismiss und 7 Tage lang nach later. Ein Modell außerhalb dieses Satzes bekommt den Hinweis auch dann, wenn du es selbst gewählt hast.

Wo er erscheint. An fünf Stellen, die alle einen gemeinsamen Merkzettel deiner Antwort in ~/.bastra/cli-settings.json lesen — eine Antwort an einer Stelle lässt die anderen verstummen:

1. bastra update fragt am Ende. Im Terminal wartet es auf eine von drei Tasten; ohne Terminal gibt es nur den Hinweis aus und wartet nie.
2. Die Nachhol-Abfrage. Ein Update führt der Updater aus, der vorher installiert war, und ein Updater aus der Zeit vor dieser Funktion kann nicht fragen. Deshalb fragt stattdessen der erste bastra-Befehl, den du danach in einem Terminal ausführst — nach der eigenen Ausgabe des Befehls, ohne dessen Exit-Code zu ändern, und einmal je Empfehlung. Sie fragt nicht, wenn bastra update schon gefragt hat oder du im Chat oder auf der Kommandozeile schon geantwortet hast. Sie fragt nie ohne Terminal an beiden Enden (also nicht in Pipes, Skripten, Hooks oder Hintergrundläufen) und nie nach --json, --help, --version, bastra update, models, config, token, completion oder uninstall. Enter oder alles, was sie nicht erkennt, zählt als later. Strg-C oder Eingabeende merkt keine Antwort: Die anderen Stellen fragen weiter, das Terminal fragt kein zweites Mal. Eine Antwort, die du einen Moment vorher anderswo gegeben hast, wird von der Frage nie ersetzt, und zwei Befehle, die gleichzeitig fertig werden, fragen einmal: Der Anspruch auf die Frage wird unter einer Sperre auf die Einstellungsdatei vergeben. Ist diese Sperre binnen weniger Sekunden nicht zu bekommen — ein anderer bastra-Prozess hält sie, oder einer wurde abgebrochen und hat sie zurückgelassen —, wird nichts gefragt und nichts geschrieben; die Frage kommt beim nächsten Befehl.
3. bastra models zeigt die Empfehlung jederzeit, auch nachdem du sie abgestellt hast.
4. Der Sitzungsstart des Agenten trägt den Hinweis in der Regel einmal je UTC-Kalendertag und Nutzer, gemeinsam für Claude Code und Codex über alle Sitzungen, bis du geantwortet hast. Sein eigener Vermerk liegt in ~/.bastra/model-session-hint-shown.txt, unabhängig von der CLI-Zeile: Kein Weg unterdrückt den anderen. Der Tag wird nur vermerkt, wenn der Block in der vorbereiteten Hook-Antwort steht. Eine frische belegte oder unzugängliche Sperre wird still ohne Warten oder Vermerk übersprungen. Bei einer Sperre, die älter als etwa zehn Sekunden ist, erfolgt ein einziger sofortiger Übernahmeversuch; vor dem Einfügen des Blocks wird der Tagesvermerk unter der Sperre geprüft. Übernehmen Sitzungsstarts gleichzeitig eine verwaiste Sperre, kann der Hinweis selten am selben Tag zweimal erscheinen. Wie beim CLI-Tagesmerker umgeht eine neue Empfehlungs-ID allein den Vermerk desselben Tages nicht. Der Agent ist angewiesen, dir davon zu erzählen, die Downloadgröße zu nennen und zu fragen. Er darf die Befehle unten für dich ausführen, aber erst nach deiner ausdrücklichen Antwort.
5. Eine gedimmte Zeile nach CLI-Befehlen, auf stderr, normalerweise einmal am Tag — überall dort, wo die Nachhol-Abfrage nicht greift. Parallele Befehle teilen sich den Tagesmerker. Eine Tagessperre, die älter als etwa zehn Sekunden ist, wird ohne Warten übernommen; übernehmen Befehle gleichzeitig eine verwaiste Sperre, kann die Zeile selten zweimal erscheinen. Ist die Tagessperre frisch oder nicht schreibbar, entfällt dieser Aufruf still und ohne Warten; Sitzungsstart, Update-Frage und Nachhol-Abfrage verwenden diese Sperre nicht. Nicht nach bastra update, models, config, token, completion, help und version. Der UTC-Tag wechselt in Mitteleuropa je nach Sommerzeit um 01:00 oder 02:00 Ortszeit; Terminal-Zeile und Agenten-Block verwenden dieselbe Tagesgrenze.

Die drei Antworten. Jeder Hinweis gibt die genauen Befehle aus; sie nennen die Empfehlung, auf die sie antworten (und beim Wechsel das Modell):

bastra models switch <empfehlung> <modell>   # empfohlenes Modell laden, prüfen, dann umstellen
bastra models later <empfehlung>             # beim aktuellen Modell bleiben, in 7 Tagen erneut fragen
bastra models dismiss <empfehlung>           # dabei bleiben, für diese Empfehlung nie mehr fragen

• switch — siehe „Der sichere Wechsel“ unten. Danach fragt für diese Empfehlung nichts mehr.
• later — nichts ändert sich; alle Stellen schweigen 7 Tage und erinnern dich dann (der Sitzungsstart und die gedimmte Zeile; die Frage im Terminal wird nicht wiederholt).
• dismiss — nichts ändert sich, und der Hinweis kommt für diese Empfehlung nicht wieder. Du verzichtest damit möglicherweise auf bessere Recall-Qualität. Das steht überall, wo dismiss angeboten oder bestätigt wird, und der Agent sagt es dir, bevor er den Befehl ausführt. bastra models zeigt die Empfehlung weiterhin, du kannst später immer noch wechseln, und eine spätere, neue Empfehlung fragt wieder.

Alle drei funktionieren ohne Terminal.

Eine Antwort gilt nur für das, was dir gezeigt wurde. Die Befehle tragen den Namen der Empfehlung, weil Hinweis und Befehl von zwei verschiedenen Programmen kommen können: von einem Daemon, der noch die vorige Version ist, und einer Kommandozeile, die schon die neue ist. Hat sich die Empfehlung dazwischen geändert oder nennt der Befehl keine, lehnt bastra ihn ab, sagt, was die aktuelle Empfehlung ist, und ändert nichts — ein Ja zu einem Modell lädt nie ein anderes. Aus demselben Grund hängt die Antwort nicht von der Shell ab, in der sie getippt wird: Ist das empfohlene Modell zufällig in deiner Shell per Umgebungsvariable festgelegt, im Daemon aber nicht, wird die Antwort trotzdem gespeichert und der Daemon hört auf zu fragen.

Der sichere Wechsel. bastra models switch … tut diese Dinge in dieser Reihenfolge: Es lädt das neue Modell (entfällt, wenn es schon da ist), schickt ihm eine kurze echte Anfrage und speichert erst, wenn diese beantwortet wurde, das neue Modell zusammen mit deiner Antwort — in einem Schreibvorgang, sodass es nie ein neues Modell ohne die Antwort gibt oder umgekehrt. Der Daemon liest das Modell beim Start, danach also neu starten (bastra update startet ihn neu, oder du startest deine KI-Clients neu).

Mit welchem Ollama der Wechsel spricht. Jede Anfrage des Wechsels — läuft Ollama, ist das Modell da, die Testanfrage — geht an eine einzige Adresse, die vor der ersten Anfrage aus BASTRA_OLLAMA_URL (Standard http://localhost:11434) ermittelt wird. Diese Adresse muss auf diesem Rechner liegen, Weiterleitungen werden abgelehnt, und eine Query oder ein Fragment der konfigurierten URL bleibt weg. Der Wechsel wird ohne eine einzige Anfrage abgelehnt, wenn die konfigurierte URL auf einen anderen Rechner zeigt, wenn sie Benutzername oder Passwort trägt (http://user:pass@host) oder wenn sie sich nicht als http(s)-URL lesen lässt. Die Ablehnung nennt höchstens den Host — nie den Benutzernamen, das Passwort, ein Token oder den Rest der URL, in welcher Schreibweise auch immer sie eingetragen wurden —, weil die Ausgabe des Befehls in einem Chat-Verlauf landen kann. In diesen Fällen wechselt bastra models set <tag> ohne die Testanfrage.

Wenn etwas scheitert. Läuft Ollama nicht, scheitert das Laden oder wird es abgebrochen, scheitert die Testanfrage oder kommt leer zurück, oder lässt sich die Einstellung nicht speichern, gibt der Befehl den Grund aus, endet mit Code 1 und ändert nichts: Dein Modell bleibt, wie es war, und die Frage bleibt offen. Dasselbe gilt, wenn ~/.bastra/cli-settings.json kein gültiges JSON ist oder zwar da ist, aber nicht gelesen werden kann (falsche Rechte zum Beispiel): bastra schreibt dann nicht hinein, statt deine anderen Einstellungen durch Standardwerte zu ersetzen — repariere zuerst die Datei oder ihre Rechte. Der zweite Fall ist keine Besonderheit der Modell-Entscheidungen: Ein Befehl, der eine Einstellung speichert, liest die Datei einmal, ändert genau das Gelesene und schreibt nicht, wenn diese eine Lesung fehlgeschlagen ist. Eine Modell-Antwort oder ein Wechsel wird außerdem mit einer Meldung abgelehnt, wenn die Sperre auf die Einstellungsdatei nicht zu bekommen ist (ein anderer bastra-Prozess hält sie, oder ein abgebrochener hat sie zurückgelassen; nach etwa zehn Sekunden wird sie übernommen) — nichts wird geschrieben, und du kannst den Befehl einfach wiederholen.

Zurückwechseln. Das alte Modell wird nie gelöscht. Nach einem Wechsel gibt der Befehl den genauen Weg zurück aus: bastra models set <vorheriger tag>. Ein ungenutztes Modell von der Platte zu entfernen ist deine Sache (ollama rm <tag>).

Mit gesetztem BASTRA_EXPAND_MODEL oder BASTRA_RERANK_MODEL. Du bekommst den Hinweis ebenfalls. Er nennt die Variable und sagt, dass sie die gespeicherte Wahl überstimmt: ein Wechsel speichert das neue Modell, aber die Variable gewinnt weiter, bis du sie entfernst und den Daemon neu startest. Nennt die Variable bereits ein Modell der aktiven Empfehlung, gibt es keinen Hinweis. Der Hinweis beim Sitzungsstart des Agenten zeigt dein aktuelles Modell nur, wenn es ein schlichter Modell-Tag ist (Buchstaben, Ziffern und . _ - : /); alles andere erscheint als „a custom model“, und die Variable wird ohne ihren Wert genannt.

Abschalten. BASTRA_UPDATE_CHECK=off lässt den Hinweis beim Sitzungsstart, nach CLI-Befehlen (Nachhol-Abfrage und gedimmte Zeile) und am Ende von bastra update verstummen; bastra config set update.mode off ebenso. bastra models dismiss <empfehlung> stellt eine einzelne Empfehlung ab. bastra models zeigt sie immer, egal was abgeschaltet ist.