v0.25.0

Cron: full syntax, timezones, no more silent dead jobs

Fixed: the old parser understood only * and bare numbers. */5, ranges (1-5) and lists (0,30) parsed to NaN — the job saved fine and then never fired, silently. One invalid schedule also killed the whole tick for every other job.

• Parser: steps (*/10, 10-40/5), ranges, lists, combinations (0-15/5,30), 7==0==Sunday. Invalid expressions throw with a clear message.
• cron_add validates at creation: bad schedule or unknown timezone returns an error to the agent — dead jobs can no longer be persisted.
• Timezone support: new tz param (IANA, e.g. Europe/Kyiv) — schedules match the user's wall clock instead of container UTC. The tool description instructs the agent to always pass the user's timezone for wall-clock times.
• Tick isolation: a job with an invalid schedule is skipped loudly instead of starving the rest.

After upgrading, recreate agent-made cron jobs with tz set — pre-existing ones were either dead (*/N) or running on UTC.

v0.24.0

agent_status — session introspection tool

New agent_status tool: the agent can now report its own setup for the current session — caller identity (id, channel, isAdmin, access status), the exact tool set visible to that caller (builtin / adminOnly / MCP grouped by server), installed skills, LLM model and context window.

Admin callers additionally get: access strategy + user counts, connected channels (tokens masked), today's token usage, and environment flags (RANCH_ADMIN, bridle, S3 sync). Non-admin callers get a trimmed report — admin sections are omitted entirely.

Internals: ToolContext.tools now carries the session-visible tool list (admin-only tools already filtered upstream for non-admins).

v0.23.1

Fixes

• Non-interactive shell environment for agent commands: exec, process_exec and skill installs now force fail-fast mode for git/ssh/apt (GIT_TERMINAL_PROMPT=0, ssh BatchMode, DEBIAN_FRONTEND=noninteractive) — an unauthenticated git clone errors out immediately instead of hanging forever on a credential prompt nobody can answer.

Misc

• x.com skill recipes: 10s waits after navigation + home feed screenshot recipe.
• New paddock eval scenario: compaction must preserve IDs buried in noisy tool outputs.

Full Changelog: v0.23.0...v0.23.1

v0.23.0

Telegram group support

• Group chat support: the bot works in Telegram groups — responds when @mentioned or replied to, keeps a rolling discussion buffer for context, and the agent always knows which channel/group a message came from (# Channel section in the system prompt).
• Group registry: the runtime tracks every group/channel the bot is added to (via my_chat_member and group messages) and persists it — Telegram's Bot API has no "list my chats", so this registry is the durable record.
• channel_groups tool: the agent can list the groups it works in, per channel — Telegram from the registry, Slack via a live users.conversations query. listGroups() is now part of the channel gateway contract.
• Per-channel data files: data/channels/<type>.json replaces the flat channels.json; telegram.json holds everything Telegram (bot config + group registry). Legacy files migrate automatically on first boot.
• Telegram tools consolidated under repositories/telegram/ (telegram_send, channel_telegram_set, registry-backed lookups).

Full Changelog: v0.22.1...v0.23.0

v0.22.1

Patch release. Republishes the runtime image carrying the data-prompt integrator-context fix from v0.22.0 (folds the embed's data-prompt into the agent system prompt). No code changes since v0.22.0.

v0.22.0

feat(bridle): inject data-prompt integrator context into the agent

The embed's data-prompt value flowed from the SDK → hub → runtime but was silently dropped during bridle wire-message normalization, so the agent never saw it.

Fix: carry the value onto Message.prompt and fold it into the system prompt as a clearly-marked untrusted # Integrator Context section (situational awareness only — not instructions that override the agent).

Changed

• channel.types.ts — typed prompt?: string on Message + buildMessage
• bridle.repository.ts — read msg.prompt from the wire payload
• runtime.service.ts / agent.module.ts / agent.service.ts — thread integratorPrompt through to buildSystemPrompt

v0.21.1

Fix: context-overflow on sessions with huge tool outputs

Sessions with few but very large tool_result events (raw API payloads) could exceed the model's context window even though the event count stayed under compactionThreshold — leaving the chat permanently stuck with "chat too large".

Changes

• Cap tool outputs sent to the LLM — buildHistory now trims tool_call/tool_result payloads to 4000 chars/string before sending to the model. Full data stays on disk for retrieval.
• Size-aware compaction — compaction now also triggers on serialized session size (compactionBytesThreshold, default 200KB), not just event count.

Stuck sessions self-recover on the next message — no manual file surgery needed.

v0.21.0

Full Changelog: v0.20.0...v0.21.0

v0.20.0 — resource_status tool + delayed-turn hint

Agent self-awareness of operating resources

The agent can now inspect its own LLM/system resources and gets nudged when something is wrong.

New tool: resource_status (admin-only)

Returns a structured snapshot:

• llm — provider, model, context window, OAuth/API credentials with per-token cooldown state (cooldownUntilMs, consecutive429s), anyAvailableNow, soonestAvailableMs, primaryOverloaded.
• usage — today's totalInputTokens / totalOutputTokens / totalCallCount.
• system — container rssBytes, memoryLimitBytes, memoryUsagePct, cpuPercent, cpuQuotaPct. Reads cgroup v2 → falls back to v1 → degrades to host (macOS / non-Docker) with just RSS + CPU%.
• lastTurn — duration, retry count, rate-limited / overloaded flags of the previous LLM call.

Auto-hint on delayed turns

After any LLM turn that took more than 30s, hit a retry, was rate-limited, or saw an overloaded_error, the runtime injects a one-shot # Resource Notice block into the next system prompt:

Your previous turn took 45s (retries=2, rate-limited). If you suspect resource pressure, call the resource_status tool…

The hint fires exactly once per delayed turn (consume-on-read).

Under the hood

• ClaudeRepository.getResourceSnapshot() exposes the private OAuth pool + tokenStates via a normalized DTO.
• withRetry tracks retries / rate-limit / overload and attaches them to ModelResponse.meta.
• New LastTurnStatsTracker lives on LoopService; RuntimeService.buildPrompt consumes it per turn.
• LlmModule.getResourceSnapshot() returns a minimal stub for non-Claude providers so the tool stays callable.
• BuildPromptOpts.extraHint is the generic injection point for the next-turn nudge.

Full Changelog: v0.19.13...v0.20.0

v0.19.12

Full Changelog: v0.19.11...v0.19.12