Was ist neu
in c9n?

c9n sagt, was als Nächstes zu tun ist

• Content-Aufgaben: Ist ein Video fertig, erscheint „Video prüfen und freigeben“. Ebenso: neues Referenzbild prüfen, fehlendes Startbild wählen, fehlgeschlagene Produktion prüfen, Skript anpassen oder überarbeiten.
• Sichtbar unter Aufgaben (mitgezählt im Menü), als Zahl am Menüpunkt „Content“ und als Hinweis „Das wartet auf dich“ oben im Content-Bereich. Ein Klick öffnet den richtigen Bereich und den Beitrag.
• Auch per MCP (todos_list).

Eindeutige Zustände für GPU-Worker

• Jeder Worker hat genau einen Zustand – gleich in der Seitenleiste, unter „Gerade“ und in der Tabelle: Arbeitet, Lädt Modell, Bereit, Pausiert, Problem, Wartet auf ersten Kontakt, Offline. Die Erklärung steht auf der GPU-Worker-Seite („Was die Zustände bedeuten“).
• Der Worker meldet sich jetzt jede Minute, auch während langer Aufträge – vorher konnte er während eines Videos als „offline“ erscheinen. Er meldet außerdem, wenn er gerade ein Modell lädt oder ein Problem hat (neue worker.py).
• „Offline“ heißt nur noch: seit über 2 Minuten keine Meldung.

Schnitt

• Fehler behoben: Fehlte auf dem GPU-Rechner ffprobe und war ein Clip kürzer als geplant, fiel beim Schnitt alles nach dem ersten Clip still weg. Der Schnitt misst die Clips jetzt immer (zur Not mit ffmpeg selbst) und prüft das fertige Video: Ist es kürzer als geplant, meldet der Worker einen Fehler statt ein halbes Video abzuliefern.

GPU-Rechner mit einer Zeile hinzufügen

• Einstellungen → GPU-Worker → Name eingeben → „Worker hinzufügen“: c9n zeigt einen fertigen Befehl (curl -fsSL …/install/… | sh). Auf dem GPU-Rechner ausgeführt, prüft er GPU, Speicher, ffmpeg und ein lokales Sprachmodell, richtet die passenden Aufgaben ein (Schnitt, Text, Bild) und startet den Worker als Dienst.
• Der Befehl enthält keinen Schlüssel, sondern einen Einmal-Code (30 Minuten gültig); der Rechner holt sich den Schlüssel selbst und speichert ihn nur für den Benutzer lesbar.
• c9n zeigt „Wartet auf …“ und dann „ist verbunden“. Der bisherige Weg mit dem Schlüssel von Hand bleibt unter „Ohne Installer einrichten“.
• Video (MiniMax-H3) richtet der Installer noch nicht ein.

Was die GPU gerade macht

• Mini-Status unten in der Seitenleiste auf jeder Seite: grün „bereit“ (mit geladenem Modell), blau pulsierend bei laufendem Auftrag mit Laufzeit und üblicher Dauer (z. B. „Clip 1: Frühstück mit Philipp · 12 von ~85 min“), orange „pausiert“, grau „offline“; dazu die Warteschlange. Mehrere GPUs werden zusammengefasst.
• Ein Klick öffnet die GPU-Worker-Seite mit „Gerade“ und Statistik der letzten 7 Tage: GPU-Zeit pro Tag, Aufträge, Erfolgsquote, Dauer je Art und je Worker.
• Wer die GPU von Hand nutzt, legt auf dem Rechner ~/c9n-media/PAUSE mit einem Grund an: der Worker meldet sich dann als „pausiert“ statt „offline“ und nimmt keine Aufträge an.

Speicher & Modelle auf der GPU-Worker-Seite

• Neue Übersicht „Speicher & Modelle“ je Worker: wie viel Speicher der Rechner insgesamt hat, wie viel davon die GPU nutzen darf, und jedes Modell als Balken im selben Maßstab – mit seinen Teilen (z. B. Videomodell: Text-Encoder, Generator, Decoder).
• Man sieht, welches Modell gerade geladen ist und welches nur nacheinander in den Speicher passt. Es ist immer nur ein Modell geladen; der Worker wechselt vor jedem Auftrag.
• Die Größen meldet der Worker selbst (neue worker.py).

