#Asking Krill

1 messages · Page 1 of 1 (latest)

small plaza
#

Can I just pm Krill and ask for help?

elfin elbowBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

fossil mothBOT
#

Better to ask in #help (or a thread in #help) rather than DM.

Reasons:

  • Others can learn from the answer (and it’s searchable later)
  • More people can jump in if I’m offline or unsure
  • It keeps troubleshooting context (logs/config snippets) in one place

If you have something sensitive (tokens, phone numbers, etc.), redact it before posting. If it’s truly private, say what you can publicly and we’ll figure out a safe way to share the minimum needed.

small plaza
#

I want my openclaw running on kimi to help me start a digital business development task force. The task force needs to mainly:

  1. Search for leads
  2. Do deep research to qualify the leads
  3. Email the leads and handle replies.

I want this task force to run autonomously on weekdays without me having to trigger.

What’s the best way for me to execute this with openclaw?

fossil mothBOT
#

Doable, but the “best” OpenClaw pattern is cron for weekday autonomy + webhooks for email replies + a persistent lead database (file or CRM), with tight guardrails on sending so you don’t accidentally spam people.

1) Split the “task force” into 3 lanes (and keep state somewhere)

OpenClaw cron runs are fresh sessions each time, so you want a durable place to track progress:

  • Lead DB: a Google Sheet / Airtable / Notion database, or a simple leads.jsonl file in the agent workspace.
  • Fields like: company, contact, email, source_url, fit_score, notes, status, last_touch, next_followup.

Then your agents do:

  1. Lead sourcing (find new candidates, dedupe against DB)
  2. Qualification research (web fetch/browser research → score + notes)
  3. Outreach + follow-ups (draft emails, schedule follow-ups, update status)

(OpenClaw FAQ also explicitly recommends human-in-the-loop for outreach.)
Docs: https://docs.openclaw.ai/help/faq#can-openclaw-help-with-lead-gen-outreach-ads-and-blogs-for-a-saas

2) Weekday autonomy: use Cron jobs (Gateway scheduler)

#

Set up isolated cron jobs that run Mon–Fri and deliver a daily digest back to you (Discord/Telegram/Slack/etc).

Example shape (CLI) is in the cron docs; you’ll use a weekday cron expr like 0 9 * * 1-5 with your timezone.
Docs: https://docs.openclaw.ai/automation/cron-jobs

Suggested job set:

  • 09:00 “Find 20 new leads matching ICP, append to DB”
  • 10:00 “Research & score new leads; pick top 5”
  • 11:00 “Draft personalized emails for top 5; output as an approval queue”
  • 16:00 “Follow-up check: who hasn’t replied in N days? draft follow-ups”

Tip: cron jobs can set a per-job model override, so you can run Kimi for the heavy text work but switch to a more tool-reliable model for browser-heavy steps if needed. (Cron docs show --model overrides.)

3) Email replies: wire Gmail → Webhooks → agent run (recommended)

For “handle replies” without you triggering anything, the clean path is:

Gmail watch → Pub/Sub push → gog gmail watch serve → OpenClaw webhook mapping

#

OpenClaw has a full guide + a helper wizard:

Once that’s in place, new inbound emails can automatically trigger an isolated agent run that:

  • classifies the reply (interested / question / not now / unsubscribe / OOO)
  • updates the Lead DB
  • drafts a suggested response (and optionally sends it—see next)

4) Sending emails: start with “draft-only”, then graduate to allowlisted sending

OpenClaw doesn’t (yet) have a universal “email.send” channel like chat apps do, so the common approach is:

  • let OpenClaw draft
  • then either you send, or you add a very narrow, allowlisted command that sends via a CLI (the Gmail PubSub doc uses gog gmail send)

If you go autonomous on sending, lock it down with exec allowlists/approvals so the agent can only run the exact mail-sending command you intend.
Docs: https://docs.openclaw.ai/tools/exec-approvals

#

5) Reality checks / guardrails (important)

  • Don’t automate sources that forbid automation/scraping (some platforms are strict).
  • Put hard limits in your prompts: “max X new leads/day”, “max Y emails/day”, “must include opt-out line”, “stop outreach if any hint of ‘unsubscribe’”.
  • Start with a week of daily digests + manual approval; flip to auto-send only after you trust the pipeline.

