Jev AI Demos: 6 interaktive Jev Modell Demos erklärt

Wer nach Jev AI Demos oder Jev Model Demos sucht, sollte mehr prüfen als nur die Frage, ob Jev eine plausible Wahl trifft. Entscheidend ist, ob sich erkennen lässt, welchen Zustand das Modell erhalten hat, welche Optionen offenstanden, welche Antwort es gab und welche Aktion die umgebende Software tatsächlich ausgeführt hat. Die sechs Szenarien auf der Jev Demoübersicht sind auf genau diese Prüfung ausgelegt.

Die Sammlung umfasst eine sich verändernde Flugwebsite, ein Link-Rennen in einer Enzyklopädie, einen Warenkorb, die Triage von Supportanfragen, eine Prüfung in der Kreditorenbuchhaltung und einen Sicherheitsalarm. Websites, Tickets, Preise, Rechnungen und Vorfälle sind simuliert. Die Seiten beschreiben live getroffene Jev Entscheidungen und zeigen Anfragen und Antworten, wenn angemeldete Besucher ein Szenario starten. Das hilft beim Verständnis der Schnittstelle. Eine gut gestaltete Simulation belegt jedoch nicht, dass dieselbe Richtlinie bei Ihren eigenen Daten zuverlässig funktioniert.

Dieser Leitfaden erklärt, worauf Sie bei jeder Demo achten sollten, wo die Entscheidungsgrenze liegt und wie Sie aus einer Vorführung eine kleine, messbare Evaluation machen. Die Beschreibungen beruhen auf den öffentlich sichtbaren Seiten vom 27. September 2026. Sie behaupten nicht, dass ein bestimmter Durchlauf erfolgreich beendet wurde.

Inhaltsverzeichnis

• Die kurze Antwort
• Was alle sechs Demos gemeinsam haben
• Die sechs Jev Modell Demos im Überblick
• Demos mit Browser-Aktionen
• Support-Triage mit drei Urteilen pro Ticket
• Rechnungsprüfung mit Belegen vor dem Urteil
• Sicherheitsalarm mit Belegen vor der Reaktion
• Einen Demo-Durchlauf bewerten
• Von der Simulation zum echten Workflow
• Häufige Fragen

Die kurze Antwort

Die Jev Demos zeigen begrenzte Modellentscheidungen innerhalb von Software-Workflows. Bei den Browser-Szenarien verändert sich die Seite nach jeder genehmigten Aktion. Jev muss deshalb aus den gerade verfügbaren Bedienelementen wählen. In den Support-, Finanz- und Sicherheitsszenarien beurteilt es strukturierte Hinweise, die Code für Routing oder Review verwenden kann. Die Seiten bieten einen manuellen und einen zeitgesteuerten Automatikmodus, zeigen ein Entscheidungspanel und verlangen zur Ausführung eine Anmeldung. Wählen Sie zuerst den manuellen Modus, wenn Sie Anfrage und Antwort vor dem nächsten Schritt prüfen möchten.

Was alle sechs Demos gemeinsam haben

Das wiederkehrende Muster lautet beobachten → entscheiden → prüfen → handeln → erneut beobachten. Eine simulierte Oberfläche stellt Bedienelemente oder Datensätze bereit. Eine Jev Anfrage beschreibt den aktuellen Zustand und stellt eine eng gefasste Frage. Das Entscheidungspanel zeigt Anfrage, Antwort und anschließende Aktion. Der neue Seitenzustand wird zur Eingabe des nächsten Schritts. Die Modellantwort klickt nicht selbst auf einen Knopf, erstattet kein Geld zurück und isoliert kein Gerät. Die umgebende Anwendung entscheidet, ob und wie sie die Antwort verwendet.