Einstellungen mit klarer Struktur

• „Einstellungen“ hat links ein Untermenü – wie „Wissen“: Übersicht, Team & Zugänge, KI-Modelle, GPU-Worker, Verbindungen, Freigaben, System & Updates. Man sieht immer, wo man ist; die doppelte Reiterleiste oben ist weg.
• GPU-Worker hat eine eigene Seite (vorher versteckt unter „Modelle“): Schlüssel, Speicher, freigegebene Modelle, Protokoll.
• „Hosting“ heißt jetzt „System & Updates“, „Modelle“ heißt „KI-Modelle“.
• „Einstellungen“ bleibt auf allen Unterseiten markiert (vorher nicht bei Modellen und Freigaben).
• Auch „Content“ hat ein Untermenü: Personas, Content-Board, Redaktionsplan, Nachtproduktion, Freigaben. Die Seite zeigt als Überschrift, in welchem Bereich man ist.

Beiträge löschen

• Im Beitrag gibt es „Löschen“ mit Rückfrage. Skript, Storyboard, Prüfung und fertige Clips werden entfernt, laufende Aufträge stoppen. Veröffentlichte Beiträge bleiben als Nachweis erhalten.
• Auch per MCP (item_delete).

GPU-Speicher auf einen Blick

• Unter Einstellungen → Modelle zeigt der Worker jetzt oben den gesamten GPU-Speicher: den festen Teil (VRAM) plus das, was die GPU aus dem Arbeitsspeicher mitnutzen darf – z. B. „28 GB von 90 GB“, darunter „2 GB fest · bis 88 GB aus dem Arbeitsspeicher“. Bei Rechnern mit gemeinsamem Speicher (AMD Ryzen AI MAX) ist das die Zahl, die für Modelle zählt.
• Arbeitsspeicher und Auslagerung (Swap) mit Gesamtgröße; alle Balken stehen auf einer Linie, Beschriftungen brechen nicht mehr um.
• Die Swap-Größe braucht die neue worker.py auf dem GPU-Rechner.

Bessere Videos

• Prompt im Format, das MiniMax-H3 erwartet: Für jeden Clip schreibt das lokale Sprachmodell zuerst einen ausführlichen Videoprompt nach der Anleitung von MiniMax – Startbild, Ablauf, Kamerabewegung, Sprecher mit Stimme, Geräusche und Musik. Vorher bekam das Videomodell nur einen Satz.
• Der gesprochene Satz steht jetzt im Prompt – wörtlich und auf Deutsch. Die Lippen passen damit zum Untertitel. Weicht das Sprachmodell vom Text ab, rendert c9n mit einem einfachen Prompt im selben Format.
• Neues Persona-Feld „Stimme“ (Tonlage, Klang, Tempo): So spricht die Persona in jedem Video.
• Personen bleiben an ihrem Platz: Der Prompt legt fest, wer links und wer rechts sitzt.
• Clips so lang wie der Text: Die Länge ergibt sich aus dem gesprochenen Satz (etwa 2,3 Wörter pro Sekunde plus Pause, 5–15 Sekunden) statt immer 15 Sekunden. Das spart auch Renderzeit.
• Schnitt: kurze Überblendungen zwischen den Clips, Lautstärke auf −14 LUFS (üblich für Reels) und ein Untertitel pro Sprecher („Und?“ – „Ich finde …“ erscheinen nacheinander). Dafür braucht der GPU-Rechner die neue worker.py.

Skript prüfen

Im Beitrag prüft „Skript prüfen“ das Skript gegen eine Social-Media-Checkliste:

• vom Sprachmodell bewertet (1–5): Hook in den ersten 2 Sekunden, eine Kernaussage, Pointe, klingt nach der Persona, erzählt in Bildern, Handlungsaufforderung – jeweils mit Befund und Verbesserungsvorschlag;
• von c9n berechnet: Sprechzeit gegenüber der geplanten Länge, Satzlänge für Untertitel, Leitplanken;
• drei alternative Einstiege, die sich mit einem Klick übernehmen lassen (gespeichert wird erst mit „Skript speichern“).

Ein genaueres Bewertungsmodell (Open-Jev-27B) folgt, sobald der GPU-Rechner mehr Grafikspeicher hat.

