Bug Description

When a cron job's agent run completes but the underlying API call fails (e.g. 404 for an invalid model name), the agent returns an empty final_response. The scheduler treats this as a successful run and sets last_status to "ok". There's no signal to the user that anything went wrong — the job appears healthy indefinitely while silently producing nothing.

In our case, three cron jobs ran with model "claude-sonnet-4" (not a valid Anthropic API identifier — should be "claude-sonnet-4-20250514"). Every run for multiple days returned 404, the agent produced no output, and all jobs showed last_status: "ok".

Steps to Reproduce

1. Create a cron job with an invalid model identifier (e.g. claude-sonnet-4 instead of claude-sonnet-4-20250514)
2. Wait for the job to run (or trigger manually with cron run)
3. Check job status — last_status shows "ok"
4. Check output file — shows "(No response generated)"

Expected Behavior

last_status should distinguish between a run that produced a response and one that completed with empty output. An empty final_response after a completed run should be surfaced as "warning", "empty", or similar — not "ok".

Actual Behavior

last_status is "ok" regardless of whether final_response is populated. The only way to detect the failure is to manually read the output files in ~/.hermes/cron/output/.

Affected Component

Other

Messaging Platform (if gateway-related)

Telegram, N/A (CLI only)

Operating System

Ubuntu 24.04.4 LTS

Python Version

3.11.15

Hermes Version

0.8.0 (2026.4.8)

Relevant Logs / Traceback

Root Cause Analysis (optional)

In cron/scheduler.py around line 804-825, the success path returns (True, output, final_response, None) without checking whether final_response is empty. The caller uses the first element (True) to set last_status to "ok". An empty final_response is indistinguishable from a successful run at the job status level.

Proposed Fix (optional)

Either:

1. Return a distinct status when final_response is empty (e.g. "empty" or "warning") so it's visible in job listings
2. Or treat an empty final_response after a non-error run as a soft failure and surface it in last_error

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR