Make responsibility come with control
If I must operate the system, I need to see what runs, limit its authority and stop it. Integration earns trust by absorbing that work—not merely hiding it until something breaks.
A modular alternative to OpenClaw
One agent.
Only when you call it.
Keep the sessions, browser view, schedules, and Telegram access. Lose the bundled machinery and the AI heartbeat you never asked to pay for.
No background model calls in the base setup
core
π
Pi agent
WebLivecraft
Scheduled
Taskscron
Taskscron
ChatTelePi
Historysaved locally
Apple Notes
Apple Calendar
Telegram
optional interactions
remove what you don’t need
00 / Why
Using agents to build
our own agency.
OpenClaw offered to take responsibility for the machinery of a personal assistant. In my setup, I ended up responsible for that machinery anyway.
Pi makes fewer promises about removing the assembly work. What changed is that I no longer have to do that work alone—and increasingly, I do not have to start from scratch.
Other people build useful components. Agents help me investigate, select, adapt and test them. My own improvements can become starting points for someone else.
The distinction is not simply an agent acting for me versus an agent I control. It is an agent helping me acquire the knowledge and tools to exercise more control myself.
Only afterwards did I learn that OpenClaw had been built on Pi. Discovering those shared roots changed how I saw the choice: not just which assistant to use, but which layers I actually needed.
“Pi won for me when building my own agency became easier than maintaining someone else’s abstraction.”
01 / Philosophy
The design argument
Who gets to decide
how it changes?
Both projects exist in the same era of cheaper coding. The distinction is not who can generate code. It is where decisions live, how much each change must coordinate, and whether users can make the system fit without changing it for everyone else.
My reading of OpenClaw’s appeal is that it offered agency: your assistant, your devices, your choice of connections. Its Gateway coordinates channels, sessions, policy and state. That can make powerful capabilities coherent. It also gives the shared coordinator more responsibilities to preserve when something changes.
The bottleneck is not just producing code. It is reconciling different workflows, keeping interfaces compatible, enforcing permissions and recovering safely. Cheap implementation does not make those decisions cheap. A feature can be easy to generate and expensive to fit into a shared system.
Pi’s smaller scope lets my setup leave more decisions at the edges: the operating system keeps time; a browser or messenger stays optional; a narrow integration can serve one routine. With clear interfaces, experiments need not become changes to everyone’s core. The advantage I am betting on is less compulsory coordination per personal change.
Read the strongest case on both sidesKeep personal choices local
A calendar adaptation should not require a universal calendar product. Reuse common mechanisms, but keep individual workflow choices out of the shared core where possible.
Let useful experiments accumulate
Agents can help map a problem, research options, inspect code, build connections and test the result. Share the useful pieces with documentation and tests—not just more code.
Compare real designs, not caricatures. OpenClaw is also open source, self-hostable and extensible. Its current vision favours a lean core and community plugins ↗. The distinction is the scope of its shared Gateway’s authority ↗, not “closed OpenClaw versus open Pi.” Centralising decisions in software on your machine is not the same as handing them to a company. Both projects can evolve.
Why this works for me now
Established pieces.
A personal fit.
I have used Pi to build iCal, Apple Notes and Firecrawl integrations. For larger pieces I rely on TelePi and Pi Livecraft. Trying to vibe-code equivalents reminded me that a demonstration is not a dependable product: session handling, recovery, security and design take sustained work.
My preferred interfaces were not available to me a few months ago. Their arrival changed the calculation. Pi did not always meet my needs; its growing ecosystem now lets me reuse substantial work and tailor the remaining connections. Like a tailored suit, the point is the fit—not manufacturing every material myself.
I have also used Pi to review the security of TelePi and Pi Livecraft. That helps me ask better questions, not eliminate risk. Custom extensions still have dependencies; AI reviews need verification. Local execution does not prevent a cloud model receiving the context sent to it, and a prompt is not an enforced permission boundary.
The 90s parallel—and its limits
Broad compatibility.
Or carefully chosen coherence.
This recalls sprawling desktop suites whose upgrades became projects of their own, versus the Unix tradition of narrow tools and the Linux ecosystem’s room for experimentation. Neither Unix nor Linux was magically reliable. Their useful lesson is that shared foundations need not impose one finished workflow.
OpenClaw attempts an Apple-like promise of simplicity across a Microsoft-like variety of environments. Apple’s best products earn coherence by constraining combinations, refusing features and engineering the chosen experience. Bundling alone does not achieve that—and Apple products can fail too. Even excellent standard products need not fit everyone: I find iPhones too big and would prefer a smaller one.
The parallel with open financial rails is the ability to build alternatives without asking one operator to provide every service. It is an analogy about room to experiment and exit, not a claim that openness removes intermediaries, security risks or the need for consumer protection.
Challenge the thesis
The strongest case.
And the strongest objection.
A preference becomes more useful when it explains what could make the other approach win.
For the thesis
Local decisions,
shared foundations.
- Control should match responsibility. When an integrated assistant still requires me to troubleshoot its machinery, its promise has failed in my setup. Pi makes assembly explicit and gives me more choice about which machinery exists.
- Personal experiments need not become universal features. A small extension or replaceable interface can meet one need without requiring a shared product to reconcile every user’s preferences. Stable contracts let useful experiments spread selectively.
- Changes can remain more local. A scheduler, messenger and agent need not ship in one release. Clear boundaries can reduce the reach of a change, even though APIs and shared state remain dependencies.
- Effort can leave a capability I chose. Tokens spent researching, comparing, adapting and testing an integration can produce reusable tools and understanding. Repairs can be valuable too; the point is whether effort moves the system towards my needs.
- The ecosystem can compound. TelePi and Pi Livecraft filled gaps that once limited this approach for me. Agents help users find, inspect and adapt such work; documented, tested improvements can become starting points for future users and agents.
Against the thesis
Delegation is agency,
too.
- Freedom from maintenance matters. Most people want outcomes, not a new engineering responsibility. A dependable integrated assistant can provide consistent permissions, shared state and support while leaving the user free to do something else.
- Pi’s complexity partly lives elsewhere. TelePi, Livecraft and custom extensions have bugs, dependencies and maintainers. Pi API changes can affect them. Comparing OpenClaw’s whole platform with Pi’s core alone is not a fair reliability test.
- Ownership is not a security certificate. Generated code and third-party extensions execute with real permissions. An integrated policy layer can enforce boundaries more consistently than ad hoc tools. AI-assisted reviews help, but do not guarantee safety.
- Timing and fit can explain the win. This combination only recently became sufficient for my needs. I depend on other people’s product work, and early satisfaction does not establish lower lifetime maintenance costs or suitability for everyone.
- The same coding-cost advantage is available to both. It cannot by itself explain their different outcomes. The hypothesis is about scope, coordination and change boundaries. OpenClaw can improve those boundaries; an undisciplined Pi stack can recreate the same oversized coordinator. Architecture must earn its advantage in operation.
Evaluate this thesis: when code becomes cheaper, the bottleneck moves towards deciding what to build, coordinating changes, enforcing boundaries and maintaining a coherent system. A small, extensible agent harness can let users and their agents research, design, build and test personal workflows without requiring every experiment to become a decision for a shared platform.
Steelman both sides. Make the strongest case for integrated orchestration: dependable delegation, shared state, consistent policy, credentials, recovery, onboarding and support. Then make the strongest case for a small common foundation with replaceable components: local decisions, experimentation, selective reuse, inspectability and exit.
Both OpenClaw and Pi are open source, extensible, and operate in the same era of cheaper coding. Read their current architecture and vision documents. Do not portray one as closed or claim that code generation uniquely benefits the other. Distinguish centralised runtime authority from vendor ownership, governance, data custody and business model.
Consider this user's experience: OpenClaw required upgrade repair and unwanted background-cost control; Pi became sufficient only after tools such as TelePi and Pi Livecraft were available. The user has built iCal, Apple Notes and Firecrawl integrations and used agents to review third-party tools. Separate testimony, timing, product fit and architectural hypotheses. Include the costs and security risks of the whole modular stack; do not treat AI review as certification or prompts as enforced permissions.
Ask what would falsify the preference: compare matched tasks, upgrade success, repair hours and tokens, unwanted calls, permission scope, recovery and exit costs over time. GitHub activity and stars are not failure rates. Test the Apple/Microsoft, Unix/Linux and open-financial-rails analogies without assuming that integration requires surveillance or openness guarantees safety. Conclude with when each design wins and a credible consumer-friendly hybrid.02 / Evidence
What the public record shows
Upkeep became part of the job.
The complaints are not only “it broke.” Users describe learning to stage releases, pin versions, snapshot state, run repair commands, and keep rollback paths ready—the habits of a service operator, not merely the owner of a personal assistant.
GitHub · 7 Jun–4 Sep 2026
OpenClaw
Pi
Repository audience at capture
388,931 stars
102,007 stars
Non-prerelease releases published
14 releases
32 releases
All issue reports opened
12,026 reports
2,528 reports
Reports labelled as bugs
2,942 reports
641 reports
Bugs with “update” or “upgrade” in the title
122 reports ↗
25 reports ↗
Snapshot captured 5 September 2026 using GitHub’s Search and Releases APIs. Release counts exclude drafts and prereleases. Issue counts depend on each project’s labels and reporting habits; titles miss failures described only in the body. As a share of bug-labelled reports, the highlighted figures are 4.1% versus 3.9%. Repository age, audience, scope and triage differ; Pi’s optional tools have their own issue trackers. Stars are not active installations, and these counts are not measured failure rates. OpenClaw releases ↗ Pi releases ↗
An update needed an operations plan.
Users report broken gateways, cron jobs, credentials, channels, and config after upgrades. The practical advice is revealing: wait, inspect GitHub, test separately, pin dependencies, snapshot the state directory, and know how to roll back.
The control plane multiplies boundaries.
A late-April incident joined slow gateways, plugin-repair loops, and broken chat channels in one release cycle. Current OpenClaw documentation now treats backup, health checks, Doctor, restart, and two-layer rollback as part of safe updating.
Smaller is not the same as flawless.
Pi has shipped update regressions too, including extension crashes and package-update bugs. Yet a detailed Reddit critique still described the core as stable while naming TUI, parsing, and provider-reliability problems. The claim is narrower: fewer built-in responsibilities leave fewer coupled systems to preserve in each update.
This trade-off is not new
Other systems learned to separate velocity from stability.
Rolling → extended-stable ↗
Fast channels maximise learning. Stable channels protect routines. Mixing those promises makes every update a wager.
Control plane → failure domain
Central coordination is convenient, but gateway, plugins, state, channels, and schedules can fail together at their seams.
Unix tools → composition
Independent parts shift some assembly to the user and need not share one release. Integration APIs and shared state can still couple their failures.
The fair conclusion: OpenClaw’s integration is the feature. It gets many hard things working behind one Gateway, and recent users also report improved stability. That power creates more compatibility edges and asks more operational effort when they move.
Pi’s public record does not prove superior reliability. Its smaller scope lets cron, messaging and browsers remain separately maintained components, although they can still depend on Pi’s APIs and session behaviour. The architectural preference needs testing across the whole setup. Read Pi’s design philosophy ↗
03 / Research
Maintenance, trust and human agency
Why OpenClaw struggled.
Why Pi works for me.
The research explains some of OpenClaw’s difficulties—and gives reasons it could earn my trust again. My preference starts somewhere simpler: Pi has kept working, without an idle AI heartbeat, and my own extensions fit the jobs I actually want done.
My experience, not a benchmark
First, it keeps working.
Then, it asks less of my trust.
-
Updates have not become repair projects.
In my use, Pi updates have kept my workflows working. Not having to fix the assistant is a substantial benefit on its own. I do not need a grand theory to value software that continues doing its job.
-
No tokens spent on an idle heartbeat.
The base Pi setup has no periodic AI heartbeat. When no task is running and no request or configured trigger arrives, there is no model work to pay for. I add scheduled tasks when I want them, rather than paying for the assistant to keep checking in.
-
I want to know what starts a run.
A request I send, or an automation I deliberately enable, is easier to reason about than an unexplained “magic” feature. Unexpected activity makes me nervous—especially when the AI’s judgment can vary from run to run. I want useful work, not surprises.
-
My extensions do not need to be products for everyone.
My iCal, Apple Notes and Firecrawl integrations are built around my routines. I like that they contain just what I need, rather than extra workflows to learn or disable. I reuse larger pieces such as TelePi and Livecraft instead of rebuilding everything.
The history I discovered afterwards
I found my alternative.
Then I discovered the shared roots.
Pi was already underneath.
On 31 January 2026, Armin Ronacher described Pi as the agent inside OpenClaw. Mario Zechner’s 8 April announcement is explicit: “OpenClaw is powered by pi.” He describes Peter building OpenClaw on Pi, and OpenClaw’s popularity bringing new attention to Pi itself. The relationship was publicly documented; I simply had not known about it.
OpenClaw made an underlying agent useful through a broader personal-assistant experience. My reading is that messaging and automation made its promise easier to grasp than a coding harness alone. The visible product attracted attention before many users knew its foundations. That integration is real product work, not just a cosmetic wrapper; these sources do not establish who first added Telegram or cron.
A history, not a permanent dependency map. The main-branch runtime documentation checked on 5 September describes an OpenClaw-owned embedded runtime. The early Pi relationship should not be assumed to describe every later release unchanged.
My discovery ran in the other direction.
I became frustrated with OpenClaw’s delivery, found Pi independently, and assembled the messaging, schedules and narrow integrations I wanted. Only afterwards did I discover that OpenClaw had been built on Pi. I had not simply found an unrelated rival: I had found a foundation I could use differently.
This is the “smoke and mirrors” feeling I associate with opaque software—not an accusation of deliberate concealment. A finished product can make its underlying capabilities hard to recognise. Discovering the pieces changed my sense of what I, as the user, was allowed and able to shape.
It reminds me of the educational ideal behind Raspberry Pi: helping people understand, create with and critically evaluate computing, rather than only consume a finished appliance. That is my analogy, not a quotation from its founders; the two Pi projects are unrelated.
The layer that helps me start should not become the limit of what I can change.
What the project documented
Why OpenClaw struggled.
In the 5 May 2026 postmortem, Peter Steinberger called OpenClaw “too founder-driven”: too much release, review, packaging and support work rested with him. Startup and update paths were also doing dependency repair while bundled and external plugins were incompletely separated.
This was trouble during a move towards a smaller core—not simply proof that bundling is bad. The account supports a diagnosis of overloaded stewardship and fragile change boundaries. It does not isolate architecture as the cause of every failure.
The 30 August account of OpenClaw 2.0 likewise says growth outpaced the foundation and release process. It also says the team delayed the unusually large release to test new installs and upgrades. Release size shows the coordination challenge; it is not, by itself, evidence that the release was unreliable.
Why the answer could change
Why it could earn trust again.
The 8 July foundation announcement describes paid staff, donors and corporate engineering support. The 30 July extended-stable announcement adds backported fixes and at least one month of support per line—a step towards LTS, not yet a long-term-support promise. These are credible responses, not proof of recovery.
OpenClaw also permits personal plugins without a core merge. Its vision favours contracts over a queue of feature merges. This is not permissionless Pi versus permission-controlled OpenClaw. The question is how much machinery I must understand and maintain to get my particular jobs done.
Its heartbeat documentation allows recurring heartbeats to be disabled, while event-driven wakes remain a separate consideration. I prefer a base setup without that machinery; I am not claiming every OpenClaw installation must run periodic checks.
A plausible explanation—not a proven cause
Why a smaller setup may be working better for me.
Pi makes fewer built-in product commitments, the operating system supplies scheduling, and I choose the interfaces and integrations I need. That can leave fewer unrelated behaviours to understand when something changes. But a separate repository is not a compatibility guarantee: TelePi, Livecraft and my extensions still depend on interfaces, session behaviour and other maintainers. The whole stack—not Pi’s core alone—must earn the reliability claim.
Less total maintenance, a smaller reach when something fails, and more choice about which maintenance I accept are three different benefits. My experience establishes a personal preference, not all three. A small core is a scope decision. A stable interface is a maintenance commitment. Agents make adaptation easier, but they can also help me accumulate more custom code than I can responsibly maintain.
Who maintains it—and who gets a say?
Neither unrestricted contribution nor a profit motive guarantees reliability. The useful question is who benefits from adding a feature, who maintains it afterwards, and whether that owner has resources and authority to say “not in this layer.” Moving a feature out of core can move work to another maintainer—or to me—without reducing it.
Pi’s contribution gate auto-closes issues and pull requests from new contributors; maintainers review closed issues daily and reopen worthwhile ones. That protects scarce review time, but does not make Pi more democratic or remove my dependence on core fixes. Extensibility helps when my need can be met outside the core; both projects offer that possibility.
The April announcement also placed Pi at Earendil, with an MIT-licensed core and plans for commercial additions under other licences. Pi is not outside commercial incentives either. Evaluate its commitments, funding and exit options, not an imagined opposition between companies and open source.
Concentrated power is not only a risk when people are overloaded. Even a well-funded team can abandon an interface or change priorities. Good stewardship needs clear commitments, a way to raise problems and a practical exit—not merely strict maintainers. The right to fork source code matters, but is not an affordable remedy for everyone.
What Linux, SQLite and Bitcoin actually teach
- Linux: choose the boundary that stays dependable. Its maintainer hierarchy is selective, and its kernel is large and monolithic. The stable userspace interface protects applications, while in-tree drivers can be repaired together when internal interfaces change. Sometimes integration makes maintenance cheaper.
- SQLite: pay for dependable shared work. It is open-source, not open-contribution. Its consortium funds maintenance and support, while developers retain technical direction. Disciplined scope and extensive testing matter more here than unrestricted merge access.
- Bitcoin: distinguish implementation authority from enforceable rules. Core’s repository decisions are not network consensus; publishing a proposal is not adoption. A node can reject invalid blocks, not compel others to accept its preferred rules. For agents, the useful parallel is enforcing important limits independently of the model’s judgment—not assuming decentralisation makes a system safe.
These are different lessons, not proof that Pi has inherited decades of dependability. A maintainable foundation leaves room to build around it, but someone still has to preserve the interfaces, fund the work and test the result.
How to test the preference instead of defending it forever
A proposed comparison, not a result already measured: use the same morning-brief task in both setups. Change its instructions while keeping the schedule and output destination fixed. Record which components need changing, what breaks, and repair time and tokens. Then test an upgrade, disabling the schedule, restoring state and replacing an interface. Check model-call logs rather than assuming silence means nothing ran. Keep the model, permissions and required capabilities comparable.
For my custom pieces, keep documented interfaces, tests, backups and a recovery path. If Pi’s changing interfaces make these expensive to preserve, its advantage shrinks. If OpenClaw preserves my workflows through upgrades, makes automation and costs legible, enforces the limits I need and saves more maintenance than it creates, I would reconsider. Dependable delegation is agency too.
Primary sources checked . Project accounts describe their own failures and intended remedies; current policies can change. My experience is not a controlled reliability or security comparison.
04 / The stack
Small pieces, clear jobs
Four tools.
No mystery layer.
Start with Pi. The other three pieces are optional. Each can be understood, inspected, and replaced without rebuilding everything else.
01Required
π
Pi
The minimal agent harness
Pi talks to your chosen model, reads and edits files, runs tools, and saves every session locally so you can return later.
- Resume the latest conversation with
pi -c - Browse all previous sessions with
pi -r - Choose a subscription login or your own API key
02Optional
⌁
Pi Livecraft
The browser workbench
A local web interface for Pi. Its session analysis shows token use and cost over time, and lets you jump from a chart point to the matching turn.
- Live sessions, usage, cost, and tool activity
- Multiple workspaces and parallel conversations
- A UI you can ask Pi to change for you
03Optional
⌚
System cron
The scheduler you already have
On macOS and Linux, cron runs a named Pi task at exactly the times you choose. No agent heartbeat is needed between jobs.
- Every run becomes a visible Pi session
- The schedule lives in one inspectable text file
- Use TelePi’s prompt inbox if it must appear in Telegram
04Optional
↗
TelePi
The messenger bridge
Continue a real Pi session from Telegram using text, voice, or screenshots, then hand the same conversation back to your terminal.
- Runs locally under your user account
- Rejects Telegram users outside your allowlist
- Accepts scheduled prompts through its watched dropbox
A simpler cost model
Know what makes the meter move.
calls AI
You send Pi or TelePi a request
calls AI
A cron schedule launches Pi—or drops a prompt into TelePi’s inbox
no call
Livecraft displays an already saved session
no call
No task is active and no request or enabled automation starts one
05 / Set up
A calm first ten minutes
Begin with one piece.
These commands are for macOS and Linux. Pi also supports Windows; use the official platform guide, and use Task Scheduler instead of cron.
Before you begin: install Node.js. Pi itself has lighter needs, but the full stack—including Livecraft—currently needs Node.js 24 or newer.
1
About 2 minutes
Install Pi
Open Terminal, paste this line, and press Return.
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
The --ignore-scripts flag follows Pi’s safer official npm install path.
2
About 3 minutes
Choose where Pi works
Create a home for your assistant’s notes and projects, then launch it there.
mkdir -p ~/PiWorkspace
cd ~/PiWorkspace
pi
This becomes Pi’s working folder. Pi still runs with your user account’s permissions, so use backups and review sensitive actions.
3
About 3 minutes
Connect your model
Inside Pi, type /login. Choose a supported subscription you already have, or enter an API key for your preferred provider.
✓
Success looks like: Pi accepts “Tell me what folder you are working in” and answers without an authentication error.
4
Any time
Leave and come back
Pi saves sessions automatically. These two commands are the habit worth remembering.
pi -c
Continue your latest session
pi -r
Browse and reopen any session
06 / Add what you need
The optional layers.
Get comfortable with Pi first. Then add one interface at a time.
A
For a browser and cost view
Add Livecraft
Fork Livecraft on GitHub if you want your own editable version, then use your fork’s address below. If you only want to try it, clone the original repository.
git clone https://github.com/sebastienservouze/pi-livecraft.git
cd pi-livecraft
npm install
npm run dev
Then open 127.0.0.1:5173. “Local” means the interface runs on your computer.
B
For access from your phone
Add TelePi
Ask Telegram’s @BotFather for a bot token, then run the guided setup. It asks for that token, your numeric Telegram ID, and your workspace.
npm install -g @futurelab-studio/telepi
telepi setup
telepi status
Guided service installation currently targets macOS and Linux. Keep the bot token private and allowlist only your own numeric ID.
C
For a task at a known time
Add one cron job
First run command -v pi to find Pi’s full path. Then run crontab -e
and add a line like this, replacing both example paths with your own. This direct route
creates a Pi session for Pi and Livecraft; it does not send the result to Telegram.
Keep it observable. Give the run a name, use absolute paths, and save its plain-text output to a log.
# Weekdays at 8:00am
0 8 * * 1-5 cd /Users/you/PiWorkspace && /full/path/to/pi --name "morning brief" -p "Read TASKS.md and prepare today's brief. Do not send or publish anything." >> /Users/you/PiWorkspace/cron.log 2>&1
To make a cron job appear in Telegram
Use TelePi’s dropbox
TelePi calls this the External Prompt Inbox. Enable a watched folder once,
then have cron place a .txt prompt inside it instead of launching Pi directly.
1 / Create the inbox
mkdir -p /Users/you/PiWorkspace/telepi-inbox
2 / Add this to ~/.config/telepi/config.env, then restart TelePi
Restart: macOS
TELEPI_PROMPT_INBOX_DIR=/Users/you/PiWorkspace/telepi-inbox
launchctl kickstart -k gui/$UID/com.telepi · Linux systemctl --user restart telepi.service
3 / Make cron drop each prompt safely
# mktemp gives every queued prompt a unique name; TelePi only sees it after the final .txt rename
0 8 * * 1-5 prompt=$(/usr/bin/mktemp /Users/you/PiWorkspace/telepi-inbox/morning-brief.XXXXXX) && /bin/echo 'Read TASKS.md and prepare today’s brief. Do not send or publish anything else.' > "$prompt" && /bin/mv "$prompt" "$prompt.txt"
TelePi processes one .txt file at a time, sends it to the root Telegram chat for
the first allowlisted user, and removes the file after accepting it. If the chat is busy,
the file stays queued for the next check. Each run uses a unique filename, so a later job
cannot replace an earlier queued prompt.
Note A session that is still being written by a cron run may appear incomplete in Livecraft until that run finishes.
macOS + iCloud
Let an Apple Note
An editable brief and a living result
Let an Apple Note
be the job.
A cron entry can launch a small runner script while the actual instructions stay in an Apple Note. Change the note whenever the brief changes—there is no need to rewrite the schedule. The runner reads that note, asks Pi to do the work, then replaces or appends to a second Apple Note.
If the automation Mac uses a different Apple Account, share the output note with the Apple Account on your iPhone. Updates made by the agent account are then collaboration activity, so Notes can notify the iPhone when alerts are enabled.
Apple Note 01
Job instructions
→
You edit the brief in plain language
At your chosen time
Runner script
→
cron reads the note and launches Pi
Named local session
Pi does the work
→
The run still appears in session history
Apple Note 02
Living output
Updated or appended, then synced to iPhone
Set up the human part
- 1
Create an iCloud Notes folder called
Pi Jobs. - 2
Add
Morning Brief — Instructionsand write the complete job in it. - 3
Add
Morning Brief — Output. Choose whether each run should replace its body or append a dated entry. - 4
Share the output note from the agent’s Apple Account to the account used on your iPhone. Do not select Hide Alerts.
For iPhone alerts: allow Notes notifications, accept the shared-note invitation with the intended Apple Account, and make sure Focus is not suppressing Notes. Apple lets each participant manage their own alert preference.
Help me create a safe, macOS-only Apple Notes runner for one scheduled Pi job.
Do not change Apple Notes or install a schedule yet. First inspect the environment, propose the files and commands, and ask for approval.
The workflow I want:
- Read only the plaintext of the exact iCloud note “Morning Brief — Instructions” in the “Pi Jobs” folder.
- Use that text as the prompt for a named Pi one-shot session.
- Write the completed response only to “Morning Brief — Output” in the same folder.
- Let me choose between replacing the previous output and appending a timestamped entry.
- Preserve the note title and safely escape Pi’s output before writing Apple Notes HTML.
Build a small runner under ~/PiWorkspace/automation/. Use /usr/bin/osascript for Notes, the absolute path to Pi, a lock to prevent overlapping runs, a timeout, and a plain-text error log that contains no credentials. Keep the cron entry tiny: it should only call the runner.
Show me how to run the script manually once so macOS can request permission to control Notes. Explain System Settings → Privacy & Security → Automation. If cron cannot receive the required permission, propose a user LaunchAgent instead—do not weaken system security or request broad access as a workaround.
Never enumerate, read, or modify any note other than the two exact names above. Never activate the schedule until the manual test has succeeded and I approve the final cron or LaunchAgent definition.
What the eventual cron line should look like
The timing lives here. The changing job details remain in Apple Notes.
15 8 * * 1-5 /Users/you/PiWorkspace/automation/run-note-job.sh
07 / Migrate
Already using OpenClaw?
Let Pi do the careful
sorting for you.
The prompt below asks Pi to inspect your existing setup, explain what it found, and wait before writing anything. It copies useful instructions and skills, proposes cron replacements, and deliberately leaves secrets, incompatible sessions, and heartbeats alone.
✓ Backup before change
✓ No automatic credential copying
✓ No deletion or OpenClaw shutdown
1Install Piand complete /login
→
2Start in a safe foldernot inside ~/.openclaw
→
3Paste the promptreview before approving
You are helping me migrate from OpenClaw to a smaller, modular Pi setup on this computer.
The target setup is:
- Pi for agent conversations and locally saved sessions
- Pi Livecraft only if I want a browser and per-session cost view
- normal system cron (macOS/Linux) or Task Scheduler (Windows) only for jobs I explicitly approve
- TelePi only if I want Telegram access, using its External Prompt Inbox/dropbox for scheduled jobs that should appear there
- no AI heartbeat and no recreated background model polling
Work in two phases. PHASE 1 MUST BE READ-ONLY.
PHASE 1 — AUDIT AND PLAN
1. Confirm the operating system, my current working folder, and that the `pi` command works.
2. Find OpenClaw's actual config and state locations safely. Respect OPENCLAW_CONFIG_PATH and OPENCLAW_STATE_DIR if set. Otherwise inspect the normal ~/.openclaw location. If the OpenClaw CLI exists, you may use read-only commands to locate its config.
3. Determine each configured OpenClaw agent workspace. The usual default is ~/.openclaw/workspace, but do not assume it.
4. Inventory, without changing anything:
- AGENTS.md, SOUL.md, IDENTITY.md, USER.md and MEMORY.md
- dated memory files and other user-authored Markdown
- skills containing SKILL.md, and any custom prompts or scripts
- scheduled jobs, cron definitions and HEARTBEAT.md
- channel integrations that I may want to replace
- existing ~/.pi/agent files that must be preserved or merged
5. Never print, copy, or expose API keys, bot tokens, OAuth files, credential stores, or secret values. Report only that a credential category exists.
6. Treat OpenClaw session databases/JSONL and Pi sessions as incompatible. Do not try to place OpenClaw sessions in Pi's session directory.
7. Present a plain-language migration table with: item found, proposed destination, action (copy / merge / archive / skip), risk, and whether I must decide.
8. Propose a new workspace path (default ~/PiWorkspace) and a timestamped backup path. Explain exactly what you want to create or edit.
9. STOP and ask for my approval before making any change.
PHASE 2 — ONLY AFTER I APPROVE THE PLAN
10. Make a timestamped backup of every source file that will be transformed and every existing destination file that will be changed. Never delete or move the originals.
11. Create the approved Pi workspace. Preserve useful OpenClaw profile and memory Markdown in a clearly named reference/ archive inside it.
12. Build or carefully merge an AGENTS.md for Pi. Distil durable instructions from AGENTS.md, SOUL.md, IDENTITY.md and USER.md; remove OpenClaw-specific tool claims; add short pointers to archived memory instead of loading everything into every prompt. Show me the proposed merged text before saving it.
13. Copy only reviewed, compatible skills into the project-local .pi/skills/ directory. Skills and extensions can execute or instruct powerful actions, so summarize each one and ask before enabling it. Do not copy generated caches or dependencies.
14. Convert useful recurring prompts into project-local .pi/prompts/*.md where appropriate. Keep names simple and document what each command does.
15. Do not recreate HEARTBEAT.md or any recurring heartbeat. Extract any genuinely useful tasks from it into a disabled list of possible scheduled jobs.
16. For every OpenClaw scheduled job, first ask where its instructions should live and where its result should appear. For Pi/Livecraft, propose an explicit direct Pi runner and cron/Task Scheduler entry with absolute paths, a named session, minimal permissions, and a log file. For Telegram, do not launch a separate Pi session directly: propose TelePi's External Prompt Inbox/dropbox, configure TELEPI_PROMPT_INBOX_DIR, and have the scheduler atomically place a .txt prompt there. Explain that TelePi sends inbox prompts to the root chat for the first allowlisted user. On macOS, if I explicitly choose Apple Notes, propose a tightly scoped runner that reads one exact instructions note and updates or appends one exact output note; run it manually for Automation permission before proposing cron or a user LaunchAgent. Do not install or activate any schedule until I approve that job individually.
17. Do not migrate provider credentials. Help me use Pi's /login flow or set a new API key myself. Do not migrate Telegram bot tokens; if I choose TelePi, use its official guided setup and ask me to enter the secret directly.
18. Keep old OpenClaw conversations as a read-only archive. If I select important conversations, summarize them into clearly labelled Markdown notes with source references; never claim they are native Pi sessions.
19. Verify the result without making a paid model call unnecessarily: show the created tree, check files and commands, and give me the exact commands for `pi`, `pi -c`, and `pi -r`.
20. Finish with four lists: migrated, transformed, deliberately skipped, and still awaiting my decision. Also list every mechanism in the new setup that can trigger a model call.
Safety rules:
- Preserve and merge; never overwrite blindly.
- Do not uninstall, disable, stop, or reconfigure OpenClaw during this migration.
- Do not activate cron, Task Scheduler, TelePi, Livecraft services, packages, skills, or extensions without separate, explicit approval.
- Pause if paths are ambiguous, files conflict, or a command would need administrator privileges.
- Use the current official documentation for any install command whose package name or requirements may have changed.
!
Important boundary: Pi can preserve and summarise old OpenClaw conversations,
but they are not native Pi sessions and should not be copied into ~/.pi/agent/sessions.
Keep the original archive until you are satisfied with the new setup.
08 / What changes
A different mental model.
This setup trades an integrated control plane for parts you can see and replace.
ConcernBundled setupThis setup
Agent loopPart of the platformPi, used directly
Saved workPlatform-managed historyLocal Pi sessions, resumable from CLI
Background workJobs plus configurable heartbeat machineryExplicitly enabled automations
BrowserBuilt-in control interfaceOptional Livecraft, running locally
MessagingIntegrated channelsOptional TelePi for Telegram
Trade-offOne product to configureMore assembly, but clearer boundaries
09 / Questions
Plain answers
Before you switch.
Do I need all four tools?+
No. Pi is the only required piece. Add Livecraft for a browser, cron for scheduled tasks, and TelePi for Telegram. Leaving a piece out is part of the design.
Does this make AI usage free?+
No. Your chosen model or subscription determines the price. The benefit is legibility: model calls begin when you ask Pi something, message TelePi, or launch a scheduled Pi task—not from a heartbeat in this design.
Can I move my old conversations?+
Keep them as a read-only archive. The two systems do not share a native session format. You can ask Pi to summarise selected conversations into Markdown notes, but that is a reference, not a resumed session.
Is Pi sandboxed?+
No, not by default. Pi and its extensions run with your user account’s permissions. A working folder or a prompt does not confine them, and there is no default per-command approval gate. For sensitive work, restrict credentials and operating-system permissions or use a suitably configured sandbox. Keep backups and review third-party code.
Can I see a cron session while it runs?+
Usually, but Livecraft may briefly show only part of a session while cron is still generating it. Wait for the run to finish, then reopen or refresh the session.
How does a cron job appear in Telegram?+
It must use TelePi’s External Prompt Inbox—the dropbox described above. Cron writes a completed .txt prompt into the watched folder; TelePi picks it up, runs it in the root Telegram chat for the first allowlisted user, and removes the file after accepting it. A normal direct pi -p cron job remains visible in Pi and Livecraft but does not announce itself in Telegram.
Can Apple Notes hold the job and its results?+
Yes, on macOS. A narrowly scoped runner can read one named instructions note, launch a named Pi session, and replace or append one named output note. Share the output note from the automation Mac’s Apple Account with the account on your iPhone to make updates collaboration activity. Notes notifications and per-note alerts must remain enabled; Focus settings can still suppress them.
When should I uninstall OpenClaw?+
Not during migration. First verify your Pi instructions, important files, chosen schedules, and messaging flow. Keep a backup, then follow OpenClaw’s current official removal instructions separately.
The whole idea