Alles passt auch auf dem Handy

• Umschalter („Nur lokal / Cloud nach Freigabe“, „Wer darf freigeben“, Videoqualität) sind ein gemeinsamer Baustein. Auf schmalen Bildschirmen stehen die Optionen untereinander statt abgeschnitten oder dreizeilig umbrochen.
• Überschriften mit Buttons: Auf dem Handy rutschen die Buttons unter die Überschrift, statt über den Rand zu ragen (z. B. „Organisationsbild speichern“).
• Workflow-Reiter brechen nicht mehr um; auf dem Handy lassen sie sich seitlich wischen.
• Jede Version prüft vor dem Release alle Seiten am Desktop und in Handybreite: Buttons einer Reihe stehen bündig, kurze Beschriftungen brechen nicht um, keine Seite scrollt seitlich.

Einheitliche Buttons auf allen Seiten

• Gleicher Aufbau überall: Button-Reihen, Überschriften mit „Schließen“ und Rückfragen vor dem Löschen kommen jetzt aus gemeinsamen Bausteinen. Buttons stehen bündig nebeneinander, haben dieselbe Größe und brechen nicht mehr um.
• Referenzbilder: „Löschen“ steht als Button in derselben Reihe wie „Freigeben“ und „Verwerfen“; die Rückfrage erscheint darunter mit „Ja, löschen“ und „Abbrechen“.
• „Schließen“ ist in allen Panels ein Button oben rechts, auf Höhe der Überschrift.
• Lose Textlinks neben Buttons (z. B. „Eintrag löschen“, „← zurück zu Idee“) sind jetzt richtige Buttons.
• Noch mit eigenem Button-Design: Pilot, Unternehmenslandkarte, Cloud-Ausführung, Kreativstudio und Organisationskarte. Sie werden in einer der nächsten Versionen umgestellt.

GPU-Worker: Speicher sehen, Modelle freigeben

• Speicher live unter Einstellungen → Modelle: GPU-Speicher, von der GPU mitgenutzter Arbeitsspeicher, belegter Arbeitsspeicher und Auslagerung als Balken (ab 90 % orange), dazu das gerade geladene Modell. Dafür braucht der GPU-Rechner die neue worker.py.
• Modelle einzeln freigeben: Bild, Text, Video und Schnitt lassen sich je Worker an- und ausschalten. Ein gesperrtes Modell bekommt keine Aufträge; sie warten, bis es wieder freigegeben ist.
• Der Worker bevorzugt Aufträge für das Modell, das gerade geladen ist, und beendet das Sprachmodell, solange ein Video rendert (beides passt nicht gleichzeitig in den Speicher).

Referenzbilder, die zur Persona passen

• Bildprompt vom lokalen Sprachmodell: Aus Persona und Wunsch schreibt das Sprachmodell zuerst einen Foto-Prompt (englisch, nur was sichtbar sein soll). Ein kurzer Wunsch wie „Caroline beim Frühstück“ genügt. Der verwendete Prompt steht am Bild.
• Nie mehr Schrift aus Regeln: Verneinte Satzteile („keine Schrift“, „ohne Logos“) und der Name der Persona gehen nicht mehr ans Bildmodell – es hat sie als Text ins Bild gemalt.
• Neues Persona-Feld „Bildsprache“: Kleidung, Accessoires, Farben, Orte – geht in jedes Bild und Video. „Aussehen“ bleibt die innere Vorstellung für Texte.
• Referenzbilder löschen (mit Rückfrage). Einstellungen, die das Bild nutzen, fragen danach nach einem neuen Startbild; geplante Produktionen damit werden angehalten.

Stabiler GPU-Worker

• Das Bildmodell läuft in einem eigenen Prozess und wird vor jedem Video vollständig beendet. Vorher konnte der Arbeitsspeicher überlaufen, sobald nach Bildern ein Video startete.
• Stürzt der Worker ab, bekommt er seinen unterbrochenen Auftrag beim Neustart sofort zurück (statt nach 3 Stunden). Den Worker bitte auf dem GPU-Rechner aktualisieren (neue worker.py).

Mehr Platz oben

