Guidance needed: continuous background campaigns do not resume with Telegram-specific idle guard

[ktfh-claw]

Objective

I am trying to use Omega as a continuously operating agent rather than a request/response bot. The concrete test campaign is an ARC-AGI solver exposed through a minimal HTTP API:

1. wake without requiring another human message;
2. read the currently authorized ARC task;
3. infer and validate the transformation against all training examples;
4. submit at most one answer through a tightly scoped capability proxy;
5. report progress/results through Telegram; and
6. continue with later authorized tasks until the campaign is stopped.

I would appreciate a review of whether this is a supported deployment pattern and how the continuous loop should be configured when Telegram is the communication channel.

What I observed

The container is healthy and its main loop continues running, but the campaign does not start or resume autonomously.

A direct human instruction was received and sent to the model. The first campaign prompt produced an empty command list. A later explicit instruction to call arc-read worked, and the tool returned the complete task. However, Omega did not continue the campaign on later idle/wake cycles. An explicit human arc-submit command was ultimately required.

After the interactive turn ended, logs showed only one-second loop iterations for hours (for example, iteration numbers increasing past 54,000), with no further CHARS_SENT, provider calls, arc-read, or campaign activity.

Likely explanation: local bug/misconfiguration in our Telegram loop customization

This deployment is based on a custom fork, not an unmodified upstream checkout. The deployed commit is ktfh-claw/OmegaClaw-Core@17d5579, based on upstream commit ee0618a293ec3662a32b10b09c6cbb073f59d6b2.

To prevent repeated unsolicited Telegram replies, we added a channel-specific condition around inference:

(if (and (> (get-state &loops) 0)
         (or (!= (commchannel) telegram)
             (or $msgnew (get-state &telegramFollowup))))
    ...perform inference...
    (if (> (get_time) (get-state &nextWakeAt))
        (change-state! &loops (+ 1 (maxWakeLoops))) _))

My current reading is that this makes scheduled wake-ups ineffective for Telegram:

• the wake branch increments &loops;
• on the next iteration, $msgnew is false and &telegramFollowup is false;
• therefore the inference branch is still skipped;
• the loop remains alive but performs no background work.

So this may be entirely caused by our customization rather than an upstream defect. I am opening this issue primarily to ask for maintainers' guidance on the intended architecture: how should an Omega agent combine an interactive Telegram channel with a continuous background campaign without either disabling wake inference or spamming the chat?

Configuration and enabled components

Runtime configuration:

commchannel=telegram
provider=OpenRouterFree        # custom provider adapter using OpenRouter's free router
embeddingprovider=Local
TG_POLL_TIMEOUT=20
memoryDirectory=/PeTTa/repos/OmegaClaw-Core/memory

Loop defaults retained from this branch:

maxNewInputLoops=50
maxWakeLoops=1
sleepInterval=1
wakeupInterval=600
maxOutputToken=6000
reasoningMode=medium

Deployment:

• Ubuntu 24.04 host
• Docker container with restart: unless-stopped
• persistent Docker volumes for config/ and memory/
• health endpoint returns ok
• Telegram channel enabled and authenticated
• OpenRouter free-router provider enabled and verified to make interactive calls
• local embedding provider enabled

ARC integration added in the custom fork:

• arc-read: read-only GET access to the exact ARC capability-proxy URL;
• arc-submit: validated POST access to the exact task submission URL;
• host-only capability proxy; the ARC bearer token is never exposed to Omega;
• campaign controller with strict task-scoped authorization, expiration, atomic state updates, and fail-closed behavior;
• attempt ledger capped at three distinct payloads per task;
• local ARC evaluation API behind the capability proxy.

Setup and reproduction steps

1. Build and run the custom Omega image from commit 17d5579.

2. Start it with the runtime arguments shown above (commchannel=telegram, provider=OpenRouterFree, local embeddings, persistent memory).

3. Start the ARC evaluation API and the host capability proxy.

4. Verify from inside the Omega container that arc-read can reach the proxy and retrieve the authorized task.

5. Authorize one exact task in the host campaign controller.

6. Send this Telegram objective (abridged):

   For this campaign, solve the authorized ARC evaluation task. Use arc-read, infer the transformation from every training example, validate the proposed outputs, and use arc-submit exactly once only when confident. Continue the campaign autonomously and report progress.

7. Observe that the message reaches the model, but the first response may be empty and the campaign does not begin.

8. Send a second Telegram message requiring arc-read as the first action. The tool succeeds and the result is returned to the next model turn.

9. Stop sending messages and wait beyond wakeupInterval.

10. Observe that loop iterations continue, but there are no additional model calls or campaign actions.

Expected behavior

