DEV Community: Darko from Kilo

Cloud Agents Just Got a Big Upgrade

Darko from Kilo — Tue, 14 Apr 2026 12:21:19 +0000

Since we launched Cloud Agents, tons of developers have used them to build from browsers, phones, and tablets — no local machine required. We've learned a lot from watching how people actually work with them.

This update is the result. Remote connections, reasoning effort, and a wave of quality-of-life improvements that make Cloud Agents feel more embedded in your workflow.

Here's what's new.

Remote Connections: Reach Your Local Sessions From Anywhere

This is the headline feature, and it changes how Cloud Agents fit into your workflow.

You can now connect Cloud Agents directly to a running session on your local machine. Your computer handles the compute. The cloud gives you a window into it from anywhere.

The classic scenario: you start a session in the Kilo CLI, need to leave your desk, enable remote mode with /remote, and suddenly you can check in on that session from your phone or browser — watching it progress, answering questions, without being tied to your machine.

To get started, enable remote mode in your CLI with the /remote command:

Once remote mode is enabled, your active local sessions show up right in the Cloud Agents dashboard:

This isn't read-only access. The full interactive experience works through the 2-way connection:

The session in the Kilo CLI

The same session in Cloud Agents

Answer questions where you prefer. When the agent needs clarification, the prompt shows up both in your CLI and the cloud. Answer it wherever you are.

Permission dialogues work too. Cloud Agents respect the same permission model you're used to. When the agent wants to run a command or modify something sensitive, the permission dialogue routes to wherever you're connected. You stay in control of what the agent can do, regardless of where you're checking in from.

The result is that "cloud" and "local" stop being separate things. It's just Kilo Code, running on your machine — and reachable wherever you are. Read the docs to get started.

Cloud Agents as Your Agent Manager

One pattern we're seeing more and more: developers using Cloud Agents not just as a convenience, but as a coordination layer for running multiple agents in parallel.

Start several sessions at once — each working on a separate PR, a targeted review, or a specific task — and use the dashboard as your control panel. While one agent is adding missed translations to an open PR, another is doing a focused review comparing your implementation against a reference codebase. You're not waiting on any of them.

Some real examples from our own team:

Spinning up a cloud agent to add translations that were missed in a locally-built PR, without interrupting local work
Running multiple perspective-specific code reviews on a single PR — each agent looking at it from a different angle, all posting their findings as review comments — like this research issue that was created entirely with Cloud Agents, including the follow-up comments
Building several PRs in parallel in the cloud, then testing and iterating on them one by one locally
Delegating "implement X" or "open a PR for issue Y" tasks to cloud agents while staying focused locally on the work that actually needs your attention

The key advantage over local: cloud sessions don't stop when you close your laptop or step away. Your local environment is for the things you want to actively test. The cloud handles everything that just needs to run.

Quality of Life, Everywhere

Beyond the headline features, we've shipped a wave of improvements that make Cloud Agents much more usable as a daily driver.

One unified page. Cloud Agents is now a single dashboard where you can both start new sessions and see all your existing ones. Previously, active sessions lived on a separate Sessions page — that split is gone.

Sessions grouped by day. Your session history is organized by day, so it's easy to scan what was open yesterday, what you started over the weekend, and what you're picking up today. Context at a glance.

Delete sessions when you're done. Small, but genuinely useful. When a task is complete and the session has served its purpose, you can remove it. Keeping your dashboard clean makes it much easier to track what's actually in flight.

Rename sessions. Give sessions meaningful names so you can find them instantly when you need to come back.

Auto-detect repo from pasted URLs. Paste a GitHub or GitLab link and the repo picker fills in automatically — one less thing to do manually.

And a whole list of under-the-hood improvements:

Faster session startup and reduced cold-boot times after idle periods
Improved session state indicators so you always know what's happening
Better error handling and recovery when connections drop
Smoother scrolling and interaction in long chat sessions
Persistent sidebar filters
UI polish and bug fixes throughout the dashboard