Die Kopfzeile ist weg. Arbeitsraum-Art, „Du arbeitest lokal“, offene Freigaben und „Neu laden“ stehen unten in der Seitenleiste. Häkchen (z. B. „Verworfene zeigen“, Kennzeichnungen) stehen wieder bündig neben ihrer Beschriftung.

Content-Board: Karten ziehen

Karten lassen sich mit der Maus zwischen den Spalten ziehen. Beim Ziehen leuchten die erlaubten Spalten auf: Idee → Skript → Storyboard, vorwärts je ein Schritt, zurück jederzeit; ins Storyboard erst mit fertigem Skript. Produktion, Freigabe und Geplant setzt c9n selbst, sobald der Schritt erledigt ist. Die Knöpfe in der geöffneten Karte funktionieren weiterhin (auch per Tastatur).

Freigegebene Referenzbilder wieder verwerfen

Ein freigegebenes Referenzbild lässt sich nachträglich verwerfen. Geplante, noch nicht gestartete Produktionen, die es als Startbild nutzen, werden angehalten und gehen zurück ins Storyboard; dort wählt ihr pro Einstellung ein anderes freigegebenes Startbild. Bereits fertige Videos bleiben erhalten.

Personas direkt in c9n bearbeiten

Unter Content → Personas gibt es jetzt Persona bearbeiten und Neue Persona: Kurzprofil, Biografie, Aussehen, Selbstbild, Widerspruch, menschliche Seite, Sprache („sagt … statt …“), Beispielsätze und Leitplanken mit Tabuwörtern und Bildregel. Hat jemand die Persona inzwischen geändert (auch ein KI-Assistent über MCP), überschreibt das Speichern nichts, sondern meldet es.

GPU-Server: was läuft, was wurde verarbeitet

• Einstellungen → Modelle → Medien-Worker zeigt je Rechner: online/offline, GPU und Speicher, und welches Modell wofür läuft (Bild, Text, Video, Schnitt) – plus ein Protokoll der letzten Aufträge mit Wofür, Modell, Dauer, Ergebnis und Fehlermeldung.
• Content → Nachtproduktion erklärt den Ablauf (tagsüber Bilder und Texte, nachts Videos – nie gleichzeitig) und die Verwaltung stellt dort Nachtfenster und Videoqualität ein: *Schnell* (480p, etwa 1 Stunde je 15-Sekunden-Clip) oder *Final* (768p, beste Qualität, etwa ein Clip pro Nacht). Die Wahl gilt für neue Aufträge.

Besser lesbar

• Helle Buttons und Umschalter (z. B. Liste/Wolke im Wissen) bleiben beim Überfahren mit der Maus lesbar.
• Nachtproduktion: Überblick als einheitliche Kacheln (Nachtfenster, fertig, fehlgeschlagen, offen, GPU-Zeit).
• Freigabeseite für KI-Clients: Knöpfe gleich groß, Beschriftungen bündig.

KI-Clients mit Anmeldung verbinden (OAuth)

Claude Desktop, Claude Code und andere MCP-Clients verbinden sich jetzt ohne kopierten Schlüssel:

1. Im KI-Client die Adresse eintragen, z. B. https://<eure-adresse>/mcp/content (Content-Studio) oder https://<eure-adresse>/mcp (Wissen lesen).
2. Der Client öffnet c9n im Browser. Angemeldet seht ihr, welcher Client worauf zugreifen möchte, und klickt Erlauben (oder Ablehnen).
3. Fertig. Der Zugang erscheint unter Wissen → Einstellungen → „Mit KI verbinden“ als „… (OAuth)“ und lässt sich dort jederzeit sperren; damit endet auch die automatische Verlängerung.

• Der Zugang gilt nur für die Person, die erlaubt hat, und nur für diesen Arbeitsraum.
• Content-Studio braucht das Gestaltungsrecht; Wissen lesen darf jede Person.
• Zugänge laufen nach 8 Stunden ab und verlängern sich im Client automatisch, höchstens 60 Tage ohne Nutzung.
• Der bisherige Weg mit Schlüssel bleibt für Clients ohne OAuth erhalten.

Worker-Schlüssel per MCP

Die Verwaltung kann den Schlüssel für einen GPU-Medien-Worker auch über den Content-Zugang anlegen lassen (Werkzeug media_worker_create). So kann ein KI-Assistent den Worker vollständig einrichten.