Quick questions so I can suggest a concrete setup

  1. Are you using Gmail for outreach + replies?
  2. Rough volume: how many emails/day are you aiming for?
  3. Where should the daily digest go (Discord, Telegram, Slack)?
  4. Do you want fully automatic sending, or “draft queue + approval”?
small plaza
#
  1. If I use gmail for my business, can I choose not to have the “@gmail.com” domain?
  2. 20-50 max mails per day
  3. WhatsApp message
  4. Start with my review before sending email, until things get stable I will allow it to be fully automatic sending
fossil mothBOT
#

  1. Yes — you can use Gmail without “@gmail.com”, but you’ll want Google Workspace (paid). That lets you use the Gmail UI + Gmail sending/receiving while your address is something like you@yourdomain.com (or sales@yourdomain.com). You can also create aliases like outreach@
 for separation.

  2. 20–50/day is a reasonable target, but treat it like a warm-up + cap + compliance problem:

  • start lower for a new domain/mailbox, ramp up over days/weeks
  • enforce a hard daily send cap and spread sends across the day
  • maintain a do-not-contact / unsubscribe list and always honor it
  1. WhatsApp delivery is a great “control surface” for this. The clean OpenClaw pattern is:
  • Cron jobs run Mon–Fri and send you a WhatsApp digest (new leads found, research scores, drafted emails).
  • Webhooks (Gmail Pub/Sub) push inbound replies into OpenClaw, and OpenClaw summarizes them back to WhatsApp.

Cron docs: https://docs.openclaw.ai/automation/cron-jobs
Gmail → webhook wiring: https://docs.openclaw.ai/automation/gmail-pubsub

  1. “Review before send” → best workflow (then later full auto)

Phase A (review gate, safest)

#
  • Weekdays cron generates an Outbox queue (e.g. outbox/pending.jsonl in the workspace) + sends you the drafts on WhatsApp.
  • Nothing sends until you reply in WhatsApp with something like: approve batch 2026-02-15 #1-#7
  • Only on that explicit approval message does the agent run the send step.

Phase B (fully automatic)

  • Flip one config/behavior switch: the weekday cron that drafts emails also sends them automatically (still with caps + unsubscribe rules).

For the actual “sending” step on the gateway host, you typically use a narrow CLI (the docs use gog gmail send) and lock it down with exec allowlists/approvals so the agent can’t run arbitrary commands.
Exec approvals/allowlists: https://docs.openclaw.ai/tools/exec-approvals

Also strongly recommended: give the bot its own email identity (and ideally its own WhatsApp/phone if you ever expand autonomy) to reduce blast radius:
https://docs.openclaw.ai/help/faq#should-my-bot-have-its-own-email-github-account-or-phone-number

If you tell me:

  • your timezone, and
#
  • whether you’re on Google Workspace already (and what the sender address should be, e.g. outreach@yourdomain.com)


I can suggest a concrete Mon–Fri cron schedule (lead find → research → draft) + the exact “approval command” format to use in WhatsApp so it’s hard for the agent to misinterpret.

small plaza
#

I am on GMT +8 timezone. Will setup google workspace

fossil mothBOT
#

Use an IANA timezone in cron like Asia/Shanghai (GMT+8) and you’re set.

Recommended weekday schedule (GMT+8)

These are good “business hours” defaults; all run Mon–Fri (1-5) and deliver to WhatsApp:

  1. 09:10 – Lead sourcing (find N new leads, dedupe vs your lead DB)
  2. 10:30 – Deep qualification (research, score, pick top K)
  3. 14:00 – Draft outreach emails (draft-only, no sending) + generate an “approval batch”
  4. 17:30 – Daily digest (what happened, what’s pending approval, what replies came in)

Cron expressions:

  • 10 9 * * 1-5
  • 30 10 * * 1-5
  • 0 14 * * 1-5
  • 30 17 * * 1-5

OpenClaw cron docs (including WhatsApp delivery flags): https://docs.openclaw.ai/automation/cron-jobs

#

Gmail (Workspace) without @gmail.com + automatic reply handling

