In this article, I want to take a closer look at one of the most talked-about projects recently: Clawdbot — now reborn as Moltbot after a trademark complaint from Anthropic forced a name change.
As the name suggests, it has shed its old skin. But has it truly become stronger?

Right now, communities like X and Reddit are on fire over Moltbot. This AI runs 24/7, all year round. One viral post claimed that a user entrusted the bot with $1 million in capital to manage. The bot reportedly analyzed over 3,000 reports in real time, charted every technical indicator, and executed stock trades nonstop.

The result?
All the money was lost — but, as the post jokingly put it, “the process was beautiful.”

At this very moment, people are posting screenshots of Moltbot automatically sending affectionate messages to their girlfriends, writing complex code, or trading stocks on their behalf. Yet the developer has been clear: this started as a personal hobby project, meant to inspire people — not a magic tool to make them rich.

Despite that, many have misunderstood it as a shortcut to becoming a millionaire. Some even claim there’s a Mac mini shortage because people are buying them in bulk just to run Moltbot 24/7.

So what exactly is this thing? And why are people reacting this way?

Let’s break it down — and then look at it honestly from a developer’s perspective.

Installation & Setup (Quick Notes)

Since many readers have already heard about Moltbot, I’ll keep this short.

One small tip: I initially tried installing it via npm, but ran into a missing CLI error. Reinstalling via curl worked without issues.

During setup, you’re greeted with a rather alarming warning: the bot can control your file system. This is not something to click through lightly. Read it carefully before proceeding.

You then enter onboarding, where you choose a model. Instead of entering an API key (and risking surprise billing later), I opted for Google OAuth, since I already subscribe to Gemini. I selected Gemini 2.5 Pro for better performance.

You’re asked about channels, skills, hooks, gateways, and execution environments. Many of these involve fairly powerful permissions. I skipped most of them for now and chose to run the bot in the terminal UI, which the project itself recommends.

Once launched, a browser window opens alongside the terminal. The bot asks for your name — and from there, you can literally watch it store and remember information about you in real time.

That’s enough for the walkthrough. Now let’s talk about what actually matters.

1. The Real Innovation: Not Technology, but Positioning

Moltbot’s GitHub stars are skyrocketing, and there’s a reason.
But if we strip things down to their technical essence, Moltbot is not fundamentally new technology.

Calling LLMs, storing state, connecting external tools — all of this can already be done with Claude Skills, ChatGPT Actions, LangChain, or Zapier. Even the so-called “gateway” is, in practice, just a long-running bot with webhooks and a scheduler.

So why are people so impressed?

Because the innovation isn’t how it works — it’s where it lives.

Traditional AI tools like ChatGPT require you to open an app and initiate work. You are always in control. Moltbot, on the other hand, lives inside your messenger — WhatsApp, Telegram, the same place you already spend your day. It’s always on. Always present.

If ChatGPT suddenly started messaging you first, it would feel like spam.
But Moltbot feels like a personal assistant.

The technology is similar. The UX and power dynamics are not.

Who controls the conversation?
Who is always running?

This shift — the idea of an AI agent that lives where you live — is the first reason people are excited.

The One Genuine Technical Differentiator: Disk-Based Memory

There is, however, one truly meaningful technical distinction.

Moltbot uses the local hard disk as long-term memory.

Most cloud AIs eventually forget earlier context as conversations grow longer. Moltbot stores conversations and state as files and reloads them later. As long as your disk has space, memory is effectively unlimited.

This disk-backed, persistent memory model is genuinely hard for traditional cloud services to replicate — and it is Moltbot’s strongest technical advantage.

2. Model Limitations and the Refactoring Hell Problem

Despite its innovative positioning, there are serious concerns from a professional developer’s perspective.

Memory Is Not Truth

Many people assume that because the bot “remembers,” it will automatically improve over time. That’s a dangerous misunderstanding.

Without a Single Source of Truth, persistent memory simply preserves mistakes along with correct information.
If your system doesn’t have a top-level constitution — immutable rules that override everything else — the AI will faithfully repeat bad assumptions forever.

Right now, Moltbot lacks this.

The Inability to Stop

This is the most critical issue.

Agents like Moltbot suffer from the same fundamental problem that plagued Auto-GPT: once they start down a wrong path, they don’t know when to stop.