Update: sichtbarer Fortschritt mit Zeit und Protokoll

Bisher zeigte die Hosting-Seite während eines Updates nur „Anfrage wartet auf den Update-Dienst …“ – man sah nicht, ob etwas passiert, wie lange es noch dauert oder ob ein Fehler aufgetreten ist.

• Laufende Uhr ab dem Klick auf „Update jetzt starten“, auch während die Anwendung neu startet.
• Schritte Herunterladen · Image prüfen · Daten sichern · Neue Version starten, jeweils mit Häkchen und Dauer; beim Herunterladen die bereits geladenen MB.
• Restzeit „noch ca. …“, geschätzt aus dem letzten Update genau dieses Servers.
• Protokoll des Update-Dienstes mit Uhrzeit je Eintrag, live aktualisiert. Nach dem Update bleibt es eine Stunde lang sichtbar, bei einem Fehler steht dort, in welchem Schritt er auftrat.
• Der Update-Dienst übernimmt eine Anfrage jetzt nach spätestens 3 statt 15 Sekunden.
• Release-Notizen werden auf der Hosting-Seite formatiert angezeigt statt mit Markdown-Zeichen.

Hinweis: Beim Wechsel auf 0.8.1 läuft noch die Oberfläche und der Update-Dienst von 0.8.0 – dieses eine Mal sieht man den Fortschritt noch nicht. Ab dem nächsten Update ist er da.

Update-Dienst: keine GitHub-Abfragegrenze mehr

GitHub erlaubt ohne Anmeldung 60 Abfragen pro Stunde – pro Internetanschluss, geteilt mit allen Geräten dahinter. Hinter einem gemeinsamen Anschluss war dieses Kontingent oft schon von anderen Geräten verbraucht, und die Prüfung auf Updates schlug fehl.

• Der Update-Dienst fragt öffentliche Versionen jetzt über die normale GitHub-Seite ab, nicht mehr über die begrenzte Schnittstelle. Die Prüfsumme des Images wird wie bisher kontrolliert.
• Die Release-Notizen stehen vor dem Update wieder auf der Hosting-Seite.
• Uhrzeiten in Meldungen stehen in deutscher Zeit statt in UTC.

Hinweis: Das Update auf 0.8.0 läuft noch mit dem bisherigen Update-Dienst. Meldet er die Abfragegrenze, bitte zur genannten Uhrzeit erneut prüfen (die Zeit ist dort noch UTC, also zwei Stunden früher als bei uns). Ab 0.8.0 tritt das nicht mehr auf.

Content-Studio: von der Persona zum fertigen Reel

Neuer Menüpunkt Content für Kurzvideos mit fiktiven Figuren, z. B. Satire-Reels für Instagram.

• Personas mit Biografie, Selbstbild, Widersprüchen, Sprache, Beispielsätzen und Leitplanken (z. B. „Keine Gesichter“, „keine realen Personen“). Leitplanken werden bei jedem Schritt geprüft: Motive, Skripte und Storyboard-Einstellungen mit Verstoß werden abgelehnt oder markiert.
• Referenzbilder entstehen lokal auf eurem GPU-Rechner. Bilder mit erkennbarem Gesicht werden automatisch verworfen, wenn die Persona das verbietet. Nur freigegebene Bilder dienen als Startbild.
• Content-Board (Idee → Skript → Storyboard → Produktion → Freigabe → Geplant) und Redaktionsplan mit festem Rhythmus (Di 18:00, Fr 12:00) und Rückwärtsplanung (Skript 5 Tage, Storyboard 3 Tage, Produktion 2 Tage, Freigabe 1 Tag vorher). Verspätete Schritte werden markiert.
• Skript und Storyboard schreibt auf Wunsch das lokale Sprachmodell; ihr könnt beides selbst ändern.
• Nachtproduktion: je Einstellung ein Videoclip aus dem Startbild, danach Schnitt auf 1080×1920 mit Untertiteln. Standardfenster 23:00–06:00. Produktion lässt sich abbrechen.
• Freigaben: Veröffentlichen erst mit den Kennzeichnungen „KI-generiert“ und „Satire · fiktive Figur“, Bildunterschrift und Termin. Der Probelauf Instagram zeigt das fertige Paket; gesendet wird nichts.