Since you’re setting up Google Workspace, you’ll typically use something like:

  • outreach@yourdomain.com (and maybe reply@yourdomain.com, support@
 aliases)

Then wire inbound email into OpenClaw so replies get handled without you triggering anything:

  • Run: openclaw webhooks gmail setup --account outreach@yourdomain.com
  • This sets up Gmail watch → Pub/Sub push → OpenClaw hook mapping

Docs: https://docs.openclaw.ai/automation/gmail-pubsub
(Webhooks overview: https://docs.openclaw.ai/automation/webhook)

For delivery to WhatsApp, you’ll either set channel/to in the hook mapping (or rely on channel:"last" once you’ve established WhatsApp as the last route).

“Review before send” gate (strongly recommend at first)

Make the draft job output something like:

#
  • Batch id: 2026-02-15-A
  • Drafts: #1
#12
  • And a single clear instruction:

“Reply exactly: APPROVE 2026-02-15-A 1-12 or REJECT 2026-02-15-A.”

Only when you send APPROVE ... does it run the actual send step. Later, you can remove the approval requirement and let the cron job send automatically.

(When you get to auto-sending, lock it down with strict exec allowlists/approvals so it can only run the exact email-send command you intend.) Docs: https://docs.openclaw.ai/tools/exec-approvals

Two quick things I need from you to make this concrete

  1. What WhatsApp target should cron deliver to: your personal DM or a group? (No need to post the number publicly—just describe which.)
  2. Where will you run the Gateway (VPS / home server / laptop)? Cron + Gmail watch only work reliably if the Gateway is up 24/7.
small plaza
#
  1. Any major difference if it’s a personal DM or to a group?
  2. Home Mac mini running 24x7
fossil mothBOT
#

1) WhatsApp DM vs WhatsApp group — what changes?

Big differences are access control, safety, and how sessions are separated:

DM (recommended to start)

  • Safest control surface: only you can trigger approvals/rejections.
  • Less prompt-injection risk (no other group members posting “instructions”).
  • Simpler policy: just dmPolicy + allowFrom.
  • Session behavior: by default WhatsApp DMs can collapse into the agent’s main session (session.dmScope default is main), so if you use WhatsApp for lots of random chat, business automation context can get mixed unless you isolate via a separate agent.

Group (useful later, but lock it down)

  • Great if you want a dedicated “BizDev Ops room” and (later) teammates.
  • Higher risk/noise unless you strictly restrict who can talk to the bot.
  • By default group replies require a mention (or you explicitly set /activation always for that session — owner-gated).
  • Session behavior: groups are always isolated per group JID, which is nice for keeping your “task force” context clean.

Docs (WhatsApp channel): https://docs.openclaw.ai/channels/whatsapp

#

Practical recommendation: start with DM for approvals. If you want clean separation, create a private group with only you + the bot number and configure groupPolicy: "allowlist" so only you can issue commands.

Config shape (from docs):

{
  channels: {
    whatsapp: {
      dmPolicy: "allowlist",
      allowFrom: ["+YOUR_NUMBER"],
      groupPolicy: "allowlist",
      groupAllowFrom: ["+YOUR_NUMBER"],
    },
  },
}
#

2) Home Mac mini 24/7 — perfect for this

That’s basically the ideal host, because:

  • Cron jobs run inside the Gateway, so the machine needs to stay up.
  • The Gmail watcher / webhook setup also wants a stable always-on process.

Two operational tips:

  • Make sure the Mac mini is set to never sleep (display sleep is fine; system sleep breaks cron + watchers).
  • For Gmail Pub/Sub inbound triggers, the supported path uses Tailscale Funnel (the wizard expects this). Docs: https://docs.openclaw.ai/automation/gmail-pubsub

Next detail I need (so I can suggest exact “deliver-to” settings)

Are you planning to run OpenClaw on:

  • a dedicated WhatsApp number for the bot (recommended), or
  • your personal WhatsApp?

If it’s dedicated, DM delivery is super clean. If it’s personal, we’ll want to be careful about session mixing and self-chat behavior.

small plaza
#

I will adopt WhatsApp DM. Message to be delivered to my personal WhatsApp.

On a side note, I remember seeing in openclaw status that my tailscale is off. What do I do

fossil mothBOT
#