Humans feel uncertainty. When something feels off, we pause, reconsider, or ask for help. Current LLM-based agents don’t. If the initial assumption is wrong, they keep building on it, refactoring again and again — until the entire project collapses into a mess.

This isn’t a Moltbot-specific design flaw. It’s a limitation of today’s models.
They lack robust uncertainty detection and the ability to say, “I’m not sure — I need human input.”

The result is what many developers have experienced firsthand: refactoring hell.

In short, Moltbot is an excellent proposal for where AI should live — but the underlying model maturity isn’t there yet for it to be a primary development tool. For now, it should be treated as a powerful experimental platform, not production infrastructure.

3. About the Mac Mini Frenzy

Finally, let’s talk hardware.

The model limitations I mentioned will improve over time. And when they do, we’ll move away from cloud APIs toward local, always-on intelligence. That’s the future Moltbot hints at.

For that reason, I don’t recommend buying a base-model Mac mini just to run Moltbot today.

But if your goal is to someday run Gemini-2.5-Pro-level intelligence locally, without worrying about usage fees, that’s a different story.

In that future, the most important spec won’t be CPU speed.

It will be memory.

I strongly believe that machines with at least 64GB of RAM will become the foundation of personal AI infrastructure. Prepare for that future, and you’ll be ready when the models finally catch up.

Thanks for reading.
If you have thoughts or questions, I’d love to continue the discussion in the comments.

I’ve often missed writing consistently due to a busy schedule, so I’ve decided to start a weekly series titled “Weekly Development Activity Briefing.” In this series, I plan to address the challenges faced during development each week.

Currently, my primary focus is on React Native development, so most of the content will revolve around that. For this week, I’ll briefly cover three key issues.

First, let’s address the issue related to the KeyExtractor in FlashList.

The issue occurs intermittently when using FlashList and seems to resurface with each new development cycle.

To briefly explain the issue: when using FlashList, if you scroll quickly through a list that has pagination applied, you may encounter a warning about a possible stableId collision.

<FlashList
  data={data}
  keyExtractor={(item: any, i: number) => `${i}-${item.title}`}
  renderItem={({item}) => (
    <View
      style={css`
        padding: 16px;
      `}
    >
      <Typography.Body2>{item.title}</Typography.Body2>
    </View>
  )}
  estimatedItemSize={10}
/>

The issue can be easily resolved by using useCallback.

This issue appears to be a typical concurrency problem in React, so I addressed it as follows:

Secondly, there is an issue related to the Android debug keystore.

When implementing features like Google login in React Native, it’s crucial to thoroughly test in a debug environment before moving to production. Typically, developers with Android experience know that on macOS, the debug keystore can be found in the ~/.android directory. I’ve repeatedly made the same mistake of overlooking this, often encountering “Developer Error” as a result. Each time, I had to rely on recalling past experiences to resolve the issue.

Typically, when you create an Android project in React Native, a debug.keystore is generated within the app directory. You need to extract the SHA-1 value from this keystore and add it to your social provider's dashboard to ensure that social logins and other features work correctly in the testing environment.

Thirdly, there is an issue related to the new architecture on Android.

After applying the new architecture and adding a Pressable button to the headerLeft in expo-router to navigate back, I found that it didn’t work as expected. Upon investigating, I discovered that this issue is related to react-native-screens. Interestingly, while onPress doesn’t work, pressIn does trigger the action. Additionally, this issue only occurs on physical devices; the button works fine on the emulator.

For now, it seems that using RectButton from react-native-gesture-handler can resolve the issue. If you found this helpful, I’ll continue to post these weekly briefing series. If you prefer to read the articles in Korean, please subscribe to the CrossPlatform-Korea YouTube channel.

3 Recent React Native Development Notes was originally published in Hyo Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

해당 글은 앱 개발 입문자를 위한 안내 문서를 먼저 참고 하시고 보시는 것을 추천드립니다. 여기서는 리액트네이티브를 공부하기에 앞서 필요한 기초 지식을 다룹니다. 이번 편은 리액트입니다. 이는 개발 시작에 앞서 최소한의 내용만 숙지시키는 것이 목적입니다.

리액트네이티브의 장점 중 하나는 UI를 만들기 위해 웹에서 사용되는 CSS 문법을 사용할 수 있다는 것입니다. 이는 프레임워크마다 고수하는 다양한 UI를 만드는 기술을 습득하지 않아도 광범위하게 CSS 기술을 응용할 수 있게 해주어 개발자들에게 굉장히 큰 이점을 가져다주었습니다.

