Forem: Darko from Kilo

4 Advanced OpenClaw Recipes For Personal FInance Nerds

Darko from Kilo — Thu, 09 Apr 2026 12:11:58 +0000

Budgeting apps often charge $8–15/month. They categorize your spending, show a pie chart, and send alerts when you go over. That's useful, but it doesn't solve the timing problem and a bunch of others.

The timing problem: Car registration comes in March. The dentist bill comes in August. Your insurance premium renews once a year. These are predictable expenses, but they show up on irregular schedules. Most budgets don't account for them.

We built five ClawBytes to cover parts budgeting apps skip. Each recipe can run inside KiloClaw and produces actual files you can use: spreadsheets, plans, scripts, and calendars.

Recipe 1: Budget Reality Check

More details: Budget Reality Check

This recipe builds a monthly budget that includes sinking funds. Sinking funds are monthly set-asides for irregular expenses like annual premiums, car maintenance, holidays, and medical costs. The recipe produces a cashflow plan, spending caps by category, and a stress test that shows what happens if your income drops 10%.

It also includes a weekly maintenance routine that takes about 10 minutes.

Extend it with skills:

The Excel / XLSX skill turns that structure into a working spreadsheet with formulas and auto-calculated sinking fund targets. You get a .xlsx file you can open in Excel or Google Sheets.

The Chart Image skill generates charts from your budget data. Bar charts for category spending, pie charts for fixed vs. variable allocations. These are useful if you need to share the budget with a partner or advisor.

Recipe 2: Paycheck Planner

More details: Paycheck Planner

Sometimes your total income covers your total bills, but the timing doesn't line up. Bills hit before payday. Autopays fire in the wrong order. Authorization holds reduce your balance without showing as transactions.

This recipe assigns each bill to a specific paycheck. It calculates a safe-to-spend number for each pay period and suggests timing fixes, like moving due dates or splitting payments. Most providers will move a due date if you call and ask.

The recipe works well for freelancers and gig workers with irregular income schedules.

Extend it with skills:

The Cron skill creates recurring reminders for the recipe's weekly check-in routine. The agent sets the schedule so you don't have to remember it.

The Data Analysis skill can analyze your recent income data and identify cashflow patterns. If you get paid irregularly, it can flag the weeks where you're most likely to be short.

Recipe 3: Subscription Creep Auditor

The recipe: Subscription Creep Auditor

Free trials convert to paid plans. Prices increase without notice. Small recurring charges add up over time. This recipe inventories every recurring charge and classifies each one as keep, downgrade, or cancel. It prioritizes cancellations by how much you'd save, and it includes a rotation strategy for services you only need occasionally. For example, you can subscribe to a streaming service for one month, watch what you want, cancel, and rotate to the next one.

Extend it with skills:

The Web Search Plus skill lets the agent look up current pricing and alternatives. When the recipe flags a subscription for downgrade, the agent can check what the cheaper tier includes or find a competitor with better pricing.

The Cron skill sets renewal-date reminders so you cancel before the next billing cycle. The recipe produces the dates. The skill creates the reminders.

Recipe 4: Bill Cutting Sprint

The recipe: Bill Cutting Sprint

This is a 14-day plan to reduce your recurring bills. You list your top 8 recurring costs. The recipe ranks them by potential savings and gives you daily 15-minute tasks: call a provider, use a negotiation script, compare alternatives, or cancel a service.

Insurance and internet/phone tend to have the most room for negotiation. The recipe includes call scripts. Telling a provider you're considering switching often triggers a retention offer.

Extend it with skills:

The Word / DOCX skill creates cancellation letters and negotiation scripts as Word documents. Some providers require written cancellation requests. Having a formatted letter ready removes a step.

The Data Analysis skill can track your sprint results: original bill amounts, new amounts after negotiation, and total monthly savings. After 14 days, you have a record of what changed.

The Excel / XLSX skill generates the 12-month expense map as a real spreadsheet. The skill can create a workbook with one sheet per fund, running balances, and a summary tab.

The Planning with Files skill creates structured task plans that persist across sessions. You can use it to track which funds are set up, which auto-transfers are active, and which ones still need a call to your bank.

Why This Works Without a Budgeting App

These recipes don't require you to connect a bank account or share credentials with a third-party service. You enter your own numbers. The agent produces the plan. The output is files you keep: spreadsheets, documents, calendars.

Pick the recipe that matches where you are right now:

Your budget keeps breaking → Budget Reality Check
You run out of money between paychecks → Paycheck Planner
Irregular bills catch you off guard → Sinking Funds Builder
Subscriptions are adding up → Subscription Creep Auditor
You need to free up cash soon → Bill Cutting Sprint

You can browse more recipes at kilo.ai/kiloclaw/bytes.

You Can’t Gentle Parent Your OpenClaw Bot

Darko from Kilo — Thu, 09 Apr 2026 12:06:34 +0000

I trusted my bot. It told me the email went out. I moved on. Two days later, a client asked me why they hadn't heard from me.

The email never went out.

The bot wasn't lying to me the way a person lies. It wasn't being evasive. It just... told me what it had done, confidently, and was wrong. And my instinct—the same instinct I use with my team, with my kids—was to give it another chance. Assume good intent. Rephrase more kindly next time.

That instinct will cost you.

What gentle parenting actually gets you (with a bot)

Here's what happens when you manage an OpenClaw agent like a person:

It will tell you it completed something. It didn't. Not only that, but it will skip a task you've assigned three times. It will drift from the behaviors you set up, then act like everything is fine. You will rephrase. You will add more context. Likewise, you will assume the relationship will compound over time through shared experience.

It won't.

The failure modes of an AI agent have nothing to do with emotional regulation. When your bot tells you it sent that email and didn't, it hallucinated. When it ignores a recurring task, the instruction never made it into a file that persists across sessions. There's no emotional subtext to decode. There's no trust to rebuild.

Empathy doesn't fix this. Structure does.

How OpenClaw Actually Works

So what does it actually mean that the bot "remembers" things? Every new session, your OpenClaw agent wakes up fresh. No memory of yesterday's conversation. What it has access to is a set of files in its workspace—and those files are its memory.

The key ones:

SOUL.md: behavioral core. Voice, temperament, constraints. Who the agent is, every session.
MEMORY.md: long-term memory. Facts, preferences, decisions that should survive indefinitely.
memory/YYYY-MM-DD.md: daily logs. What happened, what was decided, what's in flight.
USER.md: who you are. Your communication preferences, recurring context.
AGENTS.md: the operating contract. Priorities, workflow, quality bar.

If something isn't in one of these files, it doesn't exist for the agent. You can say it in chat all you want. If the context window fills up, if the session ends, if compaction kicks in—that instruction is gone.

This is the root cause of almost every "my bot isn't doing what I asked" problem.

Three Things That Actually Work

1. Tell it to write things down. Explicitly.

When you give an instruction you want to stick, don't just say it—tell the agent to record it. "Add to USER.md that I want short answers and copy-pasteable commands" is not the same as "I prefer short answers." The first one persists. The second one doesn't.

If a behavior is drifting, the instruction is living in chat, not in a file. Put it in a file.

2. Edit SOUL.md when behavior is fundamentally wrong

SOUL.md loads as a system-level prompt on every single interaction. It shapes everything else. If your bot keeps doing something you don't want—a tone that's off, autonomy it shouldn't have, a pattern it defaults to—that's a SOUL.md problem, not a conversation problem.

Edit the file directly. Be specific. "Never take autonomous action on email without explicit approval each time" is a SOUL.md instruction. "Be more careful" is a hope.

3. Run `/context list` before you troubleshoot anything

Before you spiral trying to figure out why something isn't working, check whether that thing is even in context. /context list shows you exactly what files are loaded and whether any are getting truncated. If MEMORY.md isn't showing up, it has zero effect. If a file is truncated, the instructions at the bottom are invisible.

This is the fastest diagnostic you have. Use it first.

The Actual Mindset Shift

A couple of things I'm not saying:

I'm not saying AI agents are bad or broken.
I'm not saying you're doing something wrong if you've been managing it like a person.
I'm not saying the relationship doesn't matter.

Here's what I am saying: managing an AI agent is less like managing a person and more like managing a system. The "relationship" is the state of the files. And that's not a downside—it's actually what makes it powerful. The memory is inspectable. You can open MEMORY.md in any text editor and see exactly what your agent knows. You can edit it, correct it, delete outdated information.

Total transparency. Total control. But only if you treat it like a system.

When something goes wrong, the question isn't "why did it do that?" It's "what file is missing or wrong?"

Your bot is not a child figuring out the world. It's a very capable agent that will do exactly what its files say—and nothing more.

The single most useful habit when you're starting out: end every session by asking your agent what it should update in MEMORY.md. That compounding context is the whole point.

How to Rewrite 1,000 Ecommerce Product Pages in an Afternoon with OpenClaw

Darko from Kilo — Thu, 09 Apr 2026 11:55:10 +0000

Most ecommerce stores are sitting on the same problem: a catalog full of product pages that nobody actually (re)wrote. These descriptions usually came from the manufacturer, or from a template that says "high-quality materials" on 400 different SKUs, or worse, from a summer intern in 2019 who no longer works there.

You probably know these pages are costing you conversions. You also know that rewriting 1,000 product descriptions by hand would take weeks (and dread the thought of doing that).

That's what this guide is for. We're going to walk through a catalog overhaul using OpenClaw recipes (pre-built AI workflows you can run on your own product data) plus community-built skills from ClawHub that extend what the recipes can do. By the end, you'll have rewritten descriptions, cleaned-up SEO, optimized images, and listings pushed to every channel you sell on.

Let's get started.

Step 1: Audit What's Broken

Before you rewrite anything, figure out where the damage is. The SEO Mechanic recipe crawls your entire store — product pages, collection pages, blog posts — and flags every SEO issue it finds. It finds missing meta titles, duplicate descriptions, missing alt text, thin content pages, broken internal links, missing schema markup, and more.