Alles auch per MCP

Unter Wissen → Einstellungen → „Mit KI verbinden“ gibt es den neuen Umfang Content-Studio. Damit kann ein KI-Assistent alle Schritte über /mcp/content ausführen – mit denselben Regeln wie in der Oberfläche. Nur mit Gestaltungsrecht.

Medien-Worker auf eurem GPU-Rechner

Unter Einstellungen → Modelle legt die Verwaltung einen Worker-Schlüssel an. Der Worker läuft auf dem GPU-Rechner und holt Aufträge über HTTPS ab; c9n muss den Rechner nicht erreichen. Der Schlüssel darf nur Aufträge dieses Arbeitsraums holen und abliefern.

Grenzen dieser Version

• Instagram wird noch nicht wirklich beschickt, nur der Probelauf.
• Referenzbilder aus der Cloud sind noch nicht möglich, nur lokal.
• Ein 15-Sekunden-Clip braucht auf einem AMD-Strix-Halo-Rechner rund eine Stunde; pro Nacht entstehen etwa sechs Clips.
• Die Gesichtsprüfung erkennt menschliche Gesichter, keine gezeichneten Figuren.
• Personas werden per MCP angelegt und geändert; in der Oberfläche sind sie vorerst nur lesbar.

Update-Dienst: GitHub-Abfragegrenze

GitHub erlaubt ohne Anmeldung 60 Abfragen pro Stunde. Der Update-Dienst hat bei jeder Prüfung für jede Version einzeln nachgefragt und diese Grenze aufgebraucht. Dann meldete er fälschlich „Releases liegen in einem privaten Repository“ und bot kein Update an.

• Eine Prüfung braucht jetzt eine Abfrage statt sechs bis acht; eine unveränderte Liste kostet nichts.
• Ist die Grenze doch erreicht, steht auf der Hosting-Seite „GitHub-Abfragegrenze erreicht. Der nächste Versuch klappt ab HH:MM Uhr.“

Enthält alles aus 0.7.2.

Update-Dienst: sicherer Abschluss

Nach einem erfolgreichen Update erneuert sich der Update-Dienst selbst. Schlägt dieser letzte Schritt fehl, läuft die neue Version jetzt einfach weiter und die Hosting-Seite meldet es. Bisher hätte ein solcher Fehler die gerade gestartete Anwendung angehalten.

Enthält alles aus 0.7.1.

Hosting-Seite ohne GitHub-Zugang

Das Feld „GitHub-Zugang“ auf der Hosting-Seite ist entfernt. Neue Versionen liegen öffentlich bereit; der Update-Dienst findet und installiert sie ohne Zugangsdaten.

Enthält alles aus 0.7.0 („Lokal zuerst“).

Lokal zuerst

KI-Schritte laufen jetzt standardmäßig auf deinen eigenen Modellen. Ein Cloud-Modell wird nie mehr stillschweigend genutzt: Braucht ein Schritt die Cloud, hält der Lauf an und fragt, bevor etwas dein Netz verlässt.

Eigene lokale Modelle – Einstellungen → Modelle

• Zeigt alle lokalen Modelle mit Zustand und – bei vLLM-Servern – wie viele Anfragen laufen und warten.
• Eigenes Modell eintragen: jede OpenAI-kompatible Adresse im eigenen Netz (vLLM, Ollama, LM Studio). c9n prüft sie vor dem Speichern; öffentliche Adressen werden abgelehnt.
• Standard für den Arbeitsraum: „Nur lokal“ oder „Cloud nach Freigabe“ (nur die Verwaltung). Neue Arbeitsräume starten mit „Nur lokal“. Bestehende Arbeitsräume mit Workflows stehen auf „Cloud nach Freigabe“, damit ihre Cloud-Schritte weiterlaufen – jetzt mit Rückfrage.

Wo läuft dieser Schritt?

Jeder KI-Schritt im Editor zeigt: Lokal · Cloud nach Freigabe · Cloud. Lokal bleibt alles in deinem Netz, ohne Kosten pro Token.

Freigabe vor jedem Außenkontakt

