Im Kommentar zur Modellwahl stand für claude-sonnet-5 rund 0.20 USD je Lauf.
Nach den aktuellen Listenpreisen (2/10 USD je Million Token) sind es rund 0.16 —
genau das Doppelte von Haiku 4.5, nicht das Zweieinhalbfache. Die Preisbasis
steht jetzt im Kommentar, damit die Zahlen beim nächsten Preiswechsel prüfbar
bleiben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Livia arbeitet nicht mehr neben dem Leadbestand, sondern in ihn hinein.
- Systemzugänge tragen Titel, Beschreibung und Adresse; die Liste zeigt je
Eintrag nur noch Aktiv/Inaktiv und Lesen/Schreiben — kein Berechtigungsbalken,
kein Auge-Icon, keine Lese-/Schreibgruppen
- Die Quellenregistry ist dynamisch: Der Lauf liest genau die aktiven
Lesezugänge mit Adresse aus Livias Personalblatt. Für die drei gepflegten
Quellen greift weiterhin ihr eigener Leser, für alles andere ein allgemeiner —
eine Übersichtsseite, bis zu zehn Unterseiten, kein Spider. Freie Adressen
werden auf http/https geprüft und gegen interne Netze gesperrt
- Manuell abgelegte PDF- und Word-Dokumente fliessen in denselben Lauf. Text
wird beim Ablegen nativ extrahiert (ZIP + Flate über DecompressionStream,
ohne neue Abhängigkeit), Datei und Text liegen in IndexedDB
- Neuer harter Filter «Zeitliche Relevanz»: das Modell beurteilt die
Ereigniszeit der Veränderung, nicht das Publikationsdatum. «unknown» fällt
bewusst nicht durch — ein erfundenes Datum wäre die schlechtere Antwort
- Quellentypen und Beobachtungsraum sind Chips mit Freitext; jeder Wert lässt
sich einzeln entfernen, auch die vorgegebenen
- Info-Knopf bei «Zeitliche Relevanz» und «Mindestrelevanz» erklärt, wie der
Wert entsteht — ohne erfundene Prozentgewichte
- Gefundene Leads gehen in den zentralen Signalbestand statt in eine zweite
Ergebnisliste; die Herkunft steht am Signal (origin: RESEARCH_RUN)
- Der Lauf erzeugt einen echten Protokolleintrag mit den Zahlen des Laufs
- Lead-Detail: zeitliche Einordnung mit Fundstelle, semantisches Suchprofil bei
Chancen mit «Matching starten», und bei Risiko ausdrücklich «Kein internes
Objekt eindeutig zugeordnet» statt einer beliebigen Mock-Immobilie
- Aufgabenliste nach §11 bereinigt, «Unsichere Signale in Review Queue legen»
von Nora übernommen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach der Umstellung auf Haiku 4.5 scheiterte jeder Beurteilungsaufruf mit
«This model does not support the effort parameter». Der Schalter war für Opus
gesetzt und wurde bedingungslos mitgeschickt — bei einem Modell, das über eine
Umgebungsvariable frei wählbar ist, darf das nicht sein. Eine
Kostenoptimierung, die die Funktion zur Laufzeit kaputtmacht, ist keine.
Der Schalter geht jetzt nur noch an Modelle, die ihn kennen. Bewusst als
Erlaubnisliste: ein unbekanntes Modell läuft ohne ihn — das kostet etwas mehr,
funktioniert aber. Die umgekehrte Voreinstellung würde raten und scheitern.
Ergebnis des ersten vollständigen Haiku-Laufs auf Produktion: 49 Einträge, 38
verworfen, 2 Watchlist, 9 Leads, davon 5 mit hoher Relevanz — mehr als Opus 5
im Vergleichslauf am selben Bestand fand, bei einem Zehntel der Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Modellwahl läuft über eine Umgebungsvariable im Hosting-Dashboard. Damit
sah man nirgends in der Anwendung, welches Modell gerade urteilt — und eine
Einstellung, die man nur im Dashboard prüfen kann, prüft niemand.
Der Refresh gibt das Modell jetzt zurück, die Kopfzeile zeigt es neben dem
Zeitstempel. Wer wissen will, ob die Umstellung angekommen ist, sieht es dort,
wo er ohnehin hinschaut.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Modell stand fest im Code, obwohl es die grösste Kostenstellschraube ist —
ein Lauf über fünfzig Meldungen kostet mit Opus 5 rund 0.40 USD, mit Haiku 4.5
etwa 0.08. Wer die Anwendung betreibt, soll diese Abwägung treffen können, ohne
den Quelltext anzufassen und neu zu deployen.
`LIVIA_RESEARCH_MODEL` wählt das Modell, `LIVIA_RESEARCH_TEXT_LIMIT` die Menge
Artikeltext je Meldung — der zweite grosse Hebel, weil der Immobilienbezug einer
Firmenmeldung fast immer im ersten Absatz steht und jede Halbierung die
Eingabekosten halbiert. Beide haben Vorgabewerte; ohne gesetzte Variablen
verhält sich alles wie bisher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim Messen des Tokenverbrauchs fiel auf, dass ein Lauf «49 Informationen
analysiert · 0 nicht relevant · 0 Watchlist · 0 relevante Entwicklungen»
meldete — was wie ein sauberer Lauf ohne Treffer aussieht. Tatsächlich war
jeder einzelne Beurteilungsaufruf mit «Your credit balance is too low»
gescheitert. Der `catch` um den Teilstapel fing den Fehler ab, damit ein
Ausfall nicht die übrigen mitreisst, und verlor dabei den Grund.
Scheitern alle Teilstapel, ist das kein leeres Ergebnis, sondern ein Ausfall.
Der Grund wird jetzt weitergereicht und erscheint als Warnung über der Liste.
Scheitern nur einzelne, bleibt es beim bisherigen Verhalten: die übrigen Leads
werden gezeigt.
Das ist die unangenehmste Fehlerklasse überhaupt — eine, die wie ein Ergebnis
aussieht. In einer Präsentation hätte niemand gemerkt, dass Livia gar nicht
gearbeitet hat.
Geprüft: tsc 0 Fehler, eslint 0 Fehler/0 Warnungen; der Lauf meldet den Fehler
jetzt sichtbar statt eine leere Liste.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Zefix-CSV nennt keine Firmennamen, sondern Tageszahlen je Branche. Als
Lead-Karte zwischen sechs echten Firmenmeldungen war sie ein Fremdkörper: Man
kann eine Branchenzahl nicht anrufen, und genau das verspricht eine Lead-Karte
mit «Empfohlene nächste Handlung».
Aggregierte Einträge werden weiterhin gelesen und beurteilt — die Quelle bleibt
angebunden und belegt, dass Livia auch strukturierte Daten verarbeitet —, zählen
aber als Beobachtungsposten statt als Lead. Das entspricht der «Early
Watch»-Einordnung der Vorgabe (§19), und die Zahlen der Kopfzeile gehen
weiterhin auf.
Die Quellenbeschreibung sagt jetzt selbst, warum dort keine Karte erscheint,
statt dass sich das jemand aus dem Ausbleiben erschliessen muss.
Geprüft: tsc 0 Fehler, eslint 0 Fehler/0 Warnungen, Build erfolgreich,
Live-Lauf 49 Einträge — Zefix erscheint nicht mehr als Lead, Summe aus
verworfen, Watchlist und Leads ergibt die Gesamtzahl.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Eine Seite reicht nicht. Die Handelskammer erneuert ihre obersten zehn
Meldungen im Lauf eines Tages; stehen dort gerade Personalien und
Meinungsbeiträge, findet Livia zu Recht nichts, und die Demo wirkt schwach,
obwohl die Mechanik stimmt. Genau das war zwischen zwei Läufen zu beobachten.
Neu werden je Quelle drei Übersichtsseiten gelesen — bei der Handelskammer über
`…/page/N.html`, bei Greater Zurich über `?page=N` —, gedeckelt auf 24 Artikel
je Quelle. Die Artikel werden parallel geholt statt nacheinander, die
Beurteilung läuft in begrenzt parallelen Fünferstapeln.
Wirkung, gemessen am selben Tag: aus 20 gelesenen Einträgen und 1 Lead werden
49 Einträge und 8 Leads, darunter zwei mit hoher Relevanz — eine
Arealentwicklung über 38 000 m² und eine Standorteröffnung. Laufzeit 30
Sekunden statt 16, weiterhin klar innerhalb des 60-Sekunden-Limits.
Die Begrenzung der Gleichzeitigkeit ist kein Detail: alle Teilstapel auf einmal
loszuschicken wäre schneller, läuft aber in die Drosselung des Anbieters — und
ein gedrosselter Lauf sieht für den Nutzer aus wie ein kaputter. Ein
gescheiterter Teilstapel reisst die übrigen nicht mehr mit.
Geprüft: tsc 0 Fehler, eslint 0 Fehler/0 Warnungen, Build erfolgreich,
Live-Lauf 49 Einträge aus 3/3 Quellen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Erster Produktionslauf schlug mit HTTP 500 fehl, lokal lief derselbe Code
grün. Ursache: Vercel kompiliert jede Datei einzeln statt sie zu bündeln, und
weil das Projekt `"type": "module"` ist, verlangt Nodes ESM-Lader explizite
Dateiendungen in relativen Importen. Vite löst im Entwicklungsbetrieb
grosszügiger auf und verdeckt das.
Das ist genau die Klasse Fehler, die kein Typecheck und kein Test findet — nur
ein echter Aufruf gegen die deployte Funktion.
Geprüft gegen Produktion: HTTP 200, 20 Einträge aus 3/3 Quellen in 24
Sekunden, Beurteilung läuft, Originalquellen verlinkt, keine Laufzeitfehler.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der erste Live-Lauf mit Schlüssel deckte auf, dass ein einziger Aufruf über
alle zwanzig Einträge das Urteil verwässert. Eine Meldung über eine
zweistellige Millioneninvestition in eine neue Brauerei samt Arealentwicklung
fiel als «nicht relevant» durch; derselbe Prompt, dasselbe Modell und dieselbe
Meldung ergaben in einem Stapel von drei «Investition, hohe Relevanz, 0.85».
Eine höhere Effort-Stufe half nicht, sie machte es messbar schlechter. Der
Hebel ist die Stapelgrösse. Die Teilstapel laufen parallel — die Laufzeit ist
damit die des langsamsten und nicht deren Summe: 48 Sekunden vorher, 16 danach.
Das ist zugleich die Voraussetzung fürs Deployment: die serverlose Funktion
hat voreingestellt 10 Sekunden Zeit. `vercel.json` hebt das Limit nun
ausdrücklich auf 60 Sekunden an, was auch bei einer langsamen Quelle reicht.
Ausserdem: Der Linktext der Handelskammer trägt das Publikationsdatum vorneweg
und ein »-Zeichen hinten. Beides stand bisher im Titel, den das Modell zu lesen
bekam, und gehört dort nicht hin.
Geprüft: tsc 0 Fehler, eslint 0 Fehler/0 Warnungen, Live-Lauf 20 Einträge aus
3/3 Quellen in 17 Sekunden. Die Urteile sind stichprobenweise gegen die
Originalartikel geprüft und tragfähig — eine Bäckereieröffnung in
Westaustralien und eine Übernahme in Thailand werden zutreffend als ohne
Schweizer Flächenbezug verworfen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Livia liest jetzt tatsächlich aus dem Netz statt aus Mockdaten. Ein Knopf
«Research aktualisieren» ruft serverseitig drei Quellen ab, beurteilt die
Einträge in einem einzigen LLM-Aufruf und zeigt nur an, was plausibel zu
Flächenbedarf oder Flächenfreisetzung führen könnte.
Kein Crawler, kein Scheduler, keine Queue, keine Datenbank. Der Hoster kann
bereits serverlose Funktionen — es hat bisher nur niemand eine gebraucht.
Deshalb genügt eine einzige Datei unter `api/`, drei Abruffunktionen, eine
Normalisierung und ein Analyseaufruf.
Quellen, alle drei live geprüft:
- Zürcher Handelskammer, 10 Artikel
- Greater Zurich Area, 9 Artikel
- Zefix / Open Data Kanton Zürich, CSV direkt
Zur Zefix-Quelle eine Feststellung, die von der Aufgabenstellung abweicht: die
CSV enthält keine Firmennamen. Sie führt Tageszahlen von Neugründungen je
NOGA-Branche für den Kanton Zürich. Daraus lässt sich kein Unternehmenslead
bauen, sondern nur ein aggregiertes Frühsignal zum Zielmarkt — und genau so
wird es übergeben. Namen zu erfinden, um das erwartete Format zu treffen, wäre
die eine Sache, die Livia nie tun darf.
Die drei Quellen stehen im Frontend unter «Angebundene Kanäle & Systeme» mit
Status und anklickbarem Originallink; jeder erzeugte Lead verlinkt zusätzlich
die Seite, aus der er stammt. Die Adressen kommen aus derselben Liste, die der
Abruf benutzt — der angezeigte Link kann damit nicht von dem abweichen, was
tatsächlich gelesen wurde.
Der Textextraktor sucht den Artikeltext im engsten passenden Container. Ohne
das standen bei der Handelskammer Telefonnummern und Öffnungszeiten am Anfang
jedes Textes, und das Modell hätte die Fusszeile mitbeurteilt.
Der LLM-Schlüssel liegt ausschliesslich serverseitig in `ANTHROPIC_API_KEY`.
Fehlt er, sagt die Oberfläche offen, dass gelesen, aber nicht beurteilt wurde —
statt eine leere Liste als «nichts gefunden» auszugeben.
Für die lokale Entwicklung mountet ein Vite-Plugin dieselbe Handler-Datei, die
Vercel in der Produktion ausliefert; es gibt keine zweite Fassung des
Endpoints. `tsconfig.api.json` nimmt `api/` in `tsc -b` auf, damit ein
Tippfehler dort nicht erst beim Deployment auffällt.
Geprüft: tsc 0 Fehler, eslint 0 Fehler/0 Warnungen, 423/423 Tests grün, Build
erfolgreich, Live-Lauf im Browser mit 20 real gelesenen Einträgen aus 3/3
Quellen ohne Laufzeitfehler. Die LLM-Beurteilung selbst ist mangels Schlüssel
noch ungetestet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