After it lists the problem, this recipe then prioritizes them by impact, so you fix the pages that matter first.

Make it better with ClawHub skills:

The SEO Content Writer & Blog Optimizer skill takes this further. Where SEO Mechanic finds the gaps, this skill helps you fill them with keyword-integrated content, optimized headers, and featured snippet targeting. Use it after the audit to turn your fix list into actual copy.

If your catalog is partially in PDFs or scanned supplier docs, the PaddleOCR Document Parsing skill extracts structured text from those files so you can feed clean data into the rest of the pipeline.

Step 2: Rewrite Every Description at Once

The Product Description Factory recipe takes your product catalog (CSV, Shopify export, spreadsheet, whatever you have) and generates unique, keyword-aware descriptions for every SKU.

You give it a few examples of descriptions you like, and it uses those as a reference. It generates the description, SEO meta title (under 60 characters), meta description (under 155), and image alt text in a single pass. Output comes back as CSV rows you can re-import directly.

The trick is to start with your top 20 products. Get the voice right on a small batch, tweak the examples, then run the full catalog in groups of 25-50. Don't try to do all 1,000 in one shot and review them later.

Make it better with ClawHub skills:

Before you write a single description, you might want to know what good looks like in your product category. The Web Scraper skill can pull competitor product pages so you can see how top sellers describe similar products. If competitors have anti-bot protections, Scrapling handles Cloudflare Turnstile and similar tools.

For sellers on TikTok Shop, the EcomSeer skill pulls trending product data, influencer analytics, and ad insights. Useful for figuring out which features to emphasize in your descriptions based on what's actually selling.

Step 3: Edit What's Already There

Sometimes you don't need to rewrite from scratch. You need to change "sale" to "clearance" across 800 products, raise prices by 10% in one collection, or update meta descriptions for an entire category.

The Bulk Product Surgeon recipe handles this. Describe the change in plain English — "add free shipping to every product title in the Summer collection" — and it executes across your entire catalog. It previews the changes before applying them, so you won't accidentally rename everything.

Make it better with ClawHub skills:

The Excel / XLSX skill is the natural companion here. If you're working with exported spreadsheets, it handles formula creation, formatting, and data validation before you re-import.

The Data Analysis skill helps when you need to make smarter decisions about what to edit — for example, identifying which products have the worst conversion rates so you prioritize those descriptions first.

Step 4: Fix Your Product Images

Your descriptions are sharp, but your images are 4MB JPEGs on a white-ish background that Amazon keeps rejecting. The Image Factory recipe batch-processes your entire image library: removes backgrounds, replaces with pure white, resizes for each marketplace's specs, compresses to under 200KB, converts to WebP, and generates alt text from product attributes.

Make it better with ClawHub skills:

This is where ClawHub skills add the most obvious value. The Image Cog skill goes beyond cleanup into actual image generation: product photography, style transfer, batch creation, and consistent visual identity across your catalog. Need lifestyle shots without a photographer? It handles text-to-image and image-to-image generation.

The Nano Banana Pro skill (79K+ downloads, one of the most popular on ClawHub) gives you access to Gemini's image model for generating and editing product images at up to 4K resolution. Pair it with Image Factory: one cleans up your existing photos, the other generates the ones you're missing.

Step 5: Push to Every Channel

Your catalog looks good on Shopify. Now you need it on Amazon, eBay, Walmart, and Etsy, each with different title formats, attribute requirements, and compliance rules. The Listing Broadcaster recipe takes your master catalog and adapts each listing for every channel you sell on.

It handles the annoying parts: character limits on Amazon titles, category-specific attributes, required bullet point formats, compliance flags. You maintain one master catalog and let the recipe handle the translation.

Make it better with ClawHub skills:

The Market Research skill helps you decide which channels are worth expanding to. It does market sizing, competitor mapping, and demand validation, so you're not listing on Walmart only to find out nobody buys your product category there.

The Marketing Strategy PMM skill helps with positioning. Different channels attract different buyers. The way you describe a product on Etsy (handmade, artisan, story-driven) is completely different from Amazon (specs, comparison, Prime-eligible). This skill helps you articulate what makes your product different on each platform.

Step 6: Close the Loop With Reviews

You've rewritten the catalog, fixed the images, pushed to every channel. Now you need social proof. The Review Loop recipe automates the unglamorous work of collecting reviews: sends a request email a few days after delivery, monitors for new reviews across all your channels, and drafts responses for anything that needs human attention.

It catches negative reviews early — before they sit unanswered for two weeks and convince 50 potential buyers to go elsewhere.

Make it better with ClawHub skills:

The Marketing Psychology skill applies behavioral science to your review request emails. Small tweaks like the timing of the ask, how you frame it, whether you reference the specific product, can meaningfully improve response rates.

The Skill That Makes Everything Better Over Time

One more ClawHub skill worth mentioning, because it applies to every step above: the Self-Improving Agent. With 355K downloads and 3,000 stars, it's the most popular skill on ClawHub for a reason.

It captures learnings, errors, and corrections across sessions. When you correct a product description's tone, it remembers. When you reject a bad image edit, it learns. Over time, your entire catalog pipeline gets better without you re-explaining your preferences every session.

The Full Pipeline

Here's what the complete workflow looks like:

Audit — SEO Mechanic finds everything that's broken
Rewrite — Product Description Factory generates new copy for every SKU
Edit — Bulk Product Surgeon handles mass changes across the catalog
Images — Image Factory cleans up and optimizes every product photo
Distribute — Listing Broadcaster pushes adapted listings to every channel
Reviews — Review Loop collects social proof and monitors feedback

Each step works on its own. Together, they're a catalog overhaul that would have taken a team weeks, finished in an afternoon.

Trinity-Large-Thinking is Free in Kilo for a Limited Time

Darko from Kilo — Wed, 08 Apr 2026 12:58:37 +0000

If you have been watching the OSS space, you know that the frontier is shifting from simple chat models to complex, reasoning-heavy agents. Last week, the team at Arcee AI made a massive contribution to that shift. They officially launched Trinity-Large-Thinking, a frontier open reasoning model built specifically for complex, long-horizon agents and multi-turn tool calling.

To celebrate the release of one of the strongest open models ever released outside of China, we are thrilled to announce that Trinity-Large-Thinking will be completely FREE to use in Kilo Code and KiloClaw for a full week, starting today, April 6th.

I know we've been launching a lot of models lately, but we're extra excited about this powerful new release from a lesser-known US lab. It's laser fast and great at a wide range of agentic tasks.

Here is a quick breakdown of why this model is a game-changer for your daily workflow, and why you should test drive it ASAP.

The Architecture: Massive Scale, Insane Efficiency

Usually, when you hear about a 400-billion parameter model, you immediately worry about latency. Arcee solved this through architectural constraint and innovative thinking about how to optimize every part of the inference process.

Sparse MoE Design: Trinity-Large-Thinking is a 398B-parameter sparse Mixture-of-Experts (MoE) model.
Active Parameters: During inference, it activates only about 13B parameters per token.
The Speed Advantage: Because of this extreme sparsity, it possesses the deep knowledge of a massive system but runs roughly 2 to 3 times faster than its peers on the same hardware.

The Agentic Edge: Perfect for KiloClaw

The preview release of this model, Trinity Large Preview, has been free in Kilo for over two months and quickly rose to the top of the OpenRouter leaderboards for both Kilo Code (including KiloClaw) and OpenClaw.

The preview version of Trinity Large has been in Kilo's top 20 for over two months. (Snapshot is from past 30 days.)

And that was just the preview. While Trinity Large's architecture natively supports context windows up to 512k tokens, the Preview API served at 128k context using 8-bit quantization. Now you can use the full release for free, with a longer context that supports multiple turns.

Trinity-Large-Thinking wasn't built to ace trivia benchmarks. It was purpose-built for tool calling, multi-step planning, and agent workflows. This makes it an absolute monster when plugged into agentic features like KiloClaw (our hosted OpenClaw environment).

Why is this new Trinity model so good for agentic use cases?

Native Reasoning Traces: The model generates explicit reasoning traces before producing its final response.
Context is Key: This internal thinking process is critical to the model's performance. When running agentic loops in OpenClaw, these thinking tokens must be kept in context for multi-turn conversations to function correctly.
Massive Memory: To support these long reasoning chains across many agentic steps, the model boasts a longer extended context window. It's particularly good at multi-turn tool use, context coherence, and instruction following across long-horizon agent runs.

Top of the PinchBench Index

We don't just take a lab's word for it; we look at the data. Our internal testing has found the model strong across OpenClaw use cases in KiloClaw.

Arcee built this model focusing on the things that make agents feel real in practice: staying coherent across turns, using tools cleanly, and strictly following instructions.

The results speak for themselves:

Top-Tier Performance: Initial testing saw Trinity Large Thinking rise to #2 on PinchBench, a benchmark measuring model capability on tasks relevant to agents like OpenClaw.
The Heavyweight Challenger: It sits just behind Claude Opus-4.6 in raw agentic capability.
Unbeatable Economics: While rivaling Opus-4.6, it lands at just $0.90 per million output tokens on Arcee's API, making it roughly 96% cheaper. (Plus it's currently free in Kilo — that's pretty affordable!)

At Kilo, we believe in avoiding vendor lock-in. Arcee shares that philosophy. They release model weights on Hugging Face under the Apache 2.0 license, and this has been true for all of their models. They built Trinity Large because they believe developers and enterprises need models they can inspect, post-train, host, distill, and truly own.

Try it today in our CLI, IDE extensions, and agentic features like Kilo's Cloud Agents and KiloClaw. You'll be glad you did.

PinchBench v2: Call for Contributors to the Leading OpenClaw Benchmark

Darko from Kilo — Tue, 31 Mar 2026 14:07:30 +0000

We're excited to announce that PinchBench v2 is now in active development --- and we're opening the doors for community contributions to help shape the next major release. 🦀