Diese Trennung ist die wichtigste Entwurfslektion. Das Modell kann ein nächstes Bedienelement auswählen oder den Schweregrad eines Tickets einschätzen. Regulärer Anwendungscode setzt weiterhin Berechtigungen, Schwellenwerte und Zustandsänderungen durch. Besonders deutlich wird die Grenze dort, wo die Demos ausdrücklich sagen, dass kein echter Kauf, keine Zahlung, keine Nachricht und keine Sicherheitsmaßnahme stattfindet.

Die Fragetypen von Jev erklären außerdem, warum diese Beispiele mehr als ein Chatprotokoll sind:

Fragetyp	Form der Antwort	Einsatz in einer Demo
Choice	Eine vorab definierte Option samt Wahrscheinlichkeiten	Verfügbares Seitenziel oder Support-Queue auswählen
Score	Position auf einer geordneten Skala samt Verteilung	Ticket-Schweregrad oder Alarmrisiko bewerten
Noul	Wahrscheinlichkeit, dass eine konkrete Aussage wahr ist	Bedarf an menschlicher Prüfung einschätzen

Laut offizieller Entwicklerdokumentation kann ein Zustand mehrere typisierte Fragen in einer Anfrage enthalten. Als Zustand werden derzeit Text, JSON-Objekte oder Text-Arrays unterstützt; direkte Bild-, Audio- und Videoeingaben noch nicht. In den Demos übersetzt die Anwendung eine Seite oder einen Datensatz in einen für das Modell bewertbaren Zustand. Eine visuelle Browseroberfläche bedeutet nicht, dass das Modell unmittelbar Pixel sieht.

Die sechs Jev Modell Demos im Überblick

Demo	Aufgabe für Jev	Worauf Sie achten sollten	Wichtige Grenze
Flugsuche	Aktionen auf einem sich ändernden Flugformular und der Ergebnisseite wählen	Aktuelle Bedienelemente, gewähltes Ziel, neuer Suchzustand	Beispielhafte Flüge und Preise
Wiki-Link-Rennen	Sichtbaren Artikellinks zum Zielthema folgen	Kandidaten, bisheriger Pfad, nächster Artikel	Fiktive Enzyklopädie; keine Suche oder direkte URL
Support-Triage	Thema klassifizieren, Schwere bewerten und Review-Bedarf beurteilen	Drei Antworten und Routing-Regel	Keine Erstattung, Antwort oder Kontenänderung
Warenkorb	Produkte nach exakten Bedingungen auswählen	Produktvergleich, Warenkorb, Stoppbedingung	Kein echter Checkout
Rechnungsprüfung	Zugehörige Unterlagen prüfen und Fall einordnen	Geöffnete Belege vor der endgültigen Route	Fiktive Finanzdaten; keine Zahlung
Sicherheitsalarm	Hinweise prüfen und Autorisierung, Risiko und Reaktion beurteilen	Vollständigkeit der Hinweise und Reaktionsregel	Simulierter Vorfall; keine Geräteänderung

Das sind Demonstrationen verschiedener Entscheidungsformen, keine Rangliste für Benchmarks. Eine Browser-Aktion kann in einem Seitenzustand richtig und nach einer Änderung falsch sein. Eine Klassifikation kann dem geforderten Antworttyp entsprechen und trotzdem die falsche Queue auswählen. Trennen Sie diese beiden Arten von Korrektheit beim Zuschauen.

Demos mit Browser-Aktionen

Drei Szenarien machen den Zyklus aus Beobachtung, Entscheidung und Aktion greifbar. Jedes beginnt mit einer begrenzten Aufgabe und einer simulierten Website. Das Modell wählt aus den Bedienelementen oder Links der aktuellen Seite. Die Anwendung liefert Werte aus der Aufgabe und führt bestätigte Aktionen aus. Für jeden Schritt lässt sich prüfen, ob die Aktion verfügbar war und das Ziel nähergebracht hat.

Flugsuche mit verändertem Formular nach jeder Aktion