Cloud Agents should feel noticeably snappier and more reliable across the board.

One Workflow, Anywhere

Cloud Agents started as a browser experience. With this update, they connect directly into your local development setup — and they've become a credible coordination layer for managing multiple agents at once.

Start a session locally, check in from your phone on the train. Spin up three agents in parallel, then test their output one by one. Name your sessions, clean up the ones you're done with, and keep your focus on what matters.

It's all one continuous workflow. The boundaries between local and cloud keep getting thinner.

Try It Now

If you're already using Kilo Code, you're a few clicks away:

Open Cloud Agents and start a session
Or start a session locally in the Kilo CLI, run /remote, and watch it become accessible from the cloud dashboard
Check in from wherever makes sense — browser, phone, or terminal

Cloud Agents compute remains free during the beta period. Kilo Credits are used for AI reasoning, as they are in the IDE and CLI.

We're building Cloud Agents based on what you tell us. Drop into our Discord and let us know what you think. We want to know how they fit into your day-to-day life.

Your next session is waiting.

Start Cloud Agents

AI Agents Are Coming for Every Role

Darko from Kilo — Tue, 14 Apr 2026 12:03:09 +0000

A year ago, I couldn't write a line of code. I'm a growth person — marketing, funnels, data. Then I joined Kilo and started using an AI coding agent in my IDE. I didn't learn to code. I learned to manage agents that code.

Since then, I've shipped landing pages, internal dashboards, and small automation tools — none of which I could have touched 12 months ago. It fundamentally changed how I work. And I'm convinced that what happened to me is about to happen to almost every knowledge worker.

Developers were first. Everyone else is now.

Over the past year at Kilo, we watched millions of developers adopt coding agents. Many tried a coding agent, hit the rough edges, shrugged it off. A few months later they tried again. The models and tooling had improved, and suddenly the skeptics were using agents daily.

That curve is now repeating for every other role.

But the developer wave revealed something bigger than a productivity gain. The role itself changed. Developers stopped being the ones who write the code and became the ones who direct it. That's not a subtle shift. It's a different job. And it's coming for every knowledge worker next.

Part of what's accelerating that shift is OpenClaw. Where early coding agents were built for developers living inside a code editor, OpenClaw connects to email, Slack, calendars, and documents. It's not a coding tool. It's an orchestration layer for any kind of work. That's the bridge from software teams to everyone else. KiloClaw is the hosted version. No server setup, no API key juggling, no maintenance. Just the orchestration layer, ready to use.

What it looks like in production

Last week I ran into Anelya Grant, Chief Product Officer at JustPaid, a Y Combinator-backed fintech startup. Her team replaced most of their engineering workflow with seven AI agents, built on OpenClaw and coding agents, each with a defined role, running 24/7. In one month they shipped 10 major features. The human engineers became directors.

But engineering teams aren't the only ones paying attention.

Pedro Franceschi is 29 years old and CEO of Brex, which was acquired by Capital One for $5.15 billion. He's decomposed his own job using OpenClaw. A signal ingestion pipeline screens his email, Slack, Google Docs, and WhatsApp, filtering everything through his priorities and the 25 people he cares most about. Granola runs on every meeting, feeds transcripts into the pipeline, and auto-generates action items. For each to-do, the system pulls context from the original meeting and drafts the follow-up. Slack message, email, or text. Pedro just has to click approve.

He also built a virtual recruiter named "Jim" who lives in Slack with his own email address and taught himself to screen fabricated resumes, without anyone explicitly coding that capability. And a security layer called "Crab Trap" intercepts all agent network traffic through an LLM proxy: a second AI monitoring the first in real time.

This is a CEO offloading the cognitive overhead of running a company. And Pedro is just one person. People are already taking this further, trying to run entire engineering teams and companies on agents. Frameworks like Paperclip and Gas Town have emerged specifically for that: orchestrating teams of agents, assigning roles, coordinating work in parallel, and keeping humans in an oversight position rather than an execution one.