The Remarkable Rise of PinchBench

PinchBench started as a side project of Kilo DevRel mastermind Brendan O'Leary, who wanted to build a benchmarking system for evaluating LLM models as OpenClaw coding agents. The idea was simple: run tests based on real-world tasks to help users choose the right model for their use case. But my oh my, has that "side project" taken off!

NVIDIA GTC Keynote 2026

During his recent keynote, NVIDIA CEO Jensen Huang showcased PinchBench on stage as a definitive standard for evaluating the real-world performance of OpenClaw agents. He highlighted Nemotron 3 Super's performance as the top open-weight model for OpenClaw use cases.

In the following week, MiniMax has announced that they will soon release the weights for MiniMax-M2.7, and Z AI has shared that the much-anticipated GLM-5.1 will also have open weights. The competition is heating up, and not just for OSS models. This is only the beginning of the agentic revolution.

We need your help to make PinchBench even more useful and comprehensive. The era of generalized benchmarks is over. It's time for benchmarks that help you choose the best LLMs for always-on agents, with a focus on specific skills that can be used around the clock in tools like KiloClaw.

NVIDIA GTC Keynote 2026 (Full Screen!)

What We're Building

PinchBench v2 is a significant leap forward. Our aim is to produce a benchmark that more accurately captures the real-world complexity of agentic tasks --- including longer task horizons, better verification, and a much richer picture of model performance across a wider set of domains. As KiloClaw continues to lead the charge for hosted OpenClaw ease-of-use, functionality and security, we want to make sure that PinchBench is equally ahead of the curve.

Our goal for v2 is 100 tasks, and we're especially focused on testing across a wider range of OpenClaw use cases. We want contributions that reflect the kinds of tasks OpenClaw is actually being used for in practice, paired with rigorous success-rate measurement. If you're running OpenClaw in production or research contexts, you're exactly who we want to hear from.

On the leaderboard side, we're investing in a substantially improved UI/UX --- better filtering, model landing pages, user profiles, per-task variance, and more --- to make results easier to understand and compare.

PinchBench

Open Call for Contributions

The contribution window is open now through April 15th, 2026.

We are looking for two types of contributors: skills and leaderboard. You are welcome to contribute in both categories.

Skills Contributions

Help us expand and improve the task suite:

New tasks --- What should OpenClaw be doing that we aren't currently measuring? We want tasks that represent real, valuable work: things a practitioner would actually run OpenClaw on, with clear and programmatically verifiable success criteria. Tasks should be relevant across both local and hosted OpenClaw instances --- including hosted services like KiloClaw and KimiClaw.
Task improvements --- Some existing tasks fail at high rates across nearly all models, and others may not reflect the current state of what OpenClaw can do. If you can identify, fix, or replace tasks that aren't pulling their weight, we want your PR.
Success rate coverage --- Contributions that include baseline success rates across multiple models are especially valuable. Help us ensure the benchmark is neither too easy nor impossibly hard at release. It's all about real-world agentic use.

Good tasks should be:

Realistic --- something OpenClaw would genuinely be run on in a real workflow
Clearly specified --- a passing solution should unambiguously satisfy the task
Well-calibrated in difficulty --- ideally targeting a solve rate that distinguishes model capability
Convention-compliant --- all tasks must follow OpenClaw skill conventions to ensure consistency and compatibility across the benchmark

Leaderboard Contributions

Help us build a leaderboard that's detailed, clear, relevant and accessible.

We're working through a range of UI/UX improvements for v2, including redesigned filtering and navigation, model and contributor profile pages, improved scoring to eliminate run-size bias, and daily/weekly/monthly recognition badges. If you have front-end chops and care about how benchmark results are communicated, this is where we need you.

How to Contribute

There are no forms to fill out. Anybody can contribute.

Review the open issues in the PinchBench v2 meta issue to understand what's in scope
Propose a new task or improvement in GitHub Discussions or by opening an issue --- especially for OpenClaw-specific use cases you want to see covered
Implement your contribution by forking the repo, building it out, and submitting a PR
Iterate with reviewers to get your contribution merged

Recognition

Contributors will be recognized in the v2 release in two categories:

Skills Contributors --- recognized for accepted new tasks and task improvements, ordered by number of accepted contributions
Leaderboard Contributors --- recognized for accepted UI/UX improvements to the leaderboard

Every accepted contribution counts. Whether it's one well-crafted task or a full leaderboard feature, we aim to acknowledge top community contributions in the release.

Get Involved

GitHub: pinchbench/skill --- browse open issues and the v2 meta issue
v2 Meta Issue: #60 --- the full list of what's in scope for this release

PinchBench is a community project, and v2 will be shaped by the people who contribute to it. We'd love your help in improving the definitive benchmark for OpenClaw use cases. Learn more about PinchBench and KiloClaw.

The Cost of Always-On Agents is Less Than You Might Think

Darko from Kilo — Tue, 31 Mar 2026 14:04:26 +0000

There's a growing assumption in AI right now:

If agents are always running, costs will spiral.

This sounds reasonable. More autonomy should mean more tokens and more compute. More tokens and more compute should mean higher bills.

But that mental model is already breaking. Why? Because it assumes you're paying for outputs---individual prompts and responses.

In reality, with new agentic systems like OpenClaw, you're paying for something very different:

Ongoing throughput---work completed over time.

Once we understand that shift---the move from prompts and specific outputs to a model that focuses on ongoing throughput and persistent memory---the economics start to look completely different.

The Outdated Way to Think About Cost

Most teams still evaluate AI like an API:

Cost per token
Cost per request
Cost per response

That might work for chat, but it fails for agents. Agents don't just respond once. Instead, they plan, break work into steps, execute across tools, revisit and improve outputs, and (if everything is working correctly) they continue operating after the initial trigger.

So the real question isn't "how much does this prompt cost?" but "how much useful work can I get done for a small amount of money?"

Filtering by cost in PinchBench

What the Data Actually Shows

Benchmarks like PinchBench measure something more meaningful than tokens: cost per completed agent task.

Here's a snapshot of current value rankings. A few things jump out immediately:

High-value models like Opus complete full tasks for $0.03--$0.13
Even strong mid-tier models like Kimi K2.5 stay well under $0.50 per task
Average* success rates* cluster surprisingly close (65--85%) despite major cost differences

This leads to a non-obvious conclusion:

You're often paying 10--20x more for marginal gains in quality.

Filtering by success rate in PinchBench

What $10 Gets You in OpenClaw

We often have free models like Nemotron 3 Super, Trinity Large Preview and MiMo-V2-Pro available in Kilo, but even if you're opting for paid models, you can get a LOT for $10. A ten-spot will buy you a lot more than 10 turns in your agent chat.

Let's translate those numbers into something real.

Without Agents: Linear Output

If you're coding or prompting manually:

You rely on frontier models
You resend context every time
You manually trigger every step
Work stops when you stop

$10 gets you around 2--4 meaningful tasks. Then it's on to the next project.

With KiloClaw: Compounding Output

With a hosted OpenClaw agent like KiloClaw, that same $10 is distributed across a system:

sub-agents handling different responsibilities
multiple model tiers with different costs
cached context reused across runs
scheduled execution instead of constant prompting

In KiloClaw, $10 gets you around 20--150+ agent task executions.

Of course there's some variance depending on which tasks and skills you're focused on. But still. This is huge. And it's honestly a lot more than we were expecting when we started spinning up claws.

More importantly, the system keeps working after you stop. Sub-agents reduce waste, memory persists, and auto model routing can further decrease costs by 5-10x. Most agentic tasks don't actually need the "best" model. With auto routing now available in different modes in Kilo, including in KiloClaw, you can pick a mode during onboarding and update at any time.

Current Kilo Auto Modes. Models and modes subject to change!

Looking to take advantage of high-efficiency models but super powerful models like Kimi K2.5 and MiniMax M2.7? Choose Balanced Mode and we'll route between models for you.

Why "Agentic Engineering" Was Inevitable

This isn't just a cost story. It's a shift in how software gets built, whether that's full production software for a new startup or your own personal AI assistant with something like KiloClaw.

We're entering the era of agentic engineering---where multiple agents collaborate across planning, implementation, debugging, and deployment.

This isn't hype. It's already happening:

Code gets written, reviewed, and deployed in a single loop
Long-running tasks move into persistent cloud agents
Developers supervise systems instead of executing every step

The role of the developer is changing---from builder to orchestrator. And with OpenClaw the role of everyday AI users is changing too---from consumer to conductor.

And once that happens, cost behaves differently. Efficiency is no longer about a single request---it's about how well the system runs over time.

Platforms that unify this workflow---IDE, CLI, cloud, and collaboration---don't just improve productivity. They become the default interface for building software. This is what we've been building at Kilo since the beginning, and the rise of KiloClaw is just the next phase of this (very fast) evolution.

Check out PinchBench for the best OpenClaw benchmarks, and launch your own claw in minutes with Kilo! 🦀

We Tested MiniMax M2.7 Against Claude Opus 4.6

Darko from Kilo — Wed, 25 Mar 2026 08:11:33 +0000

MiniMax M2.7 launched on March 18 scoring 56.22% on SWE-Pro, close to Claude Opus 4.6. We ran both models through three coding tasks in Kilo Code to see if the benchmark numbers hold up in practice. On pricing, MiniMax M2.7 runs at $0.30/$1.20 per million tokens (input/output) compared to Claude Opus 4.6's $5/$25, roughly a 17x difference on input and 21x on output.

TL;DR: Both models found all 6 bugs and all 10 security vulnerabilities in our tests. Claude Opus 4.6 produced more thorough fixes and 2x more tests. MiniMax M2.7 delivered 90% of the quality for 7% of the cost ($0.27 total vs $3.67).

Test Design

We created three TypeScript codebases and ran both models in Code mode in Kilo Code for VS Code. Each model received the same prompt with no hints. We scored each model independently after all tests were complete.