Die Flugdemo bietet Strecken wie Zürich–London und Singapur–Tokio. Die Standardaufgabe sucht einen einfachen Flug von Zürich nach London am 20. Oktober 2026 für einen Erwachsenen in der Economy Class. Die simulierte AeroFinder-Seite beginnt mit Suchfeldern und kann später Ergebnisse zeigen. Die Demo benennt vier Schritte: Seite lesen, Aktion wählen, prüfen und ausführen. Sie erklärt, dass Stadt- und Datumswerte aus der Aufgabe stammen, während Jev Aktion und Zielelement auswählt.

Achten Sie auf den Unterschied zwischen dem richtigen Feld und dem Wert für dieses Feld. Eine brauchbare Ablaufspur zeigt die indizierten Bedienelemente, Jevs ausgewähltes Ziel, den aus der Aufgabe übernommenen Wert und den nächsten Zustand. Ändern sich Layout oder Optionen, muss die folgende Entscheidung auf dem neuen Zustand beruhen statt auf einer starren Klickfolge. Die Beispielpreise sind keine aktuellen Flugangebote und taugen nicht zur Reiseplanung.

Wiki-Link-Rennen ohne Abkürzungen

Das Link-Rennen beginnt bei „Rubber duck“ und soll „Machine learning“ erreichen. Suche und direkte URLs sind gesperrt. Der simulierte OpenAtlas-Artikel zeigt nur die Links der aktuellen Seite. Jev muss jeweils einen davon auswählen. Anfangs sind beispielsweise „Rubber duck debugging“, „Waterfowl“ und „Toy“ verfügbar. Jeder Link eröffnet einen anderen möglichen Weg durch die fiktive Enzyklopädie.

Das ist ein kleiner Test für Planung mit lokalen Informationen. Prüfen Sie bei jedem Sprung, ob der gewählte Link sichtbar war, plausibel zum Ziel führt und der bisherige Pfad Fortschritt zeigt. Ein vielversprechender Titel kann trotzdem in einer Sackgasse enden. Das Ergebnis hängt daher sowohl von Jevs Urteil als auch vom Seitengraphen der Simulation ab. Der sichtbare Weg ist aussagekräftiger als ein einzelnes Erfolgslabel.

Warenkorb mit exaktem Abgleich und Stoppregel

Die Einkaufsdemo verlangt genau einen Liter Vollmilch, eine Packung mit zwölf Freilandeiern und ein 600-g-Vollkornbrot für weniger als vier Dollar. Jev durchsucht ein Beispielgeschäft, vergleicht ähnliche Artikel und füllt den Warenkorb. Die Aufgabe sagt ausdrücklich: anhalten, sobald die Liste stimmt, und nicht zur Kasse gehen.

Hier reicht es nicht, einen ähnlich benannten Artikel zu finden. Größe, Produkttyp, Menge, Preis und doppelte Warenkorbpositionen zählen. Vergleichen Sie jedes ausgewählte Produkt mit allen Bedingungen. Kontrollieren Sie zudem, ob das System bei den geforderten drei Artikeln stoppt und keinen unbefugten Checkout beginnt. Preise und Bestand sind Beispieldaten; aufschlussreich sind die Aktionsfolge und der endgültige Warenkorb.

Support-Triage mit drei Urteilen pro Ticket

Die Demo zur Support-Triage verwendet drei Beispiel-Tickets. Laut Seite liefert Jev pro Ticket in einer Anfrage drei Urteile: Choice für den Problemtyp, Score für den Schweregrad und Noul für die Wahrscheinlichkeit eines menschlichen Reviews. Erst nachdem Besucher die Antworten geprüft haben, wendet der simulierte Support-Desk eine im Code definierte Routing-Regel an.