CSS(Cascading Style Sheets)는 웹 페이지의 디자인과 레이아웃을 정의하는 스타일 시트 언어입니다. 리액트네이티브에서는 CSS와 유사한 스타일링 방식을 사용하지만, 정확히 같은 문법은 아니며 ‘스타일시트’라는 이름의 JavaScript 객체를 사용하여 스타일을 정의합니다. 이 방식은 웹 개발에서의 CSS와 매우 비슷하게 느껴질 수 있지만, 카멜 케이스(camelCase)를 사용하여 속성 이름을 지정하고, 값은 대부분 문자열 대신 숫자나 객체로 표현됩니다.

import React from 'react';
import { Text, StyleSheet, View } from 'react-native';

const App = () => (
  <View style={styles.container}>
    <Text style={styles.textStyle}>Hello, React Native!</Text>
  </View>
);

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  textStyle: {
    color: 'blue',
    fontSize: 20,
  },
});

export default App;

위 코드에서 StyleSheet.create 메서드를 사용하여 container와 textStyle이라는 두 개의 스타일 객체를 정의하고 있습니다. container 스타일은 뷰의 배경색, 정렬 방식 등을 지정하며, textStyle 스타일은 텍스트의 색상과 글꼴 크기를 정의합니다. 이러한 방식으로 리액트네이티브에서도 CSS와 유사한 스타일링을 적용할 수 있습니다.

더 나아가 우리는 Emotion 라이브러리를 리액트네이티브에서 사용하고 있어 이를 사용할 것을 권장하고 있습니다.Emotion CSS 라이브러리는 스타일링을 위한 강력하고 유연한 도구로, 리액트네이티브 개발에도 적용할 수 있습니다. Emotion을 사용하면 JavaScript와 CSS의 강점을 결합하여 컴포넌트 스타일을 쉽게 정의하고 관리할 수 있습니다.

리액트네이티브에서 Emotion을 사용하는 기본 예시는 다음과 같습니다.

import React from 'react';
import styled from '@emotion/native'; // Emotion 라이브러리 임포트

// Emotion을 사용한 스타일링
const Container = styled.View`
  flex: 1;
  justify-content: center;
  align-items: center;
  background-color: #F5FCFF;
`;

const StyledText = styled.Text`
  color: blue;
  font-size: 20px;
`;

const App = () => (
  <Container>
    <StyledText>Hello, React Native with Emotion!</StyledText>
  </Container>
);

export default App;

리액트네이티브에서 스타일링을 위해 CSS 문법을 익히는 것은 중요하며, 특히 flex를 이해하는 것이 핵심입니다. 리액트네이티브의 레이아웃 시스템은 웹의 CSS Flexbox와 매우 유사하게 작동하며, 이는 모바일 앱 개발에서 유연한 레이아웃과 디자인을 구현하는 데 필수적입니다.

Flex란?

Flex는 컨테이너 내 아이템의 배치, 정렬, 그리고 분배를 위한 효율적인 방법을 제공합니다. 리액트네이티브에서 flex 속성을 사용하면 컨테이너 내에서 자식 요소들이 어떻게 배치되고 차지하는 공간을 어떻게 분배할지 제어할 수 있습니다.

기본 Flex 속성

• flex: 요소가 차지할 공간의 비율을 결정합니다. 더 높은 숫자는 더 많은 공간을 차지하게 됩니다.
• flexDirection: 주축(main axis)의 방향을 결정합니다. row (수평), column (수직) 중 선택할 수 있습니다.
• justifyContent: 주축(main axis)에 따라 자식 요소들을 어떻게 정렬할지 결정합니다. 예를 들어 flex-start, center, flex-end, space-between, space-around 등이 있습니다.
• alignItems: 교차 축(cross axis)에 따라 자식 요소들을 어떻게 정렬할지 결정합니다. 예를 들어 flex-start, center, flex-end, stretch 등이 있습니다.
• alignSelf: 개별 아이템이 교차 축(cross axis)에 따라 어떻게 정렬될지 결정합니다. auto, flex-start, center, flex-end, stretch 등을 사용할 수 있습니다.

관련하여 과거에 찍은 Flex 영상을 추천드립니다. 시청해 주시고 Flex에 대한 이해를 하고 레이아웃 배치 및 CSS에 대해 익숙해지시는 시간이 되시길 바랍니다.