The gap between chaos and leverage

Success with agents isn't just about model quality, though that matters. It's about how well you can isolate a task, delegate it clearly, and review the output. The skill that matters isn't prompting. It's the ability to break work down, direct it precisely, and know what good output looks like. That's a human skill. Agents amplify it. Here's a collection of use cases across different roles. Copy any of them straight into KiloClaw to start learning by doing.

The other thing that separates the people who get results from the ones who don't is simple: they keep experimenting. Many engineers dismissed coding agents the first time around for exactly this reason. The ones who succeeded didn't wait for the technology to be perfect. They kept experimenting, iterated quickly, and got better at using it through doing.

Real work is also messy and noisy in ways a vague instruction doesn't always capture. That's why OpenClaw doesn't just respond to requests. It learns your preferences over time and acts proactively on your behalf. With that kind of access comes real responsibility. It's why we invest heavily in security and think carefully about what tools and access each agent actually needs to do its job.

The shift that's already underway

The people who adapt will look a lot like I do today: not technical in the traditional sense, but capable of shipping things. Not doing all the work, but responsible for its quality and direction. I watched this happen to developers over 12 months. I experienced it myself. It's coming for every role that runs on thinking, writing, deciding, and communicating, which is most of them.

Nobody announced the moment developers became orchestrators. It just happened, gradually then all at once. The same shift is underway for every other role.

Exciting times to be learning how to 10x yourself.

Get KiloClaw Now

Five Slices of Swiss Cheese Between Your Agent and Everyone Else

Darko from Kilo — Tue, 14 Apr 2026 11:57:08 +0000

In 1990, psychologist James Reason published a model for understanding how catastrophic failures happen in complex systems. He'd been studying aviation disasters and hospital errors — situations where multiple safeguards existed but people still died. No single safety layer is perfect. Every defense has holes in it. The dangerous moment is when the holes in every layer happen to line up at the same time.

He called it the Swiss Cheese model. Each defensive layer is a slice of Swiss cheese. Each slice has holes — weaknesses, gaps, edge cases. Stack enough slices together and the odds of a threat passing through every hole simultaneously become vanishingly small.

The model transformed how the aviation industry thinks about safety. It changed healthcare protocols. And it turns out to be a useful way to think about securing AI agents that can execute arbitrary code on your behalf.

Why AI Agents Need More Than One Layer

Most SaaS platforms keep customer data in shared infrastructure. A single database, shared compute, application-level logic deciding who sees what. If the application logic has a bug, that's your one layer of defense — and it just failed.

That's manageable when your SaaS product is a project management tool or a CRM. The blast radius of a tenant isolation failure is data exposure.

AI agents are different. An OpenClaw agent can run shell commands, browse the web, read and write files, connect to your Slack, Telegram, or Discord and has API keys for all of those and more. If tenant isolation fails for an AI agent platform, the attacker doesn't just see your data — they potentially have access to everything your agent can do.

A single-layer approach isn't enough. You need defense in depth — Swiss cheese, in safety engineering terms.

KiloClaw's Five Slices

Darko wrote a detailed post on the Kilo blog covering KiloClaw's security architecture, and it maps cleanly to the Swiss Cheese model. There are five independent layers of tenant isolation. For one customer to access another's data, all five would have to fail simultaneously.

Here's what those layers look like:

Slice 1: Authentication & Access Control

Every request is authenticated before it reaches a customer's machine. The routing destination comes from the authenticated user identity stored server-side, not from anything the user controls in the request.

This matters because the most common class of tenant isolation bugs in SaaS products is Insecure Direct Object Reference — where you change an ID in a URL or API call and access someone else's stuff. KiloClaw sidesteps this entirely by never letting the user specify the destination.

Slice 2: Application Isolation