Die veröffentlichte Regel ist konkret: Ein kritischer Schweregrad, eine Review-Wahrscheinlichkeit von mindestens 50 % oder eine Themen-Konfidenz unter 55 % leitet das Ticket an einen Menschen. Diese Werte gehören zur Demo und sind keine allgemeingültigen Schwellen. Das erste Ticket beschreibt wiederholte Doppelbelastungen und eine unbeantwortete Rechnungsanfrage aus dem Vormonat. Die anderen Fälle betreffen einen Produktions-API-Fehler und eine gewöhnliche Frage zum Export. Daran lässt sich erkennen, ob die drei Urteile getrennte Aspekte erfassen, statt alles in ein vages Label zu pressen.

Notieren Sie die Problemkategorie, die gesamte Schweregradverteilung, die Review-Wahrscheinlichkeit und den tatsächlich ausgeführten Zweig der Routing-Regel. Falls die endgültige Queue überrascht, trennen Sie Modellfehler von Fehlern in der auswertenden Regel. Die Seite sagt ausdrücklich, dass keine Nachricht versendet, keine Erstattung ausgelöst und kein Konto verändert wird. Die Queue-Zuweisung ist das simulierte Ergebnis.

Rechnungsprüfung mit Belegen vor dem Urteil

Die Demo zur Rechnungsprüfung umfasst drei Falltypen: übereinstimmende Unterlagen, bereits bezahlte Rechnung und geänderte Bankverbindung. Im fiktiven LedgerFlow-Desk kann Jev Rechnung, Bestellung, Liefernachweis, Lieferantenprofil und Zahlungshistorie prüfen, bevor es einen Fall einordnet. Die Ausgangsrechnung zeigt Lieferant, Bestellbezug, Position, Gesamtbetrag und verdecktes Zahlungskonto. Ein Zähler zeigt, wie viele der fünf Unterlagen bereits geprüft wurden.

Damit wird die Abdeckung der Belege sichtbar. Wer nur die Rechnung liest, kann eine Doppelzahlung oder eine geänderte Bankverbindung übersehen. Notieren Sie, welches Dokument Jev als Nächstes öffnet, welche neue Tatsache sichtbar wird und ob alle zusammen die abschließende Route rechtfertigen. Die Falltypen erlauben einen Vergleich: Stimmige Unterlagen können möglicherweise weitergehen, ein bereits bezahlter Fall verlangt Aufmerksamkeit für Doppelzahlungen und eine geänderte Bankverbindung einen anderen Prüfpfad. Die Demo verarbeitet fiktive Unterlagen und löst keine Zahlung aus; sie ist kein Nachweis für eine echte Zahlungskontrolle.

Sicherheitsalarm mit Belegen vor der Reaktion

Die Sicherheitsdemo beginnt entweder mit ungewöhnlichem Zugriff auf die Produktionsumgebung oder mit Aktivitäten einer Staging-Bereitstellung. Besucher sollen den Alarm und drei Beweispanels prüfen. Danach beurteilt Jev Autorisierung, Risiko und nächste Reaktion in einer Anfrage. Mögliche Entscheidungen sind Alarm schließen, Analysten-Review oder Asset isolieren und Bereitschaftsdienst benachrichtigen – ausschließlich innerhalb der simulierten Konsole.

Die zentrale Frage lautet, ob die Reaktion zu den beobachteten Hinweisen passt. Eine ungewöhnliche Admin-Anmeldung mit anschließendem Versuch, einen Credential-Speicher auf einem Produktionsserver zu öffnen, unterscheidet sich von erwarteten Staging-Aktivitäten. Prüfen Sie, welche Belege wirklich geöffnet wurden, was die typisierten Antworten aussagen und welche Richtlinie die endgültige Reaktion zulässt. Ein hoher Risikowert ist ein Signal für Code und Mitarbeitende; er erteilt keine Berechtigung, ein Produktionsgerät zu verändern. Die öffentliche Seite bezeichnet den Vorfall als fiktiv: Kein Gerät wird isoliert und kein echter Alarm geschlossen.

Einen Demo-Durchlauf bewerten

