Aleph

Aleph ist ein MCP-Server und eine Fähigkeit für Recursive Language Models (RLMs). Er hält den Arbeitszustand — Suchindizes, Codeausführung, Beweise, Rekursion — in einem Python-Prozess außerhalb des Prompt-Fensters, sodass das LLM iterativ über große Codebasen, langlebige Projekte, Protokolle, Dokumente und Daten nachdenken kann, ohne Kontext für Rohinhalte zu verbrauchen.

+-----------------+    tool calls     +-----------------------------+
|   LLM client    | ---------------> |  Aleph (Python process)     |
| (context budget)| <--------------- |  search / peek / exec / sub |
+-----------------+   small results  +-----------------------------+

Warum Aleph:

• Einmal laden, mehrfach schlussfolgern. Daten leben im Aleph-Speicher, nicht im Prompt.

• Serverseitige Berechnung. exec_python führt Code über den gesamten Kontext aus und gibt nur abgeleitete Ergebnisse zurück. Für JS/TS-Repos bieten exec_javascript und exec_typescript eine persistente Node.js-Laufzeitumgebung über denselben ctx.

• Rekursion. Unterabfragen und Rezepte teilen komplexe Aufgaben in mehrere Schlussfolgerungsdurchläufe auf.

• Arbeitsbereiche warm halten. Binden Sie Kontexte an Dateien oder generierte Arbeitsbereichs-Manifeste, aktualisieren Sie diese und setzen Sie lange Untersuchungen später fort.

Schnelleinstieg

pip install "aleph-rlm[mcp]"
aleph-rlm install --profile claude   # or: codex, portable, api
aleph-rlm doctor                     # verify everything is wired up

Starten Sie dann Ihren MCP-Client neu und bestätigen Sie, dass Aleph verfügbar ist:

get_status()
list_contexts()

Die optionale /aleph (Claude Code) oder $aleph (Codex) Skill-Verknüpfung startet einen strukturierten RLM-Workflow. Installieren Sie docs/prompts/aleph.md in den Befehls-/Skill-Ordner Ihres Clients — siehe MCP_SETUP.md für genaue Pfade.

Wenn Sie Aktionstools in einem echten Repo verwenden, ist die sicherste Standardeinstellung:

aleph --enable-actions --action-policy read-only

Cursor

Verwenden Sie globales MCP (aleph-rlm install cursor) für --workspace-mode any oder Projekt-MCP (aleph-rlm install cursor-project aus dem Repo) für ${workspaceFolder} + --workspace-mode fixed. Chat, Composer und die Cursor-CLI teilen sich diese MCP-Konfiguration; eine Cursor-Erweiterung ist optional und für Aleph nicht erforderlich — siehe MCP_SETUP.md.

Einstiegspunkte

Installationsprofile

aleph-rlm install fragt, welches Unterabfrageprofil verwendet werden soll. Profile konfigurieren das verschachtelte Backend, das sub_query und sub_query_batch für rekursives Schlussfolgern erzeugen.

aleph-rlm install claude-code --profile claude
aleph-rlm configure --profile codex   # overwrite existing config

Siehe docs/CONFIGURATION.md für alle Umgebungsvariablen, CLI-Flags und Laufzeit-configure(...)-Optionen.

Workflow für große Codebasen

Wenn Ihr Hauptanwendungsfall ein Repo oder ein Projekt mit mehreren Ordnern ist, beginnen Sie damit, ein kompaktes Arbeitsbereichs-Manifest zu laden, anstatt Rohquellcodedateien in das Modellfenster zu werfen. Das gibt dem Modell eine Karte des Projekts, lässt es aggressiv suchen und hält die Sitzung aktualisierbar, während sich das Repo ändert.

load_workspace_manifest(paths=["src", "tests"], context_id="repo")
rg_search(pattern="FastAPI|APIRouter|router\\.", paths=["src", "tests"], load_context_id="routes")
load_file(path="pyproject.toml", context_id="pyproject")
exec_python(code="""
files = [line for line in ctx.splitlines() if line.startswith("- ")]
summary = {
    "indexed_entries": len(files),
    "top_python_files": [line for line in files if "| python |" in line][:10],
}
""", context_id="repo")
get_variable(name="summary", context_id="repo")
refresh_context(context_id="repo")

Verwenden Sie load_workspace_manifest als Standard-Eingangstor für große Codebasen und Projekte. Ziehen Sie dann bestimmte Dateien mit load_file hinzu, durchsuchen Sie das Repo mit rg_search und aktualisieren Sie den gebundenen Kontext, wenn sich der Arbeitsbereich ändert. Aktualisierungen bewahren den Schlussfolgerungszustand der Sitzung, das Beweisprotokoll und die verfolgten Aufgaben.

Workflow für einzelne Dateien