• Der Lauf pausiert: „Dieser Schritt würde c9n verlassen“ – mit Ziel, Grund, Umfang, Kosten und dem genauen Text, der übertragen würde. Zulassen (Enter) oder Ablehnen (Esc).
• Eine Freigabe gilt genau einmal und nur für diesen Text. „Für diesen Workflow merken“ ist möglich und unter Freigaben jederzeit widerrufbar.
• Die Verwaltung legt fest, wer freigeben darf. Jede Freigabe wird mit Person, Zeit und Text gespeichert.
• In der Kopfzeile: „Du arbeitest lokal“ und „N Freigaben offen“.

Herkunft und Kosten

• Jeder Lauf zeigt je Schritt Lokal oder Cloud · Modell, Dauer, Tokens und Kosten.
• Unter Wirkung: lokale und Cloud-Schritte je Monat und Workflow. Cloud-Kosten nur aus gemeldeten Tokens und hinterlegten Preisen – ohne Preis steht „unbekannt“.

Zeitpläne in Alltagssprache

„Jeden Werktag um 9 Uhr …“ – c9n versteht den Satz lokal und füllt Start und Wiederholung zum Prüfen aus. Monatliche Zeitpläne werden noch nicht unterstützt.

Bekannte Grenzen

• Die Anbindungen OpenRouter, Hugging Face und Ollama Cloud melden keine Token-Zahlen; ihre Kosten stehen deshalb als „unbekannt“.
• „um fünf“ wird als 05:00 verstanden. Die Uhrzeit vor dem Anlegen prüfen.
• GitHub-, Slack- und Outlook-Konnektoren sowie die Sandbox für Werkzeugkarten folgen in 0.8.0.

Erste Version, die über die Hosting-Seite kommt

Diese Version ist die erste, die bestehende 0.6.0-Installationen unter Einstellungen → Hosting angeboten bekommen und per Klick installieren.

• Das Einrichtungsskript des Update-Dienstes verlangt keinen GitHub-Zugang mehr; die Releases sind öffentlich.

Sonst keine Änderungen gegenüber 0.6.0.

Updates mit einem Klick unter Einstellungen → Hosting

Unter Einstellungen → Hosting prüft „Nach Updates suchen“ jetzt, ob eine neue Version bereitsteht, und bietet sie an. Nach deiner Bestätigung lädt c9n die Version, prüft Prüfsummen und Image, sichert deine Daten, startet die neue Version und lädt die Seite danach selbst neu. Du musst dafür nichts auf dem Server tun.

Möglich macht das ein zweiter kleiner Container, der Update-Dienst. Er läuft neben der Anwendung und wird bei jedem Update mit aktualisiert. Die Anwendung selbst hat weiterhin keinen Zugriff auf Docker; sie gibt nur deinen Klick an den Update-Dienst weiter.

Releases sind öffentlich

Neue Versionen erscheinen ab jetzt im öffentlichen Repository dajor/c9n, mit Installer und Anwendungsimage. Der Update-Dienst braucht deshalb keinen GitHub-Zugang. Wer Releases aus einem privaten Repository bezieht, kann auf der Hosting-Seite einen Lesezugang hinterlegen; er wird geprüft, nur auf dem Server gespeichert und nie wieder angezeigt.

Geändert

• Ohne verbundenen Update-Dienst behauptet die Hosting-Seite nicht mehr, es gebe keine neuere Version.
• Fehler des Update-Dienstes stehen mit ihrer Ursache auf der Hosting-Seite.

Einmalig für bestehende Installationen

Installationen vor 0.6.0 richten den Update-Dienst einmal ein (siehe UPDATES.md im Installer). Danach kommen alle weiteren Versionen über die Hosting-Seite.

Neu: lokale CPU-Karten im Advanced-Workflow

• Informationen erkennen: Aus einem Eingabetext strukturierte Felder als Text, Zahl, Ja/Nein oder Auswahl vorschlagen. Fehlende Pflichtangaben und unklare Ergebnisse gehen zur menschlichen Prüfung. Vorschläge werden nicht automatisch als Wissen bestätigt.
• Aufgabe zuordnen: Zwei beschriebene Bearbeitungswege und einen Weg zur menschlichen Prüfung verbinden. Die Zielkarten können unterschiedliche Modelle oder andere Aktionen sein.
• Beide Karten haben einen Beispieltest mit Ergebnis und Laufzeit. Unter Verbindungen → Needle lässt sich die lokale Ausführung prüfen. Das Modell wird mit dem Docker-Image ausgeliefert; kein API-Schlüssel und keine GPU erforderlich.