Beginnen Sie im manuellen Modus. Die Seiten werben auch mit einem Automatikmodus im Drei-Sekunden-Takt; manuell bleibt genug Zeit, jede Anfrage vor der nächsten Aktion zu lesen. Eine Anmeldung ist zum Start nötig. Halten Sie pro Schritt vier Beobachtungen fest: Zustand, zulässige Optionen, Jev Antwort und ausgeführter Zustandswechsel. Eine Ergebniskarte ohne diese vier Angaben kann die Fehlerursache verdecken.

Bewerten Sie nicht nur, ob das Szenario am Ende abgeschlossen ist. Nutzen Sie stattdessen diese Prüfliste:

1. Treue zum Zustand: Enthielt die Anfrage die nötigen Informationen und nur Fakten, die zu diesem Zeitpunkt verfügbar waren?
2. Gültigkeit der Aktion: Standen das gewählte Bedienelement, der Link oder die Fallentscheidung tatsächlich zur Auswahl?
3. Einhaltung der Vorgaben: Wurden Datum, Mengen, Preisgrenzen und untersagte Aktionen beachtet?
4. Belegabdeckung: Wurden zugehörige Unterlagen vor einer Finanz- oder Sicherheitsentscheidung geprüft?
5. Umgang mit Unsicherheit: Führten geringe Konfidenz oder hohe Review-Wahrscheinlichkeit gemäß Richtlinie zu einem anderen Pfad?
6. Ausführungsgrenze: Führte der Code nur genehmigte Schritte aus und verhinderte Checkout, Zahlung, Erstattung oder reale Isolierung?
7. Wiederholbarkeit: Ergeben ähnliche Zustände ähnliche Urteile, und lässt sich ein anderer Zweig erklären?

Ein Durchlauf ist eine Produkttour, keine Schätzung der Genauigkeit. Für Ihren eigenen Workflow brauchen Sie gelabelte Fälle einschließlich mehrdeutiger und adversarialer Beispiele. Stellen Sie bei allen dieselben Fragen und vergleichen Sie die Urteile mit den tatsächlichen Ergebnissen. Für Choice messen Sie Genauigkeit und Verwechslungen zwischen Kategorien. Bei Score untersuchen Sie benachbarte Schweregrade. Für Noul bilden Sie Wahrscheinlichkeitsgruppen und vergleichen die vorhergesagte Review-Rate mit dem tatsächlich nötigen Review. Messen Sie auch den Anteil menschlich geprüfter Fälle: Ein scheinbar präzises System kann fast alles an Menschen weiterleiten.

Halten Sie die Entscheidungsrichtlinie getrennt vom Modell. Die Review-Schwelle von 50 % ist in der Demo verständlich, doch Ihre eigene Schwelle hängt davon ab, wie teuer eine übersehene Eskalation im Vergleich zu unnötiger Prüfung ist. Legen Sie sie mit zurückgehaltenen Beispielen fest, dokumentieren Sie den Zielkonflikt und passen Sie sie an, wenn sich Workflow oder Kundschaft ändern. Fehlen notwendige Quelldaten, kann eine feste Regel „fehlender Beleg → Review“ bereits vor jeder Wahrscheinlichkeit greifen.

Von der Simulation zum echten Workflow

Betrachten Sie die Demos als Referenzmuster. Beginnen Sie mit einer eng begrenzten Produktionsentscheidung, etwa der Zuweisung einer Support-Queue oder der Frage, ob ein Dokument geprüft werden muss. Definieren Sie erlaubte Antworten, Zustandsfelder, mögliche Aktionen und den Fallback bei Unsicherheit. Testen Sie danach mithilfe der Jev API-Dokumentation Ihre eigenen Beispiele mit typisierten Fragen. Bewahren Sie Zugangsdaten auf dem Server auf, validieren Sie Antworten und lassen Sie Anwendungscode jede Nebenwirkung steuern.