Each customer's VM runs inside a dedicated Fly.io application. Not a shared app with per-user containers — a separate application entirely. One customer's storage can't be attached to another customer's machine. Internal networks are isolated at the application boundary.

Slice 3: Network Isolation

Each customer environment sits on its own isolated WireGuard network mesh. During the independent security assessment, cross-tenant network tests confirmed that customers can't discover each other's machines and can't connect directly across applications.

This is the kind of claim that's easy to make and hard to verify. Which is why it was tested by a third party, not just asserted.

Slice 4: Process Isolation

Each workload runs inside its own Firecracker microVM — the same virtualization technology that powers AWS Lambda and AWS Fargate. Firecracker provides hardware-level virtualization, not just container isolation. Each VM has its own kernel.

This is the layer that matters most for AI agents specifically. If an agent gets manipulated through prompt injection — a malicious webpage or message tricks it into running something it shouldn't — the blast radius is limited to that customer's own VM. There's no shared kernel, no shared filesystem, no shared process space with other customers.

To escape that boundary, you'd need a vulnerability in the Firecracker hypervisor itself. Possible in theory, but Firecracker is also what Amazon trusts to isolate millions of Lambda functions from each other.

Slice 5: Storage Isolation

Each customer gets a dedicated encrypted persistent storage volume. That volume can only be mounted inside the customer's own application environment. There's no API, no configuration option, no path by which another customer's machine can access it.

When you destroy a KiloClaw instance, a two-phase cleanup process destroys the encryption keys, making the stored data unrecoverable. Not "deleted and maybe recoverable with forensics" — the keys are gone.

What Happens to Your Secrets

API keys and chat tokens — the things that would be most damaging if exposed — are encrypted with RSA-OAEP and AES-256-GCM in the platform database. They're decrypted only when your VM starts, and they're only available inside your isolated environment.

All external traffic uses TLS. Storage is encrypted at rest. The encryption isn't optional or configurable — it's how the platform works.

The Exec Problem

One thing unique to AI agent platforms: the exec tool. OpenClaw agents can run shell commands, which is the whole reason they're useful — and the whole reason security matters.

KiloClaw's approach is to require explicit user approval before the exec tool runs anything, by default. The approval requirement is enforced by the platform itself — not by the agent, not by the prompt, not by configuration that could be overridden through prompt injection. The agent literally cannot bypass it.

This is worth calling out because in the Swiss Cheese model, the most dangerous failures are the ones where a safety layer can be disabled by the thing it's supposed to protect against. A prompt injection attack that can turn off exec approval would collapse two layers into zero. KiloClaw prevents that by putting the control outside the agent's reach.

Independent Testing

In February 2026, Andrew Storms conducted a 10-day security assessment of KiloClaw. The work included threat modeling using the PASTA framework across 30 threats and 13 assets, code review, and adversarial testing — 35 tests targeting tenant isolation specifically, including Unicode edge cases, zero-width characters, null bytes, and injection payloads. Eight live cross-tenant network tests were run across separate customer environments.

Results:

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

The assessment also produced 17 merged pull requests — 10 security fixes and 7 hardening improvements. Finding things to improve is a sign of a good assessment, not a bad product.

No Layer Is Perfect

The Swiss Cheese model is honest about something that security marketing usually isn't: every layer has holes, and they all rely on understanding below the surface.

James Reason developed this model because the aviation industry kept making the same mistake: assuming one really good safety system was enough. It never was. What worked was redundancy across independent systems that fail in different ways.

KiloClaw's five layers — authentication, application isolation, network isolation, process isolation, and storage isolation — are enforced by different technology at different levels of the stack. A bug in one doesn't compromise the others. An attacker who gets past one still faces four more.

For a platform where AI agents run arbitrary code with access to your API keys and communication channels, that kind of redundancy isn't optional.

The KiloClaw security white paper has the full technical details. Darko's blog post is a good summary if you want the overview without the PDF.

Introducing Elephant: A New Stealth Model, Free in Kilo