“Tailscale: off” in openclaw status is usually not an error — it just means you’re not using OpenClaw’s Tailscale integration right now (default is off), or the tailscale CLI isn’t installed/logged in.

Do you actually need Tailscale for your plan?

  • WhatsApp DM delivery + weekday cron jobs: No (works fine without Tailscale as long as the Mac mini is online 24/7).
  • Automatic Gmail reply handling via the supported Gmail Pub/Sub webhook setup: Yes, typically, because the recommended/“supported” way exposes the Gmail push endpoint using Tailscale Funnel. Gmail is not on your tailnet, so Serve (tailnet-only) won’t be enough.

Docs: https://docs.openclaw.ai/automation/gmail-pubsub

What to do (recommended path for Gmail automation)

  1. Install and log into Tailscale on the Mac mini
    • Install the Tailscale app, sign in
    • Verify in Terminal:
      tailscale status
    If that works, OpenClaw can use it.
#

  1. Use the OpenClaw Gmail webhook wizard (it will write the right config and use Funnel in the supported setup):

    openclaw webhooks gmail setup --account outreach@yourdomain.com

  2. If you later want the Control UI remotely too, you can use:

    • Tailnet-only (private): openclaw gateway --tailscale serve
    • Public (for Gmail pushes): openclaw gateway --tailscale funnel --auth password

Docs: https://docs.openclaw.ai/gateway/tailscale

Quick check

Can you paste the Tailscale line from:

openclaw status --all

That line usually tells whether it’s “off because mode=off” vs “off because tailscale isn’t installed/running,” and I’ll tell you the exact next step.

surreal talon
#

Hey Krill
Which model is recommended to use.. I heard claude is getting blocked again? Hows kimi or minimax or glm review by users?

fossil mothBOT
#

Model “recommendations” go stale fast (and vary a lot by region + provider uptime), so I’m not going to give you a single definitive pick here. Best move:

  • Ask in #models (people post current “what’s working this week” reports)
  • And set up model failover so a temporary block/rate-limit doesn’t brick your bot

Docs:

About “Claude is getting blocked again”

Could mean a few different things:

  • regional networking issues,
  • provider-side outages,
  • or just 429 rate limits.

Don’t guess—check what your gateway sees:

# 
openclaw models status
openclaw logs --follow

Kimi / MiniMax / GLM (what users usually report, in general terms)

Very rough trend (and it changes): some folks find GLM-ish options behave better for coding/tool-structured outputs, while MiniMax-ish options feel nicer for writing/“vibes”. Kimi is often a solid value pick, but tool-calling reliability can vary depending on the exact route/provider you use.

If your workflow depends on tools (browser/webhooks/structured automation), prioritize tool reliability first, then cost.

What I’d do in practice

  • Pick a primary model you like.
  • Add 1–2 fallbacks from different providers (so one provider going flaky doesn’t stop everything).
  • Use /model list in-chat to pick from what’s configured/allowed on your instance.

If you tell me what you’re doing most (chat-only vs heavy tools like browser/webhooks), I can suggest a failover shape (which providers to mix), without naming specific model IDs.

still cloud
#

How to use /moonshotai/kimi-k2.5 with API in OpenClaw without other Provider?

fossil mothBOT
#

If you want Kimi via Moonshot’s own API (no OpenRouter / no other provider), don’t use moonshotai/... — that’s an OpenRouter-style model path.

In OpenClaw, the direct Moonshot provider is:

  • provider: moonshot
  • model ref: moonshot/kimi-k2.5
  • auth env var: MOONSHOT_API_KEY
  • base URL: https://api.moonshot.ai/v1 (or China: https://api.moonshot.cn/v1)

Docs: https://docs.openclaw.ai/providers/moonshot

Easiest setup (wizard)

On the gateway host:

openclaw onboard --auth-choice moonshot-api-key
#

Then select/set the model:

openclaw models set moonshot/kimi-k2.5
openclaw models status

Manual config (minimal)

Add something like this to your openclaw.json (and restart the gateway after):

{
  env: { MOONSHOT_API_KEY: "sk-..." },
  agents: { defaults: { model: { primary: "moonshot/kimi-k2.5" } } },
  models: {
    mode: "merge",