Für Browser-Workflows stellen Sie zuerst eine kleine, geprüfte Menge zulässiger Bedienelemente bereit. Das Modell sollte weder beliebige Selektoren erfinden noch unsichtbare Aktionen ausführen. Bei Finanz- und Sicherheitsprozessen trennen Sie Belegsammlung und Entscheidung und verlangen die laut Richtlinie nötigen Dokumente. Im Support beginnen Sie mit Routing oder Priorisierung, bevor das System Kunden kontaktieren oder Konten ändern darf.

Speichern Sie schließlich ein knappes Auditprotokoll: Frageversion, Zustandsreferenz, verfügbare Optionen, Antwort samt Wahrscheinlichkeiten, Richtlinienversion, Freigabestatus und ausgeführte Aktion. So kann ein Team überraschende Ergebnisse erklären und Änderungen über die Zeit vergleichen. Eine Demo zeigt die Bausteine; eine Einführung verlangt gemessene Fehlerraten, eine klare Review-Richtlinie und operative Verantwortung.

Häufige Fragen

Kann ich die Jev AI Demos kostenlos ansehen?

Die öffentlichen Seiten zeigen Szenariobeschreibungen und simulierte Startzustände ohne einen Durchlauf. Für die interaktive Ausführung steht dort „Sign in to start“. Prüfen Sie die aktuellen Zugangs- und Nutzungsbedingungen der Website, bevor Sie sich auf einen bestimmten Tarif oder ein Kontingent verlassen.

Steuern die Demos echte Websites oder echte Transaktionen?

Nein. Die öffentlichen Seiten kennzeichnen Flugwebsite, Enzyklopädie, Geschäft, Finanz-Desk und Sicherheitskonsole als Simulationen. Es gibt keinen echten Checkout, keine Zahlung, Geräteisolierung oder Kundennachricht. Gezeigt werden Entscheidungen und von der Anwendung gesteuerte Zustandswechsel.

Liest Jev in diesen Demos Screenshots?

Die Jev Entwicklerdokumentation nennt derzeit Text, JSON-Objekte und Text-Arrays als Zustandsinputs. Bildeingaben werden noch nicht unterstützt. Eine Demo kann Besuchern eine visuelle Seite zeigen, während ihre Anwendung Jev eine textuelle oder strukturierte Beschreibung der aktuellen Bedienelemente und Unterlagen übergibt.

Welche Jev Modell Demo sollte ich zuerst ausprobieren?

Die Support-Triage zeigt Choice, Score und Noul zusammen in einer Anfrage. Die Flugsuche eignet sich für wiederholte Aktionswahl auf einer sich ändernden Seite. Die Rechnungsprüfung ist besonders aufschlussreich, wenn es Ihnen um ausreichende Belege vor einer Empfehlung geht.

Was wäre ein Beleg für die Eignung in meinem Anwendungsfall?

Verwenden Sie zurückgehaltene Fälle aus Ihrem eigenen Workflow, klare menschliche Referenzlabels, eine dokumentierte Richtlinie und Messungen von Fehlern, Kalibrierung, Review-Aufwand sowie fehlgeschlagenen oder blockierten Aktionen. Die Demo-Spur zeigt den Mechanismus; Ihre Evaluation zeigt, ob er Ihre betrieblichen Anforderungen erfüllt.

Quellenhinweis: Die Szenarien wurden anhand der öffentlichen Jev AI Demo-Seiten und Entwicklerdokumentation am 27. September 2026 geprüft. Angaben zur Modellschnittstelle wurden außerdem mit dem offiziellen TypeSafe AI Quickstart abgeglichen. Jev AI bezeichnet sich als unabhängig betrieben und nicht mit TypeSafe verbunden, von TypeSafe betrieben oder unterstützt. Prüfen Sie vor einer Integration anbieterspezifische Zugangsdaten, Endpunkte und Bedingungen.