Test 1: Full-Stack Event Processing System (35 points) - Build a complete system from a spec, including async pipeline, WebSocket streaming, and rate limiting
Test 2: Bug Investigation from Symptoms (30 points) - Trace 6 bugs from production log output to root causes and fix them
Test 3: Security Audit (35 points) - Find and fix 10 planted security vulnerabilities across a team collaboration API

Test 1: Full-Stack Event Processing System

We gave both models this prompt:

"Build a real-time event processing system in TypeScript from the specification in @spec.md. Use Hono for the web framework, Prisma with SQLite for the database, Zod for input validation, and ws for WebSocket support."

The spec required 7 components: event ingestion API with API key auth, async processing pipeline with exponential backoff retry, event storage with processing history, query API with pagination and filtering, WebSocket endpoint for live streaming, per-key rate limiting, and health/metrics endpoints.

Both models implemented all 7 components. The score difference came from code organization and test coverage.

Architecture

Claude Opus 4.6 created a modular directory structure with separate directories for routes, pipeline, middleware, and WebSocket management. It split the processing logic into separate files for queue management (with retry scheduling and dead-letter routing) and per-type event handlers. It also included graceful shutdown with timer cleanup.

MiniMax M2.7 used a flatter structure with fewer files. All routing lived in a single entry file, and the processor was simpler with no shutdown management or timer tracking.

Test Coverage

Claude Opus 4.6 wrote 41 integration tests with a dedicated test database and proper cleanup between tests. The tests make actual HTTP requests against the API, testing the full middleware chain end-to-end.

MiniMax M2.7 wrote 20 unit tests that validate Zod schemas and handler functions directly. These cover the core logic, but don't test the API endpoints or middleware through HTTP, so routing or middleware bugs would slip through.

Test 1 Scoring

Claude Opus 4.6 lost 2 points for not generating a README (the spec asked for one). MiniMax M2.7 generated a README but lost points on architecture and test coverage.

Test 2: Bug Investigation from Symptoms

We built an order processing system with 4 interconnected modules (gateway, orders, inventory, notifications) and planted 6 bugs. We gave both models the codebase, a production log file showing symptoms, and a memory profile showing growth data. The prompt listed the 6 symptoms and asked both models to investigate, find root causes, and fix them.

Both models found all 6 root causes.

Bug #1: Race Condition in Inventory

Stock was checked first, then reserved in a separate transaction. Two concurrent orders could both pass the check before either reserved. Both models identified this from the logs and fixed it by making the reservation atomic.

Claude Opus 4.6 also added rollback logic. If reserving stock for one item in a multi-item order fails, it releases the items that already succeeded and marks the order as "failed." MiniMax M2.7 made the reservation atomic but didn't add rollback, so partial failures can leave orphaned reservations.

Bug #4: Floating-Point Totals

The order total calculation used standard floating-point arithmetic, which produces results like 159.92000000000002 for certain price and quantity combinations. The logs showed repeated "Total validation warning" entries where the expected and calculated totals differed by tiny fractions.

Claude Opus 4.6 rounded the result after calculation:

MiniMax M2.7 converted to integer math (cents), avoiding the precision problem entirely:

MiniMax M2.7's approach is technically better here. Working in cents avoids accumulation errors that rounding after the fact can miss on large orders.

Remaining Bugs

Both models fixed the other 4 bugs with the same approach:

