---
title: Geltungsbereich
description: >-
  Was v1 ist, was aus dem früheren Plan für die Ausführungsebene gestrichen
  wurde und warum.
sidebar:
  order: 8
---
Runic war nicht immer ein Cache. Frühere Pläne (im Repository unter `_deprecated/` archiviert sowie in `ALPHA.md`/`ROADMAP.md` als historischer Kontext) beschrieben eine Ausführungsumgebung: Tool-Aufrufe abfangen, Berechtigungen durchsetzen, Dateisystem-/Netzwerkzugriff sandboxen und ein festes Budget messen. Diese Seite erklärt, warum dieser Plan gestrichen und nicht erweitert wurde.

## Im Umfang von v1

- Das Caching des Ergebnisses einer Entscheidung, basierend auf einer normalisierten Signatur mit exakter Übereinstimmung — `{ intent, params }`, niemals roher Aufgabentext, niemals ein Reasoning-Trace.
- Das Protokollieren ausgegebener Tokens (vom Agenten gemeldet) im Vergleich zu bei einem Cache-Treffer eingesparten Tokens.
- Geltungsbereich pro Sitzung. Sitzungsübergreifendes bzw. agentenübergreifendes Teilen ist eine spätere Phase, sobald sich zeigt, dass Wiederverwendung pro Sitzung in der Praxis relevant ist.

## Ausdrücklich nicht im Umfang

- **Ausführung jeglicher Art.** Runic ruft niemals eine Fähigkeit auf, stellt nichts bereit und führt keinen Code aus. Das alte `packages/runtime` ist tot.
- **Berechtigungen oder Sandboxing.** Es gibt nichts zu prüfen, wenn nichts ausgeführt wird. Die alten `packages/permissions` und `packages/sandbox` sind tot.
- **Semantisches oder unscharfes Aufgaben-Matching.** Das ist bewusst eng gefasst — nur exakte Übereinstimmung. Es ist eine Entwurfsbeschränkung, die eine Beschränkung bleiben soll, und keine v1-Abkürzung, die später ausgeweitet wird, ohne die Frage erneut zu stellen, ob ein Cache-Treffer *tatsächlich* dieselbe Entscheidung ist.

## Warum dies ein Kurswechsel und keine Ergänzung ist

Der Großteil des alten Plans für die Ausführungsebene — Berechtigungsdurchsetzung, Sandboxing, Fähigkeitenausführung — erwies sich als Duplizierung dessen, was MCP bereits für Tool-Aufrufe standardisiert. Ein paralleles Berechtigungs-/Ausführungssystem darüber zu bauen, ist für sich genommen kein vertretbarer Ansatz; es ist redundante Infrastruktur, die mit einem bereits bestehenden Standard konkurriert.

Die Idee eines Caches mit Ledger überstand die Streichung, weil sie eine Frage beantwortet, die MCP nicht beantwortet: *Wurde diese exakte Entscheidung bereits getroffen, und was hat sie gekostet?* Das ist eine engere, ehrlichere Aussage als „Runic verwaltet die Ausführung deines Agenten“ — und sie ist es, die dieses Repository tatsächlich liefert, mit echten Benchmark-Zahlen als Beleg statt mit einem Architekturdiagramm.

## Wenn du nach dem Plan für die Ausführungsebene suchst

Er ist zur historischen Dokumentation in `ALPHA.md` und `ROADMAP.md` im Stammverzeichnis des Repositorys erhalten, und der Code selbst ist unter `_deprecated/` archiviert. Keines von beiden wird gepflegt, und keines spiegelt wider, was Runic heute ausliefert — lies dafür [Einführung](/).