Darko from Kilo — Tue, 14 Apr 2026 11:46:36 +0000

We love giving the Kilo community a chance to test cutting-edge capabilities before they are fully unmasked.

Today we're thrilled to introduce Elephant, a new 100B-parameter stealth model from a prominent open model lab.

What is Elephant?

Elephant is an "instant" model designed with a primary focus on Intelligence Efficiency. In a landscape often dominated by massive, compute-heavy giants, Elephant strikes a different balance: it aims to deliver performance comparable to State-of-the-Art (SOTA) models of its scale while significantly reducing token usage.

It is specifically optimized for:

Rapid Code Completion & Debugging: Fast, logical suggestions that keep you in the flow.
Massive Document Processing: Handling long-context information without the latency typical of larger models.
Lightweight Agent Interactions: Ideal for quick, iterative tasks within an agentic workflow.

It's a jungle out there. Elephant moves quickly to get the job done. 🐘

Technical Specs

Elephant is a text-modality powerhouse equipped with features that maximize efficiency for enterprise-style development.

Context Length: 256K tokens (enough to load entire repositories or massive dependency trees).
Max Output: 32K tokens (perfect for single-pass generation of entire modules or test suites).
Prompt Caching: Dramatically reduces costs and latency for repetitive, long-context tasks.
Function Calling & Structured Output: Built for reliable integration into agentic toolchains.

Comparison: Elephant vs. Giga Potato

Many of you will remember Giga Potato, our most popular stealth model ever. Elephant has a similar context window and max output, but it comes from a different lab and the models were built for different roles in your development lifecycle.

For example, when it comes to powering agents that deal with documents and documentation, Giga Potato stood out for deep document generation, especially technical documentation, while Elephant excels more at rapid document processing.

Giga Potato was great at producing technical documentation. Elephant is a good fit for your KiloClaw agent that's running through new research reports on a daily basis and turning them into suggested LinkedIn content.

Elephant is designed to be your "snappy" daily driver. It should feel leaner and faster—like a top-of-the-line appliance—without sacrificing the logic required for production-grade software engineering.

Available Everywhere in Kilo

Elephant isn't just a chat model, it's a fully integrated component of the Kilo ecosystem. You can start using it today for free across all our surfaces:

VS Code Extension: Try Elephant for building a new feature or landing page in one shot.
Kilo CLI: Run Elephant directly from your terminal for git-integrated agentic development.
KiloClaw: Try Elephant to keep your daily agentic tasks going with KiloClaw, the always-on AI assistant.

We encourage you to push the 256K context window to its limit and let us know how it performs on your most challenging codebases. Find this new stealth model now in the Kilo model selector—search for "Elephant" and start building your agentic pyramid.

Elephant is Free to use in Kilo during this stealth preview period.

Note that during the period, prompts and completions are logged by the model provider. This data is used strictly to improve the model's performance and reasoning capabilities during this testing phase.

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.

DEV Community: Darko from Kilo

Cloud Agents Just Got a Big Upgrade

Remote Connections: Reach Your Local Sessions From Anywhere

Cloud Agents as Your Agent Manager

Quality of Life, Everywhere

One Workflow, Anywhere

Try It Now

AI Agents Are Coming for Every Role

Developers were first. Everyone else is now.

What it looks like in production

The gap between chaos and leverage

The shift that's already underway

Five Slices of Swiss Cheese Between Your Agent and Everyone Else

Why AI Agents Need More Than One Layer

KiloClaw's Five Slices

Slice 1: Authentication & Access Control

Slice 2: Application Isolation

Slice 3: Network Isolation

Slice 4: Process Isolation

Slice 5: Storage Isolation

What Happens to Your Secrets

The Exec Problem

Independent Testing

No Layer Is Perfect

Introducing Elephant: A New Stealth Model, Free in Kilo

What is Elephant?

Technical Specs

Comparison: Elephant vs. Giga Potato

Available Everywhere in 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

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