Grenzen dieser ersten Version

Needle verarbeitet Text, keine Screenshots. Pro Eingabe sind höchstens 4000 Zeichen und acht Ergebnisfelder vorgesehen. Die Installation führt einen lokalen CPU-Aufruf gleichzeitig aus. Weitere gleichzeitige Aufrufe melden „belegt“; nach 30 Sekunden wird ein hängender Aufruf abgebrochen. Es gibt keinen automatischen Wechsel zu einem Cloud-Modell.

Routing ist experimentell. In echten Tests wurden Aufgaben auch bei hoher angezeigter Modellsicherheit falsch oder gar nicht zugeordnet. Eigene repräsentative Beispiele sind vor dem Einsatz erforderlich; wichtige Folgeaktionen sollten weiterhin menschlich freigegeben werden. „Manuell prüfen“ muss mit einer menschlichen Aufgabe verbunden sein. Technische Routingfehler stoppen den Lauf; die Extraktionskarte hat einen eigenen Fehlerausgang.

Das Modell läuft auf dem c9n-Host. Eine konfigurierte Cloud-Orchestrierung verarbeitet weiterhin die Workflow-Eingaben und Ergebnisse entsprechend ihrer bestehenden Funktionsweise. Lokale Modellverarbeitung allein bedeutet daher nicht, dass ein Cloud-Workflow vollständig offline arbeitet.

Das erste gebündelte Docker-Paket unterstützt Linux x86_64. Andere CPU-Architekturen sind noch nicht als Installationsziel freigegeben.

Weitere Verbesserungen

Die Verbindungseinstellungen sind nach Diensten gegliedert und durchsuchbar. Wissen und Wissenseinstellungen sind getrennt. Die öffentliche Versionsprüfung funktioniert auch ohne angeschlossenen Update-Dienst; für eine Installation bleibt der Update-Dienst erforderlich. Versionsnummern werden ohne Alpha-Zusatz angezeigt. Details zu diesen Änderungen stehen auch in den Hinweisen zu 0.1.1.

Navigation und Rückmeldungen

• Unter Wissen stehen Übersicht und Einstellungen jetzt direkt im Seitenmenü. Beide Unterpunkte bleiben auch im eingeklappten Menü erreichbar.
• Landkarte neu laden lädt tatsächlich das ausgewählte Organisationsbild und seine Verknüpfungen neu. Ladezustand, erfolgreiche Aktualisierung und Fehler werden sichtbar angezeigt.
• Die öffentliche Website ist in Start, Produkt, Nachweise, Community, Download und Kontakt gegliedert. Neue öffentliche Releases erscheinen dort automatisch mit passenden Downloads und Release Notes.

Dieses öffentliche Paket enthält nur den Installer für Linux amd64 / Docker Compose. Das passende Anwendungsimage wird Pilotkunden privat bereitgestellt. Der Produktcode bleibt privat. Prüfe vor der Installation SHA256SUMS-installer.txt. Bestehende Installationen werden nicht automatisch aktualisiert.

First semantically versioned c9n installation package: 0.1.0-alpha.1.

This public ZIP contains the installer and instructions, not the application image. The application remains private and is supplied separately to approved pilot customers. Request access at https://c9n.app/#contact.

• Docker Compose configuration for Linux amd64, with loopback-only access and persistent data.
• First-administrator setup, without preconfigured accounts.
• Installer verifies the exact application image ID and refuses to overwrite an existing configuration.
• German/English installation and update guidance; SHA-256 checksum attached.
• Community gateway, GPU sharing and credits are planned, not enabled by this package.

Download c9n-installer-0.1.0-alpha.1.zip and SHA256SUMS-installer.txt. Verify using sha256sum -c SHA256SUMS-installer.txt, then follow the included guide. GitHub's automatic source archives contain only this public product repository.

Tested: production image build, first-owner setup on an isolated Docker volume, health/version/assets/editors, persistent account after restart. Early alpha for guided testing, not a production-readiness guarantee.