Caloron-Noether
Caloron reimplemented as Noether composition graphs. Same orchestration capabilities, ~6x less code.
Architecture
noether-scheduler (cron: sprint_tick.json every 60s)
│
▼
Noether Engine (runs composition graphs)
├── DAG stages (Pure Python) — evaluate, is_complete, validate
├── GitHub stages (Network Python) — poll, create_issue, comment, merge
├── Supervisor stages (Pure Python) — health check, intervention, messaging
├── Retro stages (Pure/Network Python) — feedback, KPIs, report
└── Kickoff stages (Network/LLM Python) — repo context, DAG generation
│
▼
caloron-shell (~200 lines Rust, axum)
├── POST /heartbeat — record agent heartbeats
├── POST /spawn — create worktree + start harness
└── GET /status — list live agents
All business logic is in Noether stages (Python). The shell only manages processes and HTTP.
Prerequisites
Caloron-Noether is a set of stages and compositions that run on top of Noether (v0.3.0+). You need both the noether CLI and noether-scheduler on your PATH.
cargo install noether-cli noether-scheduler
# or grab prebuilt binaries: https://github.com/alpibrusl/noether/releases/latest
See the Noether docs for deeper configuration, and the Scheduler guide for cron-driven compositions.
Setup
# 1. Verify noether is installed
noether --version
noether-scheduler --version
# 2. (Optional) Point at the hosted stage registry
export NOETHER_REGISTRY=https://registry.alpibru.com
# 3. Register custom stages
./register_stages.sh
# 4. Build the shell
cargo build -p caloron-shell
# 5. Start the shell (heartbeat + spawn server)
CALORON_SHELL_PORT=7710 ./target/debug/caloron-shell
# 6. Start the scheduler (drives sprint ticks + weekly retro)
noether-scheduler --config scheduler.json
Documentation
Full docs: docs/ — build locally with mkdocs serve.
- Getting Started
- Architecture
- Stage Catalog
- Composition Graphs
- Shell API
- KV Conventions
- vs Original Caloron
- Deployment (Docker + K8s)
Stage Promotion Path
All stages start as Python. When a stage meets all four criteria (generality, hot path, stable schema, worth the lines), it can be promoted to Rust via InlineRegistry — zero graph changes needed. See context/inline-stages.md.
CLI
Installing the package (pip install caloron-noether) exposes a caloron ACLI-compliant command:
caloron init my-project --backend noether # create a project
caloron sprint "Build a hotel rate anomaly detector" # run an autonomous sprint
caloron status # active project + last sprint
caloron history --limit 10 # past sprints
caloron show 5 # full retro for sprint #5
caloron metrics --output json # aggregated KPIs
caloron agents # agent profiles in this project
caloron projects list | switch | delete # multi-project management
caloron config get|set <key> [value] # per-project settings
All commands accept --output text|json|table. The framework selected at caloron init --framework is propagated to the PO, HR, and reviewer agents. Supported frameworks: claude-code, cursor-cli, gemini-cli, codex-cli, open-code, aider. Non-claude frameworks use their agentic / auto-approval mode (-y for Gemini, --yes-always for Aider, exec --full-auto for Codex, -p for cursor-agent); make sure the corresponding CLI is authenticated and on $PATH.
Organisation conventions
Teams with a standard way of laying out projects, naming packages, or
licensing files can declare those rules once and have every caloron
sprint apply them. caloron org init scaffolds the file; edit it
with your conventions:
caloron org init # writes ~/.caloron/organisation.yml
# edit ~/.caloron/organisation.yml
caloron org show # preview the block every agent will see
caloron org validate # sanity-check the YAML
Per-project overrides go in <project>/caloron.yml (right-wins merge).
Conventions are injected into the PO, agent, reviewer, and fix
prompts — they're not enforced at tool level (no ruff config
generation, no CI gate) today; the reviewer is the backstop.
Runtime dependency — Gitea
Caloron uses Gitea as the version-control backend for sprints — issues,
PRs, merges, review comments all go through its API. A running Gitea
container is required; without it, caloron sprint aborts with
instructions. Start one with:
docker run -d --name gitea -p 3000:3000 -p 222:22 gitea/gitea:1.22
Set GITEA_TOKEN (or accept the dev-mode default) and configure your
project with caloron config set repo <owner>/<repo> pointing at a
repo you've created in that Gitea instance.
Bypass the preflight with caloron sprint --skip-gitea-check if you
intentionally want to run without version control (agent still runs;
all git/issue/PR calls become no-ops).
Sandbox
On Linux, caloron sprint runs each agent inside a bwrap (bubblewrap) sandbox. On macOS and other systems where bwrap is unavailable, it falls back to a no-op passthrough script so pip install caloron-alpibru works out of the box. Override with SANDBOX=/path/to/your-sandbox.sh if you need custom isolation.
Project Structure
orchestrator/ Sprint runtime (Python)
orchestrator.py Main loop: PO → agents → PRs → reviews → retro
skill_store.py Registry of skills/MCPs (18 built-in, user-extensible)
hr_agent.py Assigns skills + model + framework per task
agent_configurator.py Writes CLAUDE.md/.cursorrules/GEMINI.md + MCP configs
agent_versioning.py Tracks agent evolution across sprints
template_store.py Project scaffolds (YAML templates + LLM generation)
templates/ Project templates (user-extensible YAML)
fastapi.yaml FastAPI + ruff + pytest + Dockerfile
fastapi-postgres.yaml + SQLAlchemy + Alembic + docker-compose
python-data.yaml pandas + data dir + fixtures
nextjs.yaml Next.js 14 + TypeScript + Tailwind
rust-cli.yaml clap + clippy + fmt CI
stages/ Noether Python stages (stdin JSON → stdout JSON)
dag/ DAG evaluation, completion, validation
github/ GitHub/Gitea API operations
supervisor/ Health checks, interventions, messaging
retro/ Feedback, KPIs, report generation
kickoff/ Repo context, DAG generation
compositions/ Noether composition graphs (JSON)
shell/ Thin Rust binary (axum HTTP server)
scripts/ Sandbox (bubblewrap on Linux, passthrough on macOS/other)
deploy/ Docker Compose + Kubernetes Helm chart
demo/ Asciinema recording script
Metadata
Release files for caloron-alpibru 0.4.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| caloron_alpibru-0.4.2.tar.gz | 120.6 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| caloron_alpibru-0.4.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 209.1 kB
Release files / caloron_alpibru-0.4.2.tar.gz
| Download URL | caloron_alpibru-0.4.2.tar.gz |
|---|---|
| Size | 120.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c8a0a9c75fb64fa174eba8a53c92a05cf11af1c87f7a90a7c3119a7bc5aab6af
|
|
BLAKE2b-256 checksum How to use checksums |
89d85864448c0de388b23e284e6741711b16d53b8f70c543052e826c17b27a9d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Apr 16, 2026.
Transparency logRelease files / caloron_alpibru-0.4.2-py3-none-any.whl
| Download URL | caloron_alpibru-0.4.2-py3-none-any.whl |
|---|---|
| Size | 88.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
8b619ffbcf334a44d706e33e1223e99430f7b314a82649c05acab14d5305b171
|
|
BLAKE2b-256 checksum How to use checksums |
2f6641b77fd5f7add582027288fbdce9996e7a704dc929fbcbcc0adc26773ade
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Apr 16, 2026.
Transparency log