Notification ordering (Bug #2): Added a status check before sending confirmation emails, skipping orders that were already cancelled
Memory leak (Bug #3): Removed a per-order event listener that was never cleaned up, accumulating with each request (the memory profile showed listener count tracking 1:1 with request count)
Stale inventory cache (Bug #5): Added cache invalidation calls after stock updates, so the 60-second cache TTL no longer serves stale data
Token revocation bypass (Bug #6): Removed a "5-minute optimization" that skipped the revocation check for fresh tokens

Test 2 Scoring

Both models verified their fixes by running curl requests against the server. Claude Opus 4.6 explicitly referenced log entries when explaining each bug, while MiniMax M2.7 jumped more directly to the code.

Test 3: Security Audit

We built a team collaboration API (Hono + Prisma + SQLite) with 10 planted security vulnerabilities. We asked both models to audit the codebase, categorize each vulnerability by OWASP, explain the attack vector, rate severity, and implement fixes.

Both models found all 10 vulnerabilities with correct OWASP categorizations. The 4-point gap is entirely in fix quality.

Where the Fixes Diverged

Password hashing: Claude Opus 4.6 used scrypt with random salts and timing-safe comparison. MiniMax M2.7 used SHA-256 with the JWT secret as the salt, and flagged in its own output that bcrypt would be better.
Insecure deserialization: Both removed the eval() on webhook transforms. Claude Opus 4.6 replaced it with a safe JSON key-mapping system. MiniMax M2.7 disabled transforms entirely.
SSRF protection: Claude Opus 4.6 validated webhook URLs at creation, update, and delivery. MiniMax M2.7 validated at delivery only.
Rate limiting: Claude Opus 4.6 applied per-endpoint limits (login, register, password reset). MiniMax M2.7 only rate-limited the login endpoint.
JWT fix: Both moved the hardcoded secret to an environment variable. Claude Opus 4.6 let jwt.verify() handle expiration natively. MiniMax M2.7 fixed the broken manual comparison, which works but duplicates built-in functionality.

Test 3 Scoring

Overall Results

The Bigger Picture

We've been testing MiniMax models since M2 last November. Earlier versions competed against other open-weight models like GLM 4.7 and GLM-5. With each release, the scores climbed and the cost stayed low. MiniMax M2.5 (the previous version) is currently the #1 most-used model across every mode in Kilo Code, ahead of Claude Opus 4.6, GLM-5, and GPT-5.4. In Code mode it accounts for 37% of all usage. In Ask mode, 35%.

MiniMax M2.5 usage across Kilo Code modes

MiniMax M2.7 is the first version where we felt the right comparison was a frontier model rather than another open-weight one. It matched Claude Opus 4.6's detection rate on every test in this benchmark, finding the same bugs and the same vulnerabilities. The fixes aren't as thorough yet, but the diagnostic gap between open-weight and frontier models is shrinking with every release.

Takeaways

For building from scratch: Claude Opus 4.6 produced 41 integration tests and a modular architecture. MiniMax M2.7 built the same features with 20 unit tests and a flatter structure, at $0.13 vs $1.49.

For debugging: Both models found all 6 root causes from log symptoms. MiniMax M2.7 even produced a better fix for the floating-point bug. Claude Opus 4.6 added rollback logic that MiniMax M2.7 missed.

For security work: Both models found all 10 vulnerabilities. Claude Opus 4.6's fixes are closer to what you'd ship (proper key derivation, feature-preserving alternatives, defense-in-depth). MiniMax M2.7 closes the same vulnerabilities with simpler approaches and sometimes flags its own shortcuts.

On cost: $3.67 total for Claude Opus 4.6 vs $0.27 for MiniMax M2.7. Detection was identical. The gap is in how thorough the fixes are.

Talk to the Claw: The Interface Is Now a Single Sentence

Darko from Kilo — Fri, 20 Mar 2026 09:00:00 +0000

We hear it a lot these days, but what does it actually mean for software to have a "new interface"?

At Kilo, we aren't approaching this question in the abstract---we're living it every day.

As we lean into agentic flows, we're discovering that working in a new interface means that the layer between you and the tool is no longer a dashboard, a form, or a button. It's a sentence.

You will still hear people talk about UX improvements. Better navigation. Cleaner design. More intuitive onboarding flows. It will be framed as progress.

But the real change runs deeper than any redesign. The interface layer is decoupling from the application layer entirely. You don't need to know where the button is. You don't need to learn the menu structure. You just say what you need done.

Natural language is the new UI.

A couple of things I'm not saying:

I'm not saying every app will disappear.
I'm not saying this works perfectly today for every use case.
I'm not saying you should throw away your existing workflows.

But here's what I am saying: the apps you already use didn't have to rebuild themselves from scratch for this to be true. KiloClaw can talk to Todoist and Linear and your calendar and your inbox -- through the same window, using the same language you'd use to text a colleague. You don't have to live inside each one to operate them.

Credit: Todoist

This isn't about saving five minutes. It's about a bigger shift. The way we interact with software is fundamentally changing.

Twelve Tools, One Front Door

Here's where the new interface really shines.

Last week, I had a new project land in my inbox. I downloaded the PDF, uploaded it to my KiloClaw bot on Telegram, and typed a simple prompt in natural language, essentially: Create a Todoist project for this and add the tasks based on these guidelines.

That's it. No excessive bulleted lists. No diagrams. No long paragraphs discussing the background and goals for this project. Just a couple of sentences.

Thirty seconds later, it was done.

And the same thing with scheduling.

I was meeting with a friend and colleague and we agreed to sync again the following week. We both pulled up our calendars, found a time. I sent a message to KiloClaw. My contact received a calendar invite a minute later.

Two different tools. Two different workflows. One conversation.

Here's the thing: Todoist actually has a feature for this. It's called Ramble -- you can talk to it, describe your project, and it populates tasks for you. That's cool. But that's not the unlock I'm talking about.

I'm the kind of person who has a different tool for everything. Todoist for tasks. GitHub for engineering projects. Slack for team communication. Gmail for email. Each tool lives in its own silo, with its own interface, its own learning curve, its own quirks.

The problem has never been the tools.

The problem is the twelve different front doors. With a unified interface that acts on natural language, we now have a single way into the house.

The New Interface is the Front Door We Always Needed

Count the apps you opened before lunch today.

Email. Slack. Calendar. Linear. Todoist.

They're all like different doors into your life, each with its own login, its own layout, its own way of asking you to do the same basic thing: move information from your head into the right place.

That tax -- the constant context-switching, the re-orienting, the "where does this live?" -- is so familiar that most of us stopped noticing it.

We got so used to micro context-switching that we forgot there could be a better way.

Curious?

Here's what I recommend you to do to get started: Start with one workflow you do repeatedly. Something tedious. Something where you're just copying information from one place to another. Tell your bot to do it instead.

You might be surprised how short the conversation needs to be.

How KiloClaw Is Built to Be Secure

Darko from Kilo — Thu, 19 Mar 2026 13:00:00 +0000

OpenClaw has taken the world by storm and brought autonomous AI agents into the mainstream.

However, when an agent can execute code, browse the web, and connect to Slack, Discord, or Telegram on your behalf, security stops being a footnote and starts being the whole plot.

This also raises an obvious question:

How do I know my data, accounts, and API keys are safe?

That question sits at the center of how KiloClaw is built.

KiloClaw is a managed compute platform for OpenClaw built with security at its core, and we just published a detailed white paper describing the platform's security architecture and independent assessment.

This post summarizes the key points from KiloClaw's February 2026 security white paper. Let's dive in.

What makes KiloClaw different from your "typical OpenClaw hosting SaaS"

KiloClaw was designed from the ground up with defense in depth: multiple layers of isolation, strong authentication, encrypted storage, and strict handling of customer secrets.

And in February 2026, KiloClaw brought in an independent security assessor, Andrew Storms, for a 10 day review that included threat modeling, code review, adversarial testing, and live infrastructure testing. The conclusion: KiloClaw's security architecture is sound, with tenant isolation enforced at multiple independent layers.

Each instance is an isolated virtual machine

Most SaaS products store customer data in shared infrastructure and rely on application logic to keep accounts separated.

KiloClaw is different because your AI agent actually runs code on your behalf. That means the isolation between customers has to be much stronger.

A simple way to think about it is this:

Many platforms give you an apartment in a larger building.
KiloClaw gives you your own house, on your own lot, with your own fence.

When you create a KiloClaw instance, we spin up a dedicated virtual machine just for you.

Not a shared container. Not a small slice of someone else's runtime. A full virtual machine with its own kernel.

KiloClaw uses Firecracker microVMs, the same virtualization technology used by AWS Lambda and AWS Fargate. That matters because Firecracker provides isolation between workloads based on hardware virtualization.

In practical terms, that means if something goes wrong inside your AI agent's environment, the impact is contained to your environment. There is no shared kernel, no shared filesystem, and no shared process space with other customers.

Five layers of isolation

KiloClaw does not depend on one security layer. It uses five independent layers of tenant isolation.

For one customer to access another customer's data, all five layers would have to fail at the same time.

1. Identity-based routing

Every request is authenticated before it reaches a customer machine.

KiloClaw does not route requests based on user-controlled input. Instead, it derives the destination from the authenticated user identity stored server-side.

In plain English: you cannot trick the platform into sending you to someone else's machine.

2. A dedicated application environment

Each customer's VM runs inside a dedicated Fly.io application.

That matters because KiloClaw keeps each customer's machines, storage, and internal network isolated from other customers.

In practice, that means one customer's storage cannot be attached to another customer's machine, and one customer's machines cannot be discovered through another customer's internal network.

3. Network isolation

Each customer environment is placed on its own isolated WireGuard network mesh.

During the independent assessment, live cross-tenant tests confirmed that customers could not discover one another's machines, could not connect directly across applications, and could only perform self-referencing network operations.

So the separation exists at the network layer too, not just inside the app.

4. The Firecracker VM boundary

Each customer workload runs inside its own Firecracker microVM.

This is a hard isolation boundary based on hardware virtualization. Even if an AI agent were manipulated through prompt injection or malicious tool usage, the blast radius would still be limited to that customer's own VM.

To escape that boundary would require a vulnerability in the Firecracker hypervisor itself.

5. Dedicated encrypted storage

Each customer gets a dedicated persistent storage volume, and that volume is encrypted at rest.

That storage can only be mounted inside the customer's own application environment. There is no path for another customer's machine to access it.

What about my API keys?

This is one of the most common questions for a good reason.

Customer API keys and chat tokens are encrypted in the platform database using RSA-OAEP with AES-256-GCM and are decrypted only when the customer's VM starts, where they are available inside that customer's isolated environment.

In other words, your keys are stored in encrypted form by the platform and only become readable inside your own isolated environment when needed.

There is also more work planned here over time, including short-lived token exchange and in-memory secret stores to reduce the exposure window even further.

Your data is protected in transit and while stored

KiloClaw protects data both while it is moving and while it is stored.

All external traffic uses TLS, including communication between the browser and the platform, as well as API calls to model providers.

At rest, customer storage volumes are encrypted using disk encryption at the infrastructure level, and secrets stored in the database are encrypted separately using modern cryptography.

In practical terms, that covers things like:

API keys
Chat tokens
Session transcripts
Workspace files
Authentication-related secrets

What happens when I delete my instance?

When you destroy your KiloClaw instance, the platform runs a two-phase cleanup process designed to complete safely even if something fails midway.

First, it shuts down and destroys the virtual machine. Then it deletes the storage volume and removes runtime secrets.

Deleting the volume also destroys the underlying encryption keys, making the stored data unrecoverable.

The deletion flow was reviewed independently and confirmed to clean up sensitive data reliably, even if part of the process fails temporarily and has to retry.

No secrets persist after instance destruction.

Some metadata that is not sensitive, such as user identifiers or timestamps needed for operational auditing, may remain in records or logs that have been soft deleted. That is standard practice and separate from customer secrets or workspace data.

What about prompt injection?

If you follow AI security, you have probably heard of prompt injection: a malicious message or webpage tries to trick an AI agent into doing something it should not do.

KiloClaw addresses this in two important ways.

First, the agent's exec tool, the capability that lets it run shell commands, requires explicit user approval before execution by default. That setting is enforced by the platform itself and cannot be overridden by the agent, by prompt injection, or through a connected chat channel.

Second, even in a worst-case scenario where prompt injection changes the agent's behavior, the blast radius is still contained to your own VM. It cannot access another customer's resources or move sideways across tenants.

Authentication is designed to reject uncertainty

KiloClaw's authentication model includes several protections that matter in practice:

Secure JWT cookie handling
Server-side session revocation
Constant-time secret comparison
Behavior that rejects requests when required systems are unavailable

That last one is especially important.

If a required backend dependency is unavailable, KiloClaw rejects the request rather than falling back to weaker behavior. That is a strong security property and one of the details security teams look for.

What we tested with an independent security assessor

In February 2026, independent assessor Andrew Storms conducted a 10-day security assessment of KiloClaw.

That work included:

Threat modeling using the PASTA framework, covering 30 threats across 13 assets
Code review of routing, authentication, secret handling, and lifecycle management
35 adversarial tenant-isolation tests, including Unicode edge cases, zero-width characters, null bytes, and injection payloads
8 live cross-tenant network tests across separate customer environments
Dozens of adversarial command-injection payloads
Review of the build pipeline, machine images, and runtime environment

The results were strong:

No cross-tenant access path was found
No SQL injection findings
No XSS findings
No command injection findings
No path traversal findings
No open redirect findings

The assessment also produced 17 merged pull requests: 10 security fixes and 7 hardening improvements.

Security is an ongoing practice

One thing worth saying clearly: strong security does not mean pretending the work is done.

The independent review found KiloClaw's architecture to be fundamentally sound, while also identifying areas for continued investment, especially around hardening the software supply chain and improving operational maturity.

That roadmap includes:

Pinning base images to SHA-256 digests
Image signing with Sigstore and cosign
SBOM generation
Automated vulnerability scanning in CI/CD
Egress monitoring and interactive approval controls for outbound agent activity

The bottom line

KiloClaw was built with the understanding that managed compute for AI agents is a product category that demands a high level of trust and security.

That is why each customer gets:

A dedicated virtual machine
A dedicated application environment
An isolated network
Dedicated encrypted storage (volume isolation)
Strong authentication and access controls
Encrypted secret handling
Multiple independent layers of tenant isolation

For nontechnical readers, the simplest takeaway is this:

Your agent is not running in the same place as everyone else's. Your environment is isolated by design.

For technical buyers, the important point is that this was not just claimed. It was independently reviewed, tested against adversarial scenarios, and validated in live infrastructure testing.

If you have questions about KiloClaw's security architecture or want additional documentation, reach out to the Kilo security team at security at kilocode dot ai.

ClawCon Recap: NYC & Austin

Darko from Kilo — Thu, 19 Mar 2026 08:53:36 +0000

Over the past two weeks, Kilo presented two ClawCon events: ClawCon NYC on March 4th, and ClawCon Austin on March 12th. Combined, over 2,000 people showed up. Both venues hit capacity, and both made one thing pretty obvious: personal AI agents aren't an experiment anymore.

People are building real things, running real businesses, and showing up in person to learn from each other.

What Is ClawCon?

If you haven't been to one, ClawCon isn't a traditional tech conference. It grew out of the OpenClaw ecosystem, and the format is simple: doors open, people demo what they've built with their personal AI agents, there's Q&A, and then a lot of unstructured time to just talk to other people who are excited about this technology.

The events are free, there's no LinkedIn or GitHub screening, and the only barrier to entry is showing up early enough to get through the door before capacity hits. At both NYC and Austin, that happened fast.

OpenClaw has crossed 320,000 GitHub stars and is the fastest-growing open source AI agent in history. It connects to 50+ chat platforms, runs shell commands, controls browsers, manages files, and maintains memory across sessions. The community around it has grown just as fast, and ClawCon is where that community meets in person. (Kilo's role in all of this: we built KiloClaw, a managed hosting platform for OpenClaw agents that's natively connected to the Kilo Gateway and its 500+ models. We demoed it at both events. More on that below.)

ClawCon NYC: 1,300 People in Lower Manhattan

ClawCon NYC took over Ideal Glass Studios in Manhattan on March 4th. 1,313 people RSVPed, the venue filled up well before demos started at 7pm, and the one-in, one-out policy kicked in shortly after doors opened at 6. The crowd was a mix: developers who've been running OpenClaw agents for months, people who had never set one up but wanted to learn, founders demoing tools they'd built on top of the ecosystem, and plenty of people who were just curious about what "personal AI" actually means in practice. That range is part of what makes these events work. It's not a room full of the same person.

The demo portion covered a range of use cases. OpenClaw maintainers walked through recent platform updates, and several community members showed personal workflows they'd built: agents handling email triage, research pipelines, content generation, and task automation across multiple platforms.

One recurring theme was people who had set up OpenClaw agents not just for themselves, but for other people and businesses. The post-event email from ClawCon organizer Michael Galpert specifically called this out, noting that many attendees came looking for help getting their own agent running, while others had already set up "multiple individuals and businesses with their own Claws." That dynamic --- people who build agents helping people who want agents --- is becoming its own economy within the community, and it's exactly the kind of gap that KiloClaw was built to close on the infrastructure side.

The afterparty, sponsored by JellyJelly and Zo.Computer, kept things going. The ClawCon Telegram channel saw a massive influx of new members, the X livestream pulled significant viewership, and the general vibe in the post-event chatter was that the NYC OpenClaw community is bigger and more active than most people realized.

ClawCon Austin: 756 People, Robots, and Teenagers Running Businesses

Eight days later, ClawCon hit Austin at Antler VC's space on Brazos Street. 756 people attended with the same format, and the demo lineup showed just how fast this space is evolving.

Nat Eliason walked through his personal agent "Felix Craft" and how he uses it day-to-day. Nat's audience skews toward creators and entrepreneurs rather than developers, so seeing how he integrates an AI agent into non-technical work was valuable context for a lot of people in the room.
Austen Allred demoed his agent Kelly and what he calls her "Software Factory" --- a workflow where the agent handles significant portions of the development process autonomously.
Thanh Pham presented five distinct OpenClaw use cases he's built for real, paying clients. This was one of the clearest signals of a maturing ecosystem: people aren't just building agents for fun, they're getting paid to build and configure them for others.
Matt Hartman brought a physical robot that he controls with OpenClaw. A physical, moving robot operated by an AI agent. If you want a visceral demo of what agents can do beyond text on a screen, that'll do it.

And then there were the Alpha School kids. This was the moment that stuck with people.

Branson, a 15-year-old student at Alpha School, has made $30,000 selling OpenClaw agent setup and configuration services. He's not dabbling --- he's running a business. His classmates demoed alongside him: Ananya built a Reddit bot that automatically finds and engages potential customers, Austin is building edtech products with OpenClaw, and Geetesh is starting a business with his agent.

A 15-year-old generating $30K in revenue doing this says something important about where personal AI is headed: it's accessible enough for a high schooler to master, and valuable enough that people will pay real money for help. It also hints at where tools like KiloClaw fit in --- when you're setting up agents for other people, the last thing you want is to also be managing their infrastructure.

KiloClaw: What We Demoed

We brought KiloClaw to the stage at both NYC and Austin, and it resonated for slightly different reasons at each event, but the core message was the same: getting OpenClaw running shouldn't be the hard part.

Here's the context. OpenClaw is powerful, but self-hosting it is genuinely painful. You're looking at 30-60+ minutes of SSH, environment configuration, dependency management, and security hardening just to get it stood up. Once it's running, there's no auto-restart, no health monitoring, no alerting. If your agent crashes at 3am, you find out the next morning. And every new OpenClaw release means SSH-ing back in, pulling the latest code, hoping nothing breaks, and restarting manually.

KiloClaw eliminates all of that. It's a fully managed hosting platform for OpenClaw agents, built on the same Kilo Gateway infrastructure that already serves 1.5M+ developers and routes to 500+ AI models. You go from zero to a running OpenClaw agent in under 60 seconds. No SSH, no Docker, no YAML files. One-click deploy, auto-restart on crash, automatic updates, and support for multiple chat platforms including Telegram, Discord, and Slack.

Pricing for KiloClaw is $9/month on a 6-month commit or $25/month standard, and AI inference runs through Kilo Gateway at cost with zero markup --- same transparent pricing Kilo has always offered.

In NYC, the crowd skewed toward people who wanted an agent but didn't want to manage infrastructure, and the number of people who came up to the booth afterward asking "so I can just... have one running tonight?" confirmed the message landed.

In Austin, the room had a higher concentration of people already building with or on top of OpenClaw, so for them the value was less about easy setup and more about the infrastructure layer underneath: access to 500+ models without juggling API keys across providers, unified billing through the same Kilo account they might already use for the IDE extension or CLI, scheduled tasks and cron jobs so agents can run while you sleep, and enterprise-grade security for when your agent is handling API keys, conversations, and connected accounts for clients.

For someone like Thanh, who's building agent configurations for paying clients, or Branson, who's running a services business at 15, the pitch isn't convenience --- it's reliability. When you're charging someone for an agent, it can't crash silently at 3am with no monitoring and no auto-restart. KiloClaw handles that.

The Numbers After Austin

The Austin livestream crossed 120,000 views on X. That same week, both ClawCon and PinchBench, the powered-by-Kilo AI model benchmark for OpenClaw created by our very own Brendan O'Leary, got a shoutout during NVIDIA's GTC keynote.

That kind of visibility from one of the biggest names in AI hardware isn't something a community meetup series typically gets, and it says a lot about how quickly the personal AI agent movement has scaled.

What We're Seeing Across Both Events

A few patterns stood out across NYC and Austin:

Non-developers are showing up. ClawCon isn't just attracting engineers. Creators, entrepreneurs, small business owners, and students are all in the room. The tools have gotten accessible enough that you don't need to be a developer to benefit from a personal AI agent, and while you might still need help setting one up, the gap between "interested" and "using one daily" is shrinking fast.

The community is self-organizing. The Telegram group, the demo culture, the organic matchmaking between people who build agents and people who want them --- none of this is centrally orchestrated by a company. It's a community building its own infrastructure, and ClawCon is where it becomes visible.

Personal AI is moving from novelty to utility. The demos weren't "look at this cool thing." They were "here's how this saves me 10 hours a week" or "here's how this makes me money." The conversation has shifted from possibility to practice.

What's Next

ClawCon Miami presented by Kilo Code is on March 25th, and you can sign up here.

If you want to get your own OpenClaw agent running without dealing with infrastructure, KiloClaw gets you from zero to deployed in under 60 seconds. Your Kilo Code account is your KiloClaw account --- no new signup or billing relationship. Just add an agent to your toolkit. Try KiloClaw →

If you want help getting your agent configured with your email, calendar, and key workflows, we also offer a live 1-hour onboarding call to get everything dialed in. Learn more →

And if you were at NYC or Austin --- thanks for being there. The energy at both events was something you had to feel in person. See you at the next one!

MiniMax-M2.7 Is Now Available in Kilo. Here’s How It Performs.

Darko from Kilo — Thu, 19 Mar 2026 08:45:00 +0000

MiniMax just released MiniMax-M2.7, their most capable model yet. It's available now in Kilo across the IDE extension, CLI, and Cloud Agents.

We ran it through two benchmarks: PinchBench, our OpenClaw agent benchmark, and Kilo Bench, an 89-task evaluation that tests autonomous coding across everything from git operations to cryptanalysis to QEMU automation.

Here's what we found.

TL;DR: M2.7 scores 86.2% on PinchBench, placing 5th overall and within 1.2 points of Claude Opus 4.6. On Kilo Bench, it passes 47% of tasks with a distinct behavioral profile --- it may over-explore hard problems (which can lead to timeouts) but solves tasks that no other model can. It's a fast and affordable model that fills some gaps that frontier models miss.

PinchBench: #5 Out of 50 Models

PinchBench runs standardized OpenClaw agent tasks and grades them via automated checks and an LLM judge. M2.7 scored 86.2%, landing just behind GLM-5 and GPT-5.4 (both 86.4%) and just ahead of Qwen3.5-plus (85.8%).

The top of the leaderboard as of today, March 18, 2025:

The gap between 1st and 9th place is less than 2 points. M2.7 is competitive with the best models available at the agentic coding task level that PinchBench measures.

What's notable is the jump from M2.5 (82.5%) to M2.7 (86.2%) --- a 3.7-point improvement that moved MiniMax from the middle of the pack into the top tier.

You can try MiniMax M2.7 today in a cloud-hosted, fully-managed OpenClaw instance using KiloClaw. Set up takes 2 clicks and about 60 seconds, and you can access it from the Kilo dashboard:

-> https://app.kilo.ai/claw

Kilo Bench: 89 Tasks vs 5 Other Models

PinchBench tells you how a model performs on typical agent tasks in OpenClaw. Kilo Bench tells you where it breaks.

We ran M2.7 through 89 tasks in Kilo CLI alongside four other models: Qwen3.5-plus, GLM-5, Kimi K2.5, and Qwen3.5-397b. Each model received a single prompt and ran autonomously --- no human intervention, no course correction --- for up to an hour per task depending on complexity.

Overall Results

M2.7 came in second overall at 47%, two points behind Qwen3.5-plus. But the raw pass rate doesn't tell the full story.

One pattern stood out: MiniMax-M2.7 reads extensively before writing. It pulls in surrounding files, analyzes dependencies, traces call chains. On tasks where that extra context pays off, it catches things other models miss. On tasks where the clock is ticking, that might cause it to run out of time.

This is the same exploration-heavy behavior we saw in our Code Reviewer cost analysis with Claude Opus 4.6, which consumed 1.18M input tokens on a single PR while Kimi K2.5 used 219K on the same diff. Deep reading finds deeper bugs --- but it costs time and can consume more tokens.

Where M2.7 Stands Out

The most interesting finding from Kilo Bench isn't the pass rate. It's what each model uniquely solves.

Every model in this comparison solved tasks that no other model could:

M2.7's unique win on the SPARQL task is a good example of its strength: the task required understanding that an EU-country filter was an eligibility criterion, not an output filter. That's a reasoning distinction, not a coding one.

A hypothetical oracle that picks the best model per task would solve 60 out of 89 tasks (67%) --- a 36% improvement over the best single model. These models aren't interchangeable. They're complementary.

Task Difficulty Breakdown

The 89 tasks split into clear tiers:

18 tasks all 5 models solved --- git operations, text processing, basic ML, infrastructure setup. These are table stakes for any capable coding model in 2026.
17 tasks where 2-3 models succeeded --- this is where model selection actually matters. Tasks like differential cryptanalysis, Cython builds, and inference scheduling separate models by their behavioral tendencies, not just their raw capability.
29 tasks no model solved --- circuit synthesis, MIPS emulation, pixel-perfect rendering, competitive CoreWars. These represent the current hard ceiling for LLM-based agents regardless of which model you pick.

Token Efficiency

M2.7 consumed roughly 2.8M input tokens per trial on average, which is on the higher end of any model tested. For context:

M2.7 reads more context per step than any other model, which means it accumulates more tokens over the course of a task. When it works, that thoroughness produces correct solutions. When it doesn't, it means more tokens and time spent on each task.

What MiniMax-M2.7 Does Differently

MiniMax's announcement describes M2.7 as their first model that "deeply participates in its own evolution" --- the model was involved in updating its own memory, building training skills, and improving its own learning process during development. They report it autonomously ran over 100 rounds of scaffold optimization, achieving a 30% performance improvement on internal evals.

That's a genuinely novel training approach and worth reading about in MiniMax's full announcement. Whether the self-evolution process contributes to M2.7's exploration-heavy behavior in our benchmarks is an interesting question we can't answer from the outside.

When to Use M2.7

Based on both benchmarks, here's how M2.7 fits into the model landscape available in Kilo:

M2.7 is a strong pick when you're working on tasks that reward deep context gathering --- complex refactors, codebase-wide changes, or anything where understanding surrounding code matters more than speed. Its PinchBench score puts it in the same tier as GPT-5.4 and GLM-5 for general agent tasks. Compared to frontier models like Opus 4.6 and GPT 5.4 that offer the same attributes, it's much less expensive at $0.30/M input and $1.20/M output.

Consider a different model (even such as M2.1 or M2.5) when you need very fast iteration cycles or are working on well-scoped, time-sensitive tasks. M2.7's median task duration (355s) is notably longer than its predecessors.

The best approach is what Kilo is built for: switch models based on the task. Use M2.7 for the work that benefits from a compromise of thorough analysis and speed. Use something lighter for the tasks that need quick turnaround. With 500+ models available, you're not locked into any single tradeoff.

MiniMax-M2.7 is available now in Kilo. Try it in the IDE extension, CLI, or Cloud Agents.

7 Automations You Can Set and Forget Right Now

Darko from Kilo — Tue, 17 Mar 2026 14:04:51 +0000

Cloud Agents with Webhook Triggers turn Kilo into an event-driven automation layer for your development workflow.

You push a tag. A deploy finishes. Someone labels an issue. Kilo picks it up, spins up a Cloud Agent, and starts working. No manual trigger, no context-switching, and workflows that happen while you sleep.

We've already covered some big ones in previous posts (see here and here): incident triage, security patching, dependency upgrades, documentation sync, policy enforcement.

But webhooks can handle a lot more than the obvious plays. Here are seven more automations you should steal.

1. Nightly Code Quality Sweeps

Every codebase accumulates lint violations, inconsistent formatting, unused imports, and dead code paths that nobody prioritizes because they're not the most urgent. They just make everything slightly worse over time.

Set up a cron job (GitHub Actions scheduled workflow, a simple cron server, or any scheduler that can fire an HTTP POST) to trigger a webhook on a nightly or weekly cadence. The payload can specify which checks to run:

{
  "task": "code-quality-sweep",
  "checks": ["lint-fix", "format", "unused-imports", "dead-code"],
  "target_dirs": ["src/", "lib/"],
  "base_branch": "main"
}

Cloud Agent Prompt Template:

A scheduled code quality sweep has been triggered:

{{bodyJson}}

Run the following cleanup tasks on the directories specified:

1. Run the project's configured linter with auto-fix enabled
2. Run the project's formatter (Prettier, Black, gofmt, etc.)
3. Identify and remove unused imports
4. Search for dead code: unexported functions with zero call sites,
   unreachable branches, commented-out blocks older than 30 days
5. Run the test suite to confirm nothing breaks
6. Commit each category of fix separately:
   - "style: auto-fix lint violations"
   - "style: format code"
   - "refactor: remove unused imports"
   - "refactor: remove dead code"

If any fix causes test failures, revert that specific change and
document it in `quality-sweep-notes.md`.

Open a pull request summarizing all changes with counts per category.

This is the kind of thing that never warrants sprint priority but compounds over months. The agent handles it overnight, and you review a clean PR in the morning. If your team runs a monorepo, scope target_dirs to specific packages and rotate through them on different nights.

2. Feature Request to Prototype Branch

When someone files a well-scoped feature request, the path from "that's a good idea" to "someone started working on it" can take days of backlog grooming and sprint planning. For straightforward requests, an agent can at least get an MVP in place automatically.

Wire up a GitHub webhook that fires when an issue is labeled (e.g., auto-prototype or agent-implement). The payload includes the full issue body:

{
  "action": "labeled",
  "label": {
    "name": "auto-prototype"
  },
  "issue": {
    "number": 342,
    "title": "Add CSV export to the analytics dashboard",
    "body": "Users should be able to export the current dashboard view as a CSV file. The export button should appear in the top-right toolbar. Should include all visible columns with current filter state applied.",
    "user": {
      "login": "contributor-username"
    }
  },
  "repository": {
    "full_name": "org/analytics-dashboard"
  }
}

Cloud Agent Prompt Template:

A feature request has been labeled for automatic prototyping:

{{bodyJson}}

Analyze this feature request and build a prototype implementation:

1. Read the existing codebase to understand architecture, patterns,
   and conventions
2. Create `prototype-plan.md` outlining your approach, files to modify,
   and any assumptions you're making
3. Implement the feature following existing project patterns
4. Add basic tests covering the happy path
5. If the request is ambiguous or requires design decisions, document
   your choices in `prototype-plan.md` and pick the simplest option
6. Commit incrementally as you work:
   - "feat: scaffold [feature] structure"
   - "feat: implement [feature] core logic"
   - "test: add tests for [feature]"

Do not modify CI configuration, deployment configs, or unrelated code.
Keep scope tight to what the issue describes.

This isn't about shipping features without review. It's about eliminating the gap between "approved idea" and "first draft." Your team reviews the prototype PR, iterates on it, or uses it as a reference for a manual implementation. Either way, the starting line moved forward without anyone context-switching.

Tip: Be selective about which issues get the label. This works best for well-specified, moderate-complexity requests. Vague issues like "make the app faster" won't produce useful output.

3. Stale Branch Audit and Cleanup

Many repos accumulate dozens of branches that nobody remembers. Feature branches from three months ago, experiment branches that went nowhere, hotfix branches that were merged but never deleted. They clutter your branch list and occasionally cause confusion about what's active.

Trigger this on a weekly or biweekly cron:

{
  "task": "branch-audit",
  "stale_threshold_days": 30,
  "protected_branches": ["main", "develop", "staging", "release/*"],
  "dry_run": false
}

Cloud Agent Prompt Template:

A scheduled branch audit has been triggered:

{{bodyJson}}

Audit the repository's remote branches:

1. Use `git branch -r` and `git log` to list all remote branches
   with their last commit date and author
2. Identify branches with no commits in the last {{body.stale_threshold_days}} days
3. Skip any branches matching the protected patterns
4. For each stale branch, check if it was merged into main
   (use `git branch -r --merged origin/main`)
5. Generate `branch-audit-report.md` containing:
   - Total branch count
   - Stale branches (merged vs unmerged), with last commit date and author
   - Recommended actions for each
6. If dry_run is false AND the branch was already merged:
   delete the remote branch using `git push origin --delete <branch>`
7. Commit the audit report:
   "chore: branch audit report - [date]"

Never delete unmerged branches automatically. Flag them in the report
for human review.

This is pure housekeeping that nobody wants to do manually. The audit report gives you visibility into what's lingering, and the auto-deletion of merged branches keeps things clean without risk.

4. Release Prep Automation

Release days involve a predictable checklist: bump the version, update the changelog, check that migration guides are current, tag the commit, maybe update some environment configs. It's mechanical work that's easy to mess up when you're rushing.

Trigger this when you create a GitHub release or push a tag matching your release pattern:

{
  "action": "published",
  "release": {
    "tag_name": "v2.4.0",
    "name": "v2.4.0",
    "body": "## What's New\n- CSV export for analytics dashboard\n- Improved error handling in payment flow\n- Bug fix: session timeout on mobile",
    "prerelease": false,
    "target_commitish": "main"
  },
  "repository": {
    "full_name": "org/product-api"
  }
}

Cloud Agent Prompt Template:

A new release has been published:

{{bodyJson}}

Prepare the repository for this release:

1. Update version numbers in all relevant files (package.json,
   pyproject.toml, version.go, etc.) to match the tag
2. Generate a CHANGELOG entry for this version:
   - Use `git log` to collect all commits since the previous tag
   - Group by type (feat, fix, refactor, docs, chore)
   - Include PR numbers where available (parse from commit messages
     or use `gh pr list --state merged`)
3. Check that README version badges reference the new version
4. If a MIGRATION.md or UPGRADING.md exists, verify it covers any
   breaking changes found in the commit log
5. If breaking changes exist but aren't documented, create a section
   in the migration guide with the relevant commit details
6. Commit: "chore(release): prepare v{{body.release.tag_name}}"

Do not modify application logic or tests.

The agent handles the tedious release bookkeeping so your release process is consistent every time. No more forgetting to update the changelog or missing a version reference buried in a config file.

5. Scheduled Test Coverage Gap Analysis

Test coverage reports tell you a number. They don't tell you which gaps actually matter or write the tests to fill them. An agent can do both.

Run this on a weekly cron, or trigger it after a milestone is closed:

{
  "task": "coverage-gap-analysis",
  "coverage_threshold": 70,
  "focus_dirs": ["src/api/", "src/services/"],
  "skip_patterns": ["*.test.*", "*.spec.*", "__mocks__/"]
}

Cloud Agent Prompt Template:

A test coverage analysis has been triggered:

{{bodyJson}}

Analyze and improve test coverage:

1. Run the project's test suite with coverage reporting enabled
2. Parse the coverage report to identify files below
   {{body.coverage_threshold}}% coverage
3. Filter to files in the focus directories, excluding skip patterns
4. For the 5 files with the lowest coverage:
   - Analyze what's untested (uncovered branches, functions, edge cases)
   - Write tests that cover the most critical untested paths
   - Prioritize: error handling > core business logic > utility functions
5. Run the test suite again to verify new tests pass
   and coverage improved
6. Generate `coverage-report.md` with:
   - Before/after coverage percentages per file
   - Summary of what was tested and why those paths were prioritized
7. Commit: "test: improve coverage for [module/area]"

Write tests that follow existing test patterns and conventions
in the project. Do not refactor source code to improve testability.

Scoping to the 5 worst files per run keeps PRs reviewable. Over a few weeks of scheduled runs, coverage steadily improves without anyone grinding through it manually.

Note on runtime: If your full test suite takes more than 10-12 minutes, configure the agent to run a targeted subset (e.g., only tests in the focus directories). Each Cloud Agent message has a 15-minute execution window.

6. First-Time Contributor Support

Open source projects lose contributors at the first PR. The experience is often: submit a PR, wait days for review, get a list of style violations and missing tests, feel overwhelmed, disappear. An agent can smooth that onboarding curve significantly.

Wire up a GitHub webhook that fires on pull_request.opened. Filter in your GitHub webhook settings (or in the prompt) for first-time contributors:

{
  "action": "opened",
  "pull_request": {
    "number": 187,
    "title": "Add dark mode toggle to settings page",
    "body": "Implements dark mode toggle as described in #142.",
    "user": {
      "login": "new-contributor"
    },
    "head": {
      "ref": "feature/dark-mode-toggle"
    },
    "author_association": "FIRST_TIME_CONTRIBUTOR"
  },
  "repository": {
    "full_name": "org/open-source-project"
  }
}

Cloud Agent Prompt Template:

A pull request has been opened by a first-time contributor:

{{bodyJson}}

If author_association is not "FIRST_TIME_CONTRIBUTOR", stop here.
No action needed for returning contributors.

Help this contributor get their PR ready for review:

1. Check out their branch and review the changes
2. Check if tests exist for the new/modified code. If not, write
   tests following the project's existing test patterns and push
   them to the contributor's branch
3. Run the linter and formatter. If there are violations, fix them
   and push a commit: "style: fix lint/format issues"
4. Check if the PR description references an issue. If the linked
   issue has acceptance criteria, verify the implementation covers them
5. If CONTRIBUTING.md exists, check the PR against its requirements
   (commit message format, branch naming, etc.) and fix what you can
6. Create a welcoming comment on the PR (using `gh pr comment`)
   summarizing what you did:
   - Tests added or adjusted
   - Style fixes applied
   - Any remaining items the contributor should address

Be encouraging. This may be their first open source contribution.

The agent doesn't replace human code review. It handles the mechanical stuff (linting, test scaffolding, format fixes) so that when a maintainer does review, the conversation is about the actual implementation rather than style violations. For the contributor, the experience goes from "wall of automated check failures" to "an agent cleaned up the small stuff, here's what's left."

7. Post-Deploy Smoke Test + Rollback Alert

You've deployed. CI passed. But does the thing actually work in production? Smoke tests catch the gaps between "tests pass in CI" and "the app works for real users."

Trigger a webhook from your deployment pipeline (GitHub Actions, ArgoCD, a deploy script) after a successful deploy:

{
  "event": "deploy_completed",
  "environment": "production",
  "service": "api-gateway",
  "deploy_commit": "a1b2c3d",
  "deploy_url": "https://api.yourproduct.com",
  "health_endpoint": "/health",
  "critical_endpoints": [
    { "method": "GET", "path": "/api/v1/status" },
    { "method": "GET", "path": "/api/v1/config" }
  ],
  "previous_commit": "e4f5g6h",
  "rollback_branch": "release/2.3.9"
}

Cloud Agent Prompt Template:

A deployment has completed:

{{bodyJson}}

Run post-deploy verification:

1. Use curl to hit the health endpoint and verify a 200 response:
   `curl -s -o /dev/null -w "%{http_code}" {{body.deploy_url}}{{body.health_endpoint}}`
2. For each critical endpoint, make a request and verify:
   - Response status is 2xx
   - Response time is under 2 seconds
   - Response body is valid JSON (if applicable)
3. Check the deploy commit's diff against the previous commit to
   identify which files changed
4. If any endpoint fails:
   - Document the failure details in `deploy-smoke-report.md`
   - Include the failing endpoint, status code, response body, and
     which files in the deploy diff are most likely related
   - Use `gh issue create` to open a P1 issue with the failure details
5. If all endpoints pass, create `deploy-smoke-report.md` confirming
   the deploy is healthy with response times for each endpoint
6. Commit: "chore: post-deploy smoke test report for {{body.deploy_commit}}"

This is verification only. Do not modify application code.

The agent runs basic health checks immediately after deploy and, if something's wrong, opens an issue with the failure context and the relevant diff. It's not a replacement for a full monitoring stack, but it catches the "deploy broke something obvious" cases within minutes instead of waiting for user reports.

Important: Your Agent Environment Profile needs network access to hit those endpoints. If your production environment is behind a VPN or firewall, the Cloud Agent container won't be able to reach it. This works best for publicly accessible APIs or services with external health endpoints.

Wiring It All Up

Every automation above follows the same setup flow in the Kilo Dashboard at app.kilo.ai/cloud/webhooks:

Create an Agent Environment Profile with the env vars, secrets, and startup commands your automation needs. Install any tools not in the base image via startup commands. Profiles are reusable across triggers.
Configure a Webhook Trigger with your prompt template and target repo. The trigger resolves the profile at runtime, so profile updates automatically apply to future executions.
Copy the webhook URL and configure your external system to POST to it. GitHub webhook settings for repo events, a cron job for scheduled tasks, your deploy pipeline for post-deploy flows.

For personal accounts, webhook sessions run in your Cloud Agent container and you can watch them execute live. Organization webhooks run in dedicated compute as a bot user, with completed sessions available to share or fork.

If you're building automations with Cloud Agents, share what you're running in the #cloud-agents channel on Discord.

Forem: Darko from Kilo

4 Advanced OpenClaw Recipes For Personal FInance Nerds

Recipe 1: Budget Reality Check

Recipe 2: Paycheck Planner

Recipe 3: Subscription Creep Auditor

Recipe 4: Bill Cutting Sprint

Why This Works Without a Budgeting App

You Can’t Gentle Parent Your OpenClaw Bot

What gentle parenting actually gets you (with a bot)

How OpenClaw Actually Works

Three Things That Actually Work

1. Tell it to write things down. Explicitly.

2. Edit SOUL.md when behavior is fundamentally wrong

3. Run /context list before you troubleshoot anything

The Actual Mindset Shift

How to Rewrite 1,000 Ecommerce Product Pages in an Afternoon with OpenClaw

Step 1: Audit What's Broken

Step 2: Rewrite Every Description at Once

Step 3: Edit What's Already There

Step 4: Fix Your Product Images

Step 5: Push to Every Channel

Step 6: Close the Loop With Reviews

The Skill That Makes Everything Better Over Time

The Full Pipeline

Trinity-Large-Thinking is Free in Kilo for a Limited Time

The Architecture: Massive Scale, Insane Efficiency

The Agentic Edge: Perfect for KiloClaw

Top of the PinchBench Index

PinchBench v2: Call for Contributors to the Leading OpenClaw Benchmark

The Remarkable Rise of PinchBench

What We're Building

Open Call for Contributions

Skills Contributions

Leaderboard Contributions

How to Contribute

Recognition

Get Involved

The Cost of Always-On Agents is Less Than You Might Think

The Outdated Way to Think About Cost

What the Data Actually Shows

What $10 Gets You in OpenClaw

Without Agents: Linear Output

With KiloClaw: Compounding Output

Why "Agentic Engineering" Was Inevitable

We Tested MiniMax M2.7 Against Claude Opus 4.6

Test Design

Test 1: Full-Stack Event Processing System

Architecture

Test Coverage

Test 1 Scoring

Test 2: Bug Investigation from Symptoms

Bug #1: Race Condition in Inventory

Bug #4: Floating-Point Totals

Remaining Bugs

Test 2 Scoring

Test 3: Security Audit

Where the Fixes Diverged

Test 3 Scoring

Overall Results

The Bigger Picture

Takeaways

Talk to the Claw: The Interface Is Now a Single Sentence

Twelve Tools, One Front Door

The New Interface is the Front Door We Always Needed

How KiloClaw Is Built to Be Secure

What makes KiloClaw different from your "typical OpenClaw hosting SaaS"

Each instance is an isolated virtual machine

Five layers of isolation

1. Identity-based routing

2. A dedicated application environment

3. Network isolation

4. The Firecracker VM boundary

5. Dedicated encrypted storage

What about my API keys?

Your data is protected in transit and while stored

What happens when I delete my instance?

What about prompt injection?

Authentication is designed to reject uncertainty

What we tested with an independent security assessor

Security is an ongoing practice

3. Run `/context list` before you troubleshoot anything