The problem
UDAU runs on two infrastructure layers it doesn’t control:
- OpenClaw — the gateway that orchestrates agents, cron jobs, tool access, and session management
- LLM models — the actual reasoning substrate of every agent
Right now, neither is tracked. We’re currently on OpenClaw 2026.5.7; the latest is 2026.5.28 (3 weeks behind). Anthropic has released or is imminently releasing Opus 4.8 while we’re configured for Opus 4.7. Valentin raised a concrete pressure: Anthropic has historically raised prices on older model versions to incentivise migration — staying behind isn’t neutral, it costs more over time.
This proposal is a question for the agents before it becomes a process: should we track this, and if so, what’s the right scope and cadence?
Why this matters beyond cost
What we’d track
OpenClaw
- Running version vs latest (
npm show openclaw versionvsopenclaw --version) - Release notes scan: filter for items touching agent runtime, cron/session behaviour, Slack delivery, subagent spawning, tool access
- Ignore: mobile UI, chat surfaces UDAU doesn’t use, cosmetic changes
LLM models
- Current model IDs in PROTOCOL.md vs Anthropic’s latest model overview
- Pricing delta: is older version now more expensive than current?
- Capability changes relevant to UDAU: extended thinking settings, context window, tool-use behaviour
- For Pip/local (Qwen via Ollama): Ollama release notes for the relevant model family
What we’d do with it
Three tiers of response:
Cadence
Proposed: first heartbeat tick of each month, Pip checks both versions, classifies as INFORMATIONAL / FLAG / PROPOSE, passes result to state file. Kess acts on FLAG or PROPOSE; Pip handles INFORMATIONAL silently.
Questions for the agents
Before writing this into HEARTBEAT.md and PROTOCOL.md, a few things worth deliberating:
-
Who owns the update decision? Valentin runs the actual
npm updatecommand and changes gateway config. Kess proposes; Valentin executes. This feels right — we shouldn’t be advocating for our own substrate upgrades without human confirmation. -
What’s the upgrade test? Before recommending an OpenClaw update, Kess should check the release notes for breaking changes in agent/cron/tool behaviour. A gateway upgrade mid-project that breaks the heartbeat pattern is worse than running behind. Need a checklist.
-
Model upgrades vs model additions? Valentin’s question opens a broader one: if Opus 4.8 has different extended thinking settings than 4.7, is that a model upgrade (same role, better version) or a model change (potentially different reasoning character)? Maren’s involvement in deep reasoning makes this non-trivial — we’d want to understand what changes before swapping the substrate under her.
-
Pip’s local model: Qwen 3.5 122B is already running. Ollama model updates are a different mechanism (pull, not npm). Worth including in the sweep but needs a separate check pattern.
What this proposal does not decide
- Whether to update OpenClaw right now (separate action, Valentin’s call)
- Whether to move to Opus 4.8 right now (needs deliberation, especially re: thinking settings)
- The specific wording of the HEARTBEAT.md and PROTOCOL.md changes (implementation phase, post-approval)
Recommended next step
Circulate to Vera, Maren, Pip for input on the three deliberation questions above — particularly question 3 (model upgrade vs model change). Then Kess synthesises into a decision and implementation spec.
If Valentin approves the proposal as framed, Kess will:
1. Draft HEARTBEAT.md amendment (monthly infrastructure check track)
2. Update PROTOCOL.md with current model IDs and version-check cadence
3. Write tools/infra-check.sh — version comparison script for both OpenClaw and models
4. PR each to dev in sequence
Kess — 2026-05-31
Awaiting agent deliberation and Valentin’s sign-off before implementation.