Übersicht
Was gerade läuft, was wartet, was es kostet. Alles Weitere links.
Grenzen
lädt…
Zuletzt gelaufen
Womit gearbeitet wird
Was ansteht
Braucht Aufmerksamkeit
Auftrag erteilen
Ein Auftrag wird geplant, umgesetzt, getestet und geprüft — in dieser Reihenfolge, jedes Mal.
Auftrag erteilen
Dateien hierher ziehen, einfügen (Strg+V) oder auswählen
Eine
.md wird zusätzlich als
Spezifikation eingelesen — danach findet die Suche ihre Kapitel.
Bilder liegen im Lauf unter anhang/ bereit.
Live
noch keine Ereignisse
Letzte Runs
| Status | Branch | Run | Zeit |
|---|
Backlog
Jedes Projekt in Teilaufgaben zerlegt, nach Wichtigkeit sortiert, mit Fortschritt. Was das Modell vorschlägt, ist ein Vorschlag — Reihenfolge und Wichtigkeit bestimmst du.
Worauf kommt es gerade an?
Dieselbe Liste sieht je nach Absicht anders aus. Wer etwas zum Laufen
bringen will, zieht das Funktionierende nach vorn und verschiebt die Härtung.
Wer etwas ans Netz stellt, dreht das um. Nur das Verhältnis der
Regler zählt.
Zugangsdaten, Rechte, Eingabeprüfung, Protokollierung
Was das Vorhaben können soll — der Regelfall
Kleine Posten zuerst, damit früh etwas dasteht
Von Hand gesetzte Wichtigkeiten bleiben unangetastet.
Loops
Ein Auftrag füllt das Backlog; ein Loop arbeitet einen
Ausschnitt davon ab. Dazwischen liegt die Entscheidung, wer daran arbeitet.
Ein Loop im Zustand bereit ist fertig gedacht und läuft trotzdem
nicht — bis du es sagst.
lädt…
Vorhaben zerlegen
Vorhandene Posten bleiben stehen.
Dauerlauf
Nimmt sich die offenen Posten nach Wichtigkeit vor, einen nach dem anderen.
Keine Zwischenfragen — geweckt wirst du nur bei Unumkehrbarem:
Produktion, Vault, Rechte, Selbst-Update. Für Läufe über Nacht.
Hört auf bei drei Fehlschlägen hintereinander — das ist kein Pech mehr.
Posten
Von Hand ergänzen
Warteschlange
Was läuft, was wartet — und warum gebremst wird.
Warteschlange
| Zustand | Run | Branch | Priorität | seit |
|---|
Aufgaben
| Prio | Aufgabe | Status | Läufe | letzter |
|---|
Ideen
| Idee | Status | Nutzen | Aufwand |
|---|
Kunden und Projekte
Jedes Projekt gehört zu einem Kunden und hat ein eigenes Repository.
Kunden
| Slug | Name | Projekte | Notizen |
|---|
Projekte
| Kunde / Projekt | Workmode | Datenklasse | Team | Tasks | Runs |
|---|
+ Neues Projekt
local_only braucht mindestens einen lokalen Worker
(NPU, Beelink oder Mac), sonst scheitert jeder Lauf — siehe
docs/konfiguration.md.Agenten-Team
Jede Rolle bekommt eine Kette. Fällt der erste Eintrag aus, nimmt der Router den nächsten.
Rollenbelegung
Jede Rolle bekommt eine Kette. Fällt der erste
Eintrag aus — offline, Rate Limit, falsche Datenklasse — nimmt der Router
den nächsten. Eine Rolle mit nur einem Eintrag hat keinen Ausweich.
Arbeitsweisen
Eine Arbeitsweise ändert nicht, was gebaut wird, sondern wie. Dauerhaft für ein Projekt — oder einmalig für einen Auftrag.
Katalog
Die Regeln einer Arbeitsweise werden der Anweisung der betroffenen Rollen
vorangestellt. Beispiel Grilling: ohne ihn rät der Planner
bei Unklarheiten, mit ihm hört er auf zu raten und fragt.
Hier gesetzte Arbeitsweisen gelten für jeden Auftrag des Projekts.
Im Auftragsformular lässt sich zusätzlich einmalig etwas zuschalten.
Neue Arbeitsweisen bekommen niemals automatisch kritische Rechte.
Wissensbasis
Spezifikationen laden — die Agenten bekommen daraus die passenden Kapitel mit.
Spezifikation laden
Die Datei wird an ihren Überschriften in Kapitel zerlegt. Pro Auftrag
bekommt der Agent nur die passenden Kapitel — nicht das ganze Dokument.
Geladene Dokumente
| Name | Kapitel | Größe | maßgeblich | SHA |
|---|
Semantische Suche
Ohne Einbettungen sucht das System nur nach Wörtern, die im Text stehen.
Wer nach „was passiert, wenn kein Geld mehr da ist“ fragt,
findet das Kapitel „0-Euro-Budget“ damit nicht — es teilt kein
einziges Wort mit der Frage. Die Einbettungen werden lokal
gerechnet und kosten nichts.
Kapitelsuche ausprobieren
Selbstentwicklung
BaerAgentOS arbeitet an sich selbst. Niemals automatisch: jede Änderung braucht eine Freigabe.
Eigenen Quellcode aufnehmen
Abgleich mit dem Entwicklungsrechner
An diesem Quelltext arbeiten zwei Parteien: baer mit einem Assistenten am
Entwicklungsrechner, und BaerAgentOS hier über die Selbstentwicklung.
Beide schreiben in dasselbe Repository. Wird hier ein Kandidat angewendet
und dort danach deployt, wäre diese Arbeit still wieder weg —
ohne Fehlermeldung. Deshalb steht hier, was gerade besetzt ist.
noch nicht abgefragt
Entwicklungsteam
Am eigenen Quelltext zu arbeiten ist die anspruchsvollste Aufgabe, die das
System hat: gewachsener Code, viel Dokumentation, und ein Fehler trifft es
selbst. Ein Modell, das eine 187-Zeilen-Datei nicht wortgetreu wiedergeben
kann, ist hier fehl am Platz — auch wenn es woanders reicht.
Backlog der Selbstentwicklung
Dieselben Posten wie im Backlog-Reiter, nur schon auf
baeragentos gefiltert. Ein Lauf endet hier
nie mit einem Update, sondern mit einem Kandidaten
weiter unten — deshalb ist fertig noch nicht deployt.
lädt…
Wunsch eintragen
Was BaerAgentOS können soll. Landet als in Planung —
also als Notiz, nicht als Arbeitsauftrag. Erst wenn du ihn auf
offen schiebst, darf daran gearbeitet werden.
Update-Kandidaten
noch keine Kandidaten
Provider und Modelle
Wo die Modelle herkommen, was sie kosten, ob sie erreichbar sind.
lädt…
Abo-Kontingente
Ein Budget zählt Euro und lässt sich nachlegen. Ein
Kontingent zählt Token in einem rollenden Fenster und
lässt sich nicht nachlegen — es ist alle, bis das Fenster
weiterrückt. Deshalb weicht der Router hier auf andere Anbieter
aus statt auf billigere.
lädt…
Gleichzeitigkeit
Anbieter laufen unabhängig voneinander parallel — Mac,
Beelink und OpenRouter gleichzeitig. Innerhalb eines Anbieters gilt seine eigene
Zahl. Bei einem Broker ist sie hoch: gleichzeitige Aufrufe kosten dort Geld,
aber keine Zeit. Bei einem lokalen Rechner ist sie 1 —
und das ist keine Vorsicht, sondern der Arbeitsspeicher: Ollama lädt sonst
ein zweites Modell, verdrängt das erste und macht beide Aufrufe
langsamer als nacheinander.
lädt…
+ Neuen Provider anlegen
Adapter
openai passt für fast alles mit
/chat/completions — auch Ollama, vLLM oder LM Studio.Modell-Arena
Modelle unter gleichen Bedingungen gegeneinander. Erst gemessen, dann benotet.
Modelle gegeneinander antreten lassen
Alle Teilnehmer bekommen dieselben Aufgaben, denselben Prompt und dieselbe
Temperatur. Wo sich Richtigkeit messen lässt, entscheidet die
Messung — bei Codeaufgaben läuft eine Testsuite, die das
Modell nicht kennt. Ein Juror benotet nur noch die Güte der Antworten,
die bereits bestanden haben, und sieht dabei keine Modellnamen.
Wonach soll ausgewählt werden?
Es gibt keine beste Wahl, nur eine beste Wahl für einen Zweck.
Für einen Langlauf über Nacht zählt Qualität, und Zeit wie Geld sind zu
verschmerzen. Für ein schnelles Zwischenergebnis ist es umgekehrt.
Nur das Verhältnis der drei zählt.
Statistik über alle Durchläufe
Durchläufe
Verbrauch
Tokens, Euro und Budgetgrenzen — nach Modell und nach Tag.
Tokens pro Tag
Nach Modell
| Provider | Modell | Abrechnung | Calls | Input | Output | Ø ms | EUR |
|---|
Systemzustand
Version, Datenbankstand, Fähigkeiten und laufende Dienste.
Version
Budget
| Geltungsbereich | Zeitraum | verbraucht | soft | hard | Auslastung |
|---|
Status
Capabilities