@Doug Keim Thanks for the feedback — really appreciate it 🙌Good to know this is actually useful. Regarding Gemini — honestly, even OpenClaw has already removed mentions from the docs about using Google paid subscriptions, because the ban risk is pretty high. I didn’t want to push anything that could put people’s accounts at risk — especially since most people have way more than just Gemini/Antigravity tied to their Google accounts (email, etc.). So I decided not to publish anything about that for now. As for OpenRouter and free models — I actually have a draft almost ready. I basically took all the free tiers, sorted them by strength, and set up a fallback chain so that once a stronger model hits its limit, it drops to the next one. So it always tries the strongest model first, then falls back if needed — and on every new request it starts from the top again (in case limits reset). I’ll try to push it to the classroom in the next few days 👍

https://www.skool.com/ai-agents-openclaw/classroom/513b4ce7?md=09cb8315e3254aedb6f90ecc092042bd it is here :)

@Doug Keim It seems important here to distinguish between two high-level approaches — who is actually driving the agent development: 1. a technically skilled person with experience in building agents 2. a business-oriented, non-technical person In the second case, we are trying to close that gap by providing a reliable tool — our CTO agent. It evolves continuously, and based on your feedback we update it regularly. And to be honest, sometimes we even go back to square one and completely redesign it. However, this approach will always have a ceiling. The more complex the agent becomes, and the more conflicting requirements it has, the higher the probability that things will break. The alternative path is classical engineering. This is where we build agents for OpenClaw using dozens of development patterns. In this setup, the agent is not just a collection of markdown files — it includes a whole layer of additional systems: guardrails, prompt optimization, and most importantly, a closed-feedback loop testing cycle. In my opinion, this is the most critical part of agent development — with every incremental change, you run a full automated regression using a stable eval set. Overall, this is a much longer and more labor-intensive process, but it delivers significantly higher reliability and better outcomes.

Just wanted to add a couple more points here 👇 First — in Telegram privacy settings you can fully control who is allowed to message you. If you configure it properly, you can basically reduce spam to zero. Second — when working with OpenClaw, data transfer speed and responsiveness actually matter quite a bit. There’s been some recent movement where the founders are in touch and starting to align their products more closely (see screenshot attached). That usually means the ecosystem is going to grow — and I’d expect more convenient UX/tools around configuration in the near future. And lastly — Telegram invests heavily into its SDK, which gives a lot of flexibility. For example, it’s very convenient to set up a sandbox environment for testing your agent before pushing it live, or to validate changes and make sure regression doesn’t break things.