Aleph ist auch stark, wenn Sie eine große Datei einmal laden, die schwere Arbeit innerhalb von Aleph erledigen und nur kompakte Antworten abrufen.

load_file(path="/absolute/path/to/large_file.log", context_id="doc")
search_context(pattern="ERROR|WARN", context_id="doc")
peek_context(start=1, end=60, unit="lines", context_id="doc")
exec_python(code="""
errors = [line for line in ctx.splitlines() if "error" in line.lower()]
result = {
    "error_count": len(errors),
    "first_error": errors[0] if errors else None,
}
""", context_id="doc")
get_variable(name="result", context_id="doc")
save_session(context_id="doc", path=".aleph/doc.json")

Die wichtige Gewohnheit ist, serverseitig zu rechnen. Behandeln Sie get_variable("ctx") nicht als Standardpfad. Suchen, filtern, unterteilen oder fassen Sie zuerst zusammen und rufen Sie dann ein kleines Ergebnis ab.

Wenn Sie den Nur-Terminal-Modus anstelle von MCP wünschen, verwenden Sie:

aleph run "Summarize this log" --provider cli --model codex --context-file app.log

Lokale Modelle (llama.cpp)

Aleph kann ein lokales Modell anstelle einer Cloud-API verwenden. Dies führt die vollständige RLM-Schleife — Suche, Codeausführung, Konvergenz — vollständig auf Ihrem Computer ohne API-Kosten aus.

Voraussetzungen: llama.cpp und eine GGUF-Modelldatei.

# Install llama.cpp
brew install llama.cpp          # Mac
winget install ggml.LlamaCpp    # Windows

# Start the server with your model
llama-server -m /path/to/model.gguf -c 16384 -ngl 99 --port 8080

Verweisen Sie Aleph auf den laufenden Server:

export ALEPH_PROVIDER=llamacpp
export ALEPH_LLAMACPP_URL=http://127.0.0.1:8080
export ALEPH_MODEL=local
aleph

Oder lassen Sie Aleph den Server automatisch starten:

export ALEPH_PROVIDER=llamacpp
export ALEPH_LLAMACPP_MODEL=/path/to/model.gguf
export ALEPH_LLAMACPP_CTX=16384
export ALEPH_MODEL=local
aleph

Getestet mit Qwen 3.5 9B (Q8_0, ~9 GB). Jedes GGUF-Modell funktioniert — größere Modelle liefern bessere Ergebnisse in der RLM-Schleife. Modelle mit Unterstützung für Schlussfolgerung/Denken (Qwen 3.5, QwQ, etc.) werden automatisch gehandhabt. Siehe CONFIGURATION.md für alle ALEPH_LLAMACPP_*-Variablen.

Häufige Arbeitslasten

Kern-Tools

Python vs. JS/TS REPL

Alephs primäre Steuerungsebene ist weiterhin Python. exec_python bleibt die Standard-REPL für allgemeine Analysen, Rezepte und Orchestrierung.

• Verwenden Sie exec_python, wenn Sie die volle Aleph-Oberfläche benötigen: Python-first Prompts, Pythons numerischer / symbolischer Stack (cmath, mpmath, decimal, fractions, statistics, numpy, scipy, sympy, networkx) oder Rezeptausführung über run_recipe_code.

• Verwenden Sie exec_javascript / exec_typescript, wenn das Ziel-Repo oder die Analyse natürlich JS/TS-geformt ist und Sie einen persistenten Node-Zustand, JS-native Array-/Objektmanipulation oder asynchrone Rekursion mit await wünschen.

• exec_python Volle Aleph-Helferoberfläche, einschließlich Rezept-DSL-Helfer, synchrones sub_query(...) / sub_aleph(...) und die breiteste Kompatibilität mit bestehenden Prompts und Workflows.

• exec_javascript / exec_typescript Persistente Node.js-Laufzeitumgebung pro Kontext für JS/TS-lastige Repos. Teilt denselben ctx, unterstützt Top-Level await und kann mit asynchronem await sub_query(...), await sub_query_batch(...), await sub_query_map(...), await sub_query_strict(...) und await sub_aleph(...) rekursiv sein. Enthält auch die Rezept-DSL (Recipe, Search, Take usw.) zum Erstellen von Rezept-Payloads in JS/TS.

Die JS/TS-Laufzeitumgebung wird auch mit einem breiteren lokalen Helfer-Set geliefert als das erste Handoff-Segment: Suchen/Peek/Zeilen/Chunk, Extraktionshelfer (extract_emails, extract_todos, extract_routes usw.), Text-Dienstprogramme (number_lines, grep_v, sort_lines, normalize_whitespace usw.), Textvergleichshelfer (diff, similarity, common_lines, diff_lines), Sammlungshelfer (flatten, group_by, frequency, sample_items, shuffle_items usw.), Validierungshelfer (is_json, is_email, is_uuid usw.), CSV-/JSON-Konverter und semantic_search.

Die JS/TS-Laufzeitumgebung enthält jetzt auch die Rezept-DSL: RecipeStep, RecipeBuilder und alle Schritt-Konstruktoren (Recipe, Search, Peek, Lines, Take, Chunk, Filter, MapSubQuery, SubQuery, Aggregate, Assign, Load, Finalize, as_recipe). Sie können Rezepte mit flüssiger Verkettung oder im Pipe-Stil erstellen:

// Fluent style
Recipe("doc").search("ERROR").take(5).finalize().compile()

// Pipe style
Recipe("doc").pipe(Search("ERROR")).pipe(Take(5)).pipe(Finalize()).compile()

Die MCP-Tools compile_recipe und run_recipe_code akzeptieren einen language-Parameter ("python", "javascript", "typescript"), um Rezept-DSL-Code in der entsprechenden Laufzeitumgebung zu kompilieren.

Was sich von Python unterscheidet:

• Python ist immer noch die Standard- und am besten unterstützte Aleph-REPL.

• JS/TS-Rekursionshelfer sind asynchron und erfordern await.

• Die Rezept-Ausführung (run_recipe) verwendet immer die Python-Laufzeitumgebung. Der JS/TS-Pfad deckt nur das Rezept-Erstellen und Kompilieren ab.

• JS verwendet RecipeBuilder.pipe() / flüssige Methoden anstelle des Python-Operators | (JS | ist bitweises ODER, nicht für diesen Zweck überladbar).

• Pythons Import-Ökosystem bleibt nur Python. Die Node-Laufzeitumgebung ist helfergesteuert: kein require, kein process, kein module und kein Laden von npm-Paketen innerhalb der Sandbox.

• exec_typescript entfernt Typsyntax für die Ausführung; es ist kein vollständiger TS-Compiler, Typ-Prüfer oder ts-node-Umgebung.

• Das Verhalten von Regex-Flags folgt jeder Laufzeitumgebung: Python-Helfer verwenden Python re-Flags, während JS/TS-Helfer JavaScript-Regex-Flag-Strings verwenden.

Beispiel für einen JS/TS-Workflow:

exec_typescript(code=`
const routes: string[] = extract_routes('javascript').map((item) => item.value);
const routeKinds = frequency(
  routes.map((route) => (route.includes('.post(') ? 'write' : 'read')),
  2,
);
const notes = await sub_query_map(
  routes.map((route) => `Explain ${route}`),
  routes,
);
({ routeCount: routes.length, routeKinds, notes })
`, context_id="repo")

Sicherheitsmodell

Aleph wurde entwickelt, um Rohkontext aus dem Modellfenster fernzuhalten, es sei denn, Sie rufen ihn explizit ab:

• Tool-Antworten sind begrenzt und gekürzt.

• get_variable("ctx") ist richtlinienbewusst und sollte nicht Ihr Standardpfad sein.

• exec_python stdout, stderr und Rückgabewerte sind unabhängig begrenzt.

• ALEPH_CONTEXT_POLICY=isolated fügt strengere Regeln für den Sitzungsexport/-import und defensivere Standardeinstellungen hinzu.

• ALEPH_ACTION_POLICY=read-only (oder --action-policy read-only) hält Aktionstools im schreibgeschützten Modus: Suchen und Laden von Dateien funktionieren weiterhin, aber Schreibvorgänge und die Ausführung von Subprozessen sind blockiert.

Das sicherste Muster ist immer:

1. Laden Sie den großen Kontext in den Aleph-Speicher.

2. Suchen oder berechnen Sie innerhalb von Aleph.

3. Rufen Sie nur das kleine Ergebnis ab, das Sie benötigen.

Dokumentationskarte

• MCP_SETUP.md: Client-für-Client MCP- und Skill-Installation.

• docs/prompts/aleph.md: der /aleph und $aleph Workflow plus Tool-Muster.

• docs/CONFIGURATION.md: Flags, Umgebungsvariablen, Limits und Sicherheitseinstellungen.

• docs/langgraph-rlm-default.md: LangGraph-Integration mit Aleph-artiger Tool-Nutzung.

• examples/langgraph_rlm_repo_improver.py: Beispiel für Repo-Verbesserung mit optionalem LangSmith-Tracing.

• CHANGELOG.md: Release-Historie.

• DEVELOPMENT.md: Entwickler-Leitfaden.

Entwicklung

git clone https://github.com/Hmbown/aleph.git
cd aleph
pip install -e ".[dev,mcp]"
# Optional extras:
#   .[docs]           -> MarkItDown-backed document conversion
#   .[observability]  -> OpenTelemetry spans
pytest tests/ -v
ruff check aleph/ tests/

Referenzen

• Zhang, A. L., Kraska, T., Khattab, O. (2025) Recursive Language Models (arXiv:2512.24601)

Lizenz

MIT