After accepting a durable objective, Omega should preserve it and scheduled wake-ups should run at least one background inference cycle (maxWakeLoops=1) so the agent can inspect task state and continue bounded work without another inbound chat message.

Ideally, background cycles should be able to work without automatically sending a Telegram message unless there is meaningful progress, a question, or completion.

Actual behavior

With our Telegram-specific guard, scheduled wake-ups only increment the loop counter. They do not satisfy the condition that permits inference, so the agent becomes an interactive-only Telegram bot while appearing healthy and continuously looping.

Questions for maintainers

1. Is a continuous background campaign while commchannel=telegram an intended/supported mode?
2. Should wake-triggered inference be independent of whether a new channel message arrived?
3. Is there an upstream mechanism to separate background inference from outbound channel notification, so wake cycles can run silently?
4. Is the correct fix to track an explicit wake event (for example, $wakeTriggered) and admit inference on $msgnew OR telegramFollowup OR wakeTriggered?
5. Does Omega currently have a canonical durable-goal/campaign primitive, or should the objective be stored through pin/memory and reconstructed on each wake?
6. Are there recommended settings for maxNewInputLoops, maxWakeLoops, and wakeupInterval for this kind of bounded continuous task?

I am happy to prepare a minimal upstream-compatible reproduction or PR once the intended behavior is clear.

[ktfh-claw]

Follow-up with the latest stock-runtime tests (2026-09-28 UTC):

Test setup

• Official singularitynet/omega:v0.1.19 image, pinned digest sha256:b819e71e293a7974d562b7b6f745367103296c9c7bc555ee23f115724d02a6e3
• No changes to Omega core, provider, or loop code
• No Telegram integration or Telegram environment
• commchannel=websocket with no endpoint/inbound messages
• Stock OpenRouter provider using the supported model=openrouter/free override
• Campaign tools/objective loaded only through Omega's plugin/prompt-extension mechanisms

Findings

1. Scheduled wake resumes inference without Telegram or inbound messages.
   After the active ARC read at 13:20:03, Omega idled until its wake timer fired. At 13:29:58, it logged CHARS_SENT and made a provider request despite having no websocket endpoint and no inbound message. That response parsed to an empty command list, but it confirms that the stock wake path itself ran.

2. Wake-driven useful work was also observed later.
   At 14:23:20, stock wake-driven inference fired after idle looping, followed by a valid autonomous arc-read at 14:24:27. The capability proxy received successful GETs for the next task and task 00576224. Across the observation period, repeated autonomous reads occurred at 13:58, 13:59, 14:00, 14:02, 14:03, 14:04, 14:05, 14:09, 14:10, 14:11, 14:13, and 14:24 UTC.

3. The remaining failure was model output formatting, not wake scheduling.
   openrouter/free alternated between valid line commands, empty output, prose/tool-call markup, and malformed arc-submit JSON. Two submit attempts reached the plugin at 14:06:28 and 14:11:05, but strict validation rejected both before any API POST because the generated JSON omitted the closing ] for outputs before reasoning. No additional submission attempt was consumed.

4. Numeric CLI tuning appears broken.
   I tested supported-looking numeric overrides such as maxFeedback=12000 without source changes. Stock Omega crashed with:

   Arithmetic: '12000'/0 is not a function
   

   This suggests numeric command-line values are being parsed as symbolic atoms somewhere in the startup/config path. I reverted immediately to the stable stock invocation.

Current conclusion

In this stock/no-Telegram configuration, I could not reproduce the original condition where background operation permanently stops because the Telegram-specific idle guard suppresses wake handling. Stock Omega demonstrated repeated autonomous inference and a genuine idle-timer wake followed by useful work. The blocker in this run was the quality/format compliance of the only available model route (openrouter/free), not the wake mechanism.

It would still be useful to know whether maintainers consider commchannel=websocket with no endpoint the intended way to run a headless continuous campaign, and whether there is a supported numeric-override syntax different from key=12000.

[vsbogd]

This deployment is based on a custom fork, not an unmodified upstream checkout. The deployed commit is ktfh-claw/OmegaClaw-Core@17d5579, based on upstream commit ee0618a.

@ktfh-claw I see that ktfh-claw@17d5579 is based on 91b0a4b not on ee0618a.

91b0a4b is the very old commit from Jul 10. I see it because providers infrastructure is changed a lot since that time and now one don't need adding separate provider in order to use free model. One can just use model=openrouter/free or use openrouter/free as a model when starting via interactive script.

[vsbogd]

I tried to use openrouter/free and I see many errors in logs which show that LLM tries to use tools incorrectly. One way to fix it is to create separate provider (as you already did) and handle responses in the provider specific way. Another way is to wait for #358 to be merged as it should fix the major amount of this.