Repository navigation
Expand file tree
/
Copy pathindex.html
More file actions
1483 lines (1410 loc) · 91.1 KB
/
Copy pathindex.html
File metadata and controls
1483 lines (1410 loc) · 91.1 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta
name="description"
content="A calm, modular alternative to OpenClaw using Pi, Pi Livecraft, system cron, and TelePi. Includes a safe, agent-led migration guide."
/>
<meta name="theme-color" content="#f3f0e8" />
<meta property="og:title" content="The Small Agent Stack" />
<meta
property="og:description"
content="Keep the useful parts. Remove the always-on ones. A modular Pi setup with a safe OpenClaw migration path."
/>
<title>The Small Agent Stack — a modular OpenClaw alternative</title>
<link rel="icon" href="favicon.svg" type="image/svg+xml" />
<script>document.documentElement.classList.add("js");</script>
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
href="https://fonts.googleapis.com/css2?family=DM+Mono:wght@300;400;500&family=Manrope:wght@400;500;600;700&family=Newsreader:opsz,wght@6..72,400;6..72,500&display=swap"
rel="stylesheet"
/>
<link rel="stylesheet" href="styles.css" />
<script src="script.js" defer></script>
</head>
<body>
<a class="skip-link" href="#main">Skip to the guide</a>
<header class="site-header">
<a class="brand" href="#top" aria-label="The Small Agent Stack, home">
<span class="brand-mark" aria-hidden="true">
<span></span><span></span><span></span>
</span>
<span>small agent stack</span>
</a>
<nav class="desktop-nav" aria-label="Main navigation">
<a href="#philosophy">Philosophy</a>
<a href="#evidence">Evidence</a>
<a href="#research">Research</a>
<a href="#stack">The stack</a>
<a href="#start">Set up</a>
<a href="#migrate">Migrate</a>
<a href="#questions">Questions</a>
</nav>
<a class="header-cta" href="#start">Start small <span aria-hidden="true">↘</span></a>
<button class="menu-button" type="button" aria-expanded="false" aria-controls="mobile-nav">
<span class="sr-only">Open menu</span>
<span></span><span></span>
</button>
<nav class="mobile-nav" id="mobile-nav" aria-label="Mobile navigation" hidden>
<a href="#philosophy">Philosophy</a>
<a href="#evidence">Evidence</a>
<a href="#research">Research</a>
<a href="#stack">The stack</a>
<a href="#start">Set up</a>
<a href="#migrate">Migrate</a>
<a href="#questions">Questions</a>
</nav>
</header>
<main id="main">
<section class="hero" id="top">
<div class="hero-copy">
<p class="eyebrow reveal">A modular alternative to OpenClaw</p>
<h1 class="reveal">One agent.<br /><em>Only when you call it.</em></h1>
<p class="hero-intro reveal">
Keep the sessions, browser view, schedules, and Telegram access. Lose the bundled machinery
and the AI heartbeat you never asked to pay for.
</p>
<div class="hero-actions reveal">
<a class="button button-primary" href="#start">Build this setup <span>↓</span></a>
<a class="button button-quiet" href="#migrate">Let Pi migrate me <span>→</span></a>
</div>
<p class="hero-note reveal"><span></span> No background model calls in the base setup</p>
</div>
<div class="hero-visual reveal" aria-label="A diagram of four independent tools connected to Pi, with Apple Notes, Apple Calendar, and Telegram on an outer interaction ring">
<div class="orbit orbit-interactions"></div>
<div class="orbit orbit-outer"></div>
<div class="orbit orbit-inner"></div>
<div class="core-node">
<span class="node-kicker">core</span>
<strong>π</strong>
<small>Pi agent</small>
</div>
<div class="satellite satellite-web">
<span class="satellite-icon">⌁</span>
<span><strong>Web</strong><small>Livecraft</small></span>
</div>
<div class="satellite satellite-cron">
<span class="satellite-icon">⌚</span>
<span><strong>Scheduled<br />Tasks</strong><small>cron</small></span>
</div>
<div class="satellite satellite-chat">
<span class="satellite-icon">↗</span>
<span><strong>Chat</strong><small>TelePi</small></span>
</div>
<div class="satellite satellite-sessions">
<span class="satellite-icon">≋</span>
<span><strong>History</strong><small>saved locally</small></span>
</div>
<div class="interaction interaction-notes">
<span class="interaction-icon">✎</span>
<strong>Apple Notes</strong>
</div>
<div class="interaction interaction-calendar">
<span class="interaction-icon interaction-icon-calendar">31</span>
<strong>Apple Calendar</strong>
</div>
<div class="interaction interaction-telegram">
<span class="interaction-icon">↗</span>
<strong>Telegram</strong>
</div>
<div class="visual-label label-one">optional interactions</div>
<div class="visual-label label-two">remove what you don’t need</div>
</div>
</section>
<section class="story section-pad">
<div class="section-index">00 / Why</div>
<div class="story-grid">
<h2>Using agents to build<br />our own agency.</h2>
<div class="story-copy">
<p>
OpenClaw offered to take responsibility for the machinery of a personal assistant. In my
setup, I ended up responsible for that machinery anyway.
</p>
<p>
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.
</p>
<p>
Other people build useful components. Agents help me investigate, select, adapt and test
them. My own improvements can become starting points for someone else.
</p>
<p>
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.
</p>
<p>
Only afterwards did I learn that OpenClaw had been built on Pi.
<a href="#research-history">Discovering those shared roots</a> changed how I saw the choice:
not just which assistant to use, but which layers I actually needed.
</p>
</div>
<blockquote>
“Pi won for me when building my own agency became easier than maintaining someone else’s abstraction.”
</blockquote>
</div>
</section>
<section class="philosophy section-pad" id="philosophy">
<div class="section-heading philosophy-heading">
<div>
<div class="section-index">01 / Philosophy</div>
<p class="eyebrow">The design argument</p>
<h2>Who gets to decide<br /><em>how it changes?</em></h2>
</div>
<p class="section-summary">
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.
</p>
</div>
<div class="philosophy-body">
<div class="philosophy-copy">
<p>
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.
</p>
<p>
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.
</p>
<p>
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 <strong>less compulsory coordination per personal change</strong>.
</p>
<a class="argument-jump" href="#steelman">Read the strongest case on both sides <span aria-hidden="true">↓</span></a>
</div>
<div class="principle-list">
<article class="principle">
<span>01</span>
<div>
<h3>Make responsibility come with control</h3>
<p>
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.
</p>
</div>
</article>
<article class="principle">
<span>02</span>
<div>
<h3>Keep personal choices local</h3>
<p>
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.
</p>
</div>
</article>
<article class="principle">
<span>03</span>
<div>
<h3>Let useful experiments accumulate</h3>
<p>
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.
</p>
</div>
</article>
</div>
</div>
<aside class="experience-note">
<span>One user’s evidence</span>
<p>
In my setup, OpenClaw upgrades broke parts of the workflow; after a fresh install I struggled
to deactivate jobs and incurred heartbeat costs I did not need. Pi updates have been remarkably
reliable for me. That explains my preference; it is not a controlled benchmark or proof that
architecture alone caused the difference.
</p>
</aside>
<p class="architecture-note">
<strong>Compare real designs, not caricatures.</strong> OpenClaw is also open source, self-hostable
and extensible. Its <a href="https://github.com/openclaw/openclaw/blob/main/VISION.md" target="_blank" rel="noreferrer">current vision favours a lean core and community plugins ↗</a>.
The distinction is the scope of its <a href="https://docs.openclaw.ai/start/why-openclaw" target="_blank" rel="noreferrer">shared Gateway’s authority ↗</a>,
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.
</p>
<div class="argument-context">
<article>
<p class="eyebrow">Why this works for me now</p>
<h3>Established pieces.<br />A personal fit.</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</article>
<article>
<p class="eyebrow">The 90s parallel—and its limits</p>
<h3>Broad compatibility.<br />Or carefully chosen coherence.</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</article>
</div>
<section class="steelman" id="steelman" aria-labelledby="steelman-heading">
<div class="argument-heading">
<p class="eyebrow">Challenge the thesis</p>
<h3 id="steelman-heading">The strongest case.<br />And the strongest objection.</h3>
<p>A preference becomes more useful when it explains what could make the other approach win.</p>
</div>
<div class="steelman-grid">
<details class="steelman-card">
<summary>
<span class="steelman-kicker">For the thesis</span>
<strong>Local decisions,<br />shared foundations.</strong>
<span class="steelman-toggle" aria-hidden="true"></span>
</summary>
<ol>
<li><strong>Control should match responsibility.</strong> 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.</li>
<li><strong>Personal experiments need not become universal features.</strong> 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.</li>
<li><strong>Changes can remain more local.</strong> 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.</li>
<li><strong>Effort can leave a capability I chose.</strong> 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.</li>
<li><strong>The ecosystem can compound.</strong> 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.</li>
</ol>
</details>
<details class="steelman-card steelman-counter">
<summary>
<span class="steelman-kicker">Against the thesis</span>
<strong>Delegation is agency,<br />too.</strong>
<span class="steelman-toggle" aria-hidden="true"></span>
</summary>
<ol>
<li><strong>Freedom from maintenance matters.</strong> 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.</li>
<li><strong>Pi’s complexity partly lives elsewhere.</strong> 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.</li>
<li><strong>Ownership is not a security certificate.</strong> 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.</li>
<li><strong>Timing and fit can explain the win.</strong> 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.</li>
<li><strong>The same coding-cost advantage is available to both.</strong> 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.</li>
</ol>
</details>
</div>
</section>
<aside class="agency-outlook">
<p class="eyebrow">Not engineers or products</p>
<h3>A simple experience should not require surrendering control.</h3>
<p>
Most people will still want a finished product. The Unix philosophy is a way to build software,
not an obligation to give everyone a terminal. A curated, local-first application or a paid
managed service could offer a polished interface over replaceable components. Choosing a
platform does not inherently mean giving up personal data or becoming the product; that depends
on its business model, permissions, retention and exit options.
</p>
<p>
For me, Pi’s promise is agency that helps build agency: assistance not only with the task, but
with researching, designing and testing the tools through which I act. The test is whether I
can inspect, limit, change and leave the system—not how much autonomy it advertises.
</p>
</aside>
<div class="prompt-card philosophy-prompt">
<div class="prompt-toolbar">
<div>
<span class="prompt-light"></span>
<span class="prompt-label">CHALLENGE THIS THESIS</span>
</div>
<button class="copy-button prompt-copy" type="button" data-copy-target="philosophy-prompt">Copy prompt</button>
</div>
<pre id="philosophy-prompt"><code>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.</code></pre>
<div class="prompt-footer">
<span>Paste this into your favourite AI. Ask it to disagree before you decide.</span>
</div>
</div>
</section>
<section class="evidence section-pad" id="evidence">
<div class="section-heading evidence-heading">
<div>
<div class="section-index">02 / Evidence</div>
<p class="eyebrow">What the public record shows</p>
<h2>Upkeep became part of the job.</h2>
</div>
<p class="section-summary">
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.
</p>
</div>
<div class="evidence-table" role="table" aria-label="Public GitHub activity for OpenClaw and Pi over 90 days">
<div class="evidence-row evidence-header" role="row">
<span role="columnheader">GitHub · 7 Jun–4 Sep 2026</span>
<span role="columnheader">OpenClaw</span>
<span role="columnheader">Pi</span>
</div>
<div class="evidence-row" role="row">
<strong role="rowheader">Repository audience at capture</strong>
<span class="evidence-value" role="cell"><b>388,931</b> stars</span>
<span class="evidence-value" role="cell"><b>102,007</b> stars</span>
</div>
<div class="evidence-row" role="row">
<strong role="rowheader">Non-prerelease releases published</strong>
<span class="evidence-value" role="cell"><b>14</b> releases</span>
<span class="evidence-value" role="cell"><b>32</b> releases</span>
</div>
<div class="evidence-row" role="row">
<strong role="rowheader">All issue reports opened</strong>
<span class="evidence-value" role="cell"><b>12,026</b> reports</span>
<span class="evidence-value" role="cell"><b>2,528</b> reports</span>
</div>
<div class="evidence-row" role="row">
<strong role="rowheader">Reports labelled as bugs</strong>
<span class="evidence-value" role="cell"><b>2,942</b> reports</span>
<span class="evidence-value" role="cell"><b>641</b> reports</span>
</div>
<div class="evidence-row evidence-focus-row" role="row">
<strong role="rowheader">Bugs with “update” or “upgrade” in the title</strong>
<span class="evidence-value" role="cell">
<a href="https://github.com/openclaw/openclaw/issues?q=is%3Aissue%20label%3Abug%20%28update%20OR%20upgrade%29%20in%3Atitle%20created%3A2026-06-07..2026-09-04" target="_blank" rel="noreferrer"><b>122</b> reports ↗</a>
</span>
<span class="evidence-value" role="cell">
<a href="https://github.com/earendil-works/pi/issues?q=is%3Aissue%20label%3Abug%20%28update%20OR%20upgrade%29%20in%3Atitle%20created%3A2026-06-07..2026-09-04" target="_blank" rel="noreferrer"><b>25</b> reports ↗</a>
</span>
</div>
</div>
<p class="evidence-caption">
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.
<a href="https://github.com/openclaw/openclaw/releases" target="_blank" rel="noreferrer">OpenClaw releases ↗</a>
<a href="https://github.com/earendil-works/pi/releases" target="_blank" rel="noreferrer">Pi releases ↗</a>
</p>
<aside class="evidence-reference">
<div>
<p class="eyebrow">History, not a scorecard</p>
<h3>Compare attention.<br />Then compare like ages.</h3>
</div>
<div>
<p>
<a href="https://www.star-history.com/?repos=earendil-works%2Fpi%2Copenclaw%2Fopenclaw&type=date&legend=top-left" target="_blank" rel="noreferrer">Open the Pi / OpenClaw Star History comparison ↗</a>.
That live, third-party chart uses calendar dates and describes public attention—not reliability
or active use. It is not the source of the fixed counts above.
</p>
<p>
<a href="evidence/evidence.html">Explore the age-aligned chart preview →</a> for releases and issue
reports from each repository’s creation, with a second starting-point check, source data and
the limits of comparing a whole platform with a smaller core.
</p>
</div>
</aside>
<div class="signal-grid">
<article class="signal-card">
<span class="signal-source">Reddit · recurring pattern</span>
<h3>An update needed an operations plan.</h3>
<p>
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.
</p>
<div class="signal-links">
<a href="https://www.reddit.com/r/openclaw/comments/1te4rzr/has_any_openclaw_upgrade_ever_not_broken_something/" target="_blank" rel="noreferrer">Upgrade discussion ↗</a>
<a href="https://www.reddit.com/r/openclaw/comments/1uwdr2z/in_yet_another_surprise_202671_broke_my_install/" target="_blank" rel="noreferrer">7.1 reports ↗</a>
</div>
</article>
<article class="signal-card">
<span class="signal-source">X + official docs · failure at the seams</span>
<h3>The control plane multiplies boundaries.</h3>
<p>
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.
</p>
<div class="signal-links">
<a href="https://x.com/i/trending/2051108934908522734?lang=en" target="_blank" rel="noreferrer">X incident summary ↗</a>
<a href="https://openclaw.ai/blog/openclaw-rough-week" target="_blank" rel="noreferrer">Maintainer account ↗</a>
<a href="https://github.com/openclaw/openclaw/blob/main/docs/install/updating.md" target="_blank" rel="noreferrer">Official update guide ↗</a>
</div>
</article>
<article class="signal-card">
<span class="signal-source">Pi · counter-check</span>
<h3>Smaller is not the same as flawless.</h3>
<p>
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.
</p>
<div class="signal-links">
<a href="https://www.reddit.com/r/PiCodingAgent/comments/1usdpqw/my_problems_with_pi/" target="_blank" rel="noreferrer">Critical Pi review ↗</a>
<a href="https://github.com/earendil-works/pi/issues/4908" target="_blank" rel="noreferrer">Pi regression example ↗</a>
</div>
</article>
</div>
<div class="parallel-panel">
<div class="parallel-intro">
<p class="eyebrow">This trade-off is not new</p>
<h3>Other systems learned to separate velocity from stability.</h3>
</div>
<div class="parallel-list">
<div>
<span><a href="https://openclaw.ai/blog/extended-stable-releases-and-maturity-scorecards" target="_blank" rel="noreferrer">Rolling → extended-stable ↗</a></span>
<p>Fast channels maximise learning. Stable channels protect routines. Mixing those promises makes every update a wager.</p>
</div>
<div>
<span>Control plane → failure domain</span>
<p>Central coordination is convenient, but gateway, plugins, state, channels, and schedules can fail together at their seams.</p>
</div>
<div>
<span>Unix tools → composition</span>
<p>Independent parts shift some assembly to the user and need not share one release. Integration APIs and shared state can still couple their failures.</p>
</div>
</div>
</div>
<div class="evidence-conclusion">
<p>
<strong>The fair conclusion:</strong> 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.
</p>
<p>
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.
<a href="https://pi.dev/" target="_blank" rel="noreferrer">Read Pi’s design philosophy ↗</a>
</p>
</div>
</section>
<section class="research section-pad" id="research" aria-labelledby="research-heading">
<div class="section-heading research-heading">
<div>
<div class="section-index">03 / Research</div>
<p class="eyebrow">Maintenance, trust and human agency</p>
<h2 id="research-heading">Why OpenClaw struggled.<br /><em>Why Pi works for me.</em></h2>
</div>
<p class="section-summary">
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.
</p>
</div>
<article class="research-experience" aria-labelledby="research-experience-heading">
<p class="eyebrow">My experience, not a benchmark</p>
<h3 id="research-experience-heading">First, it keeps working.<br />Then, it asks less of my trust.</h3>
<ol class="research-priorities" role="list">
<li>
<h4>Updates have not become repair projects.</h4>
<p>
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.
</p>
</li>
<li>
<h4>No tokens spent on an idle heartbeat.</h4>
<p>
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.
</p>
</li>
<li>
<h4>I want to know what starts a run.</h4>
<p>
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.
</p>
</li>
<li>
<h4>My extensions do not need to be products for everyone.</h4>
<p>
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.
</p>
</li>
</ol>
</article>
<aside class="research-boundary" aria-labelledby="research-boundary-heading">
<p class="eyebrow">A security distinction that matters</p>
<h3 id="research-boundary-heading">Predictable triggers are not predictable judgment.</h3>
<p>
No heartbeat removes one reason for an unsolicited model run; it does not guarantee
obedience during a requested task. Pi can still make mistakes, call tools and consume more
tokens while working. By default, Pi and its extensions run with my account’s permissions,
not inside a sandbox. A narrow extension is not automatically a narrow permission grant.
</p>
<p>
Real limits need scoped credentials, operating-system permissions or a suitably configured
sandbox. A prompt is not an enforced permission boundary, and an AI review is not security
certification. Each added bridge, scheduler or extension needs its own checks for triggers,
permissions and stop controls. No idle model calls also does not mean no network activity:
Pi can perform update checks and telemetry.
<a href="https://github.com/earendil-works/pi/blob/main/packages/coding-agent/README.md" target="_blank" rel="noreferrer">Pi’s documented defaults and package warnings ↗</a>
</p>
</aside>
<article class="research-history" id="research-history" aria-labelledby="research-history-heading">
<p class="eyebrow">The history I discovered afterwards</p>
<h3 id="research-history-heading">I found my alternative.<br />Then I discovered the shared roots.</h3>
<div class="research-history-grid">
<div>
<h4>Pi was already underneath.</h4>
<p>
On <a href="https://lucumr.pocoo.org/2026/1/31/pi/" target="_blank" rel="noreferrer">31 January 2026, Armin Ronacher described Pi as the agent inside OpenClaw</a>.
Mario Zechner’s <a href="https://mariozechner.at/posts/2026-04-08-ive-sold-out/" target="_blank" rel="noreferrer">8 April announcement</a>
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.
</p>
<p>
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.
</p>
<p class="research-version-note">
<strong>A history, not a permanent dependency map.</strong> The
<a href="https://github.com/openclaw/openclaw/blob/0cebe40cf7cb939da0c5722a990eb10522d27d5a/docs/concepts/agent.md" target="_blank" rel="noreferrer">main-branch runtime documentation checked on 5 September</a>
describes an OpenClaw-owned embedded runtime. The early Pi relationship should not be
assumed to describe every later release unchanged.
</p>
</div>
<div>
<h4>My discovery ran in the other direction.</h4>
<p>
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.
</p>
<p>
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.
</p>
<p>
It reminds me of the educational ideal behind
<a href="https://www.raspberrypi.org/about/" target="_blank" rel="noreferrer">Raspberry Pi: helping people understand, create with and critically evaluate computing</a>,
rather than only consume a finished appliance. That is my analogy, not a quotation
from its founders; the two Pi projects are unrelated.
</p>
</div>
</div>
<blockquote>The layer that helps me start should not become the limit of what I can change.</blockquote>
</article>
<div class="research-findings">
<article id="research-openclaw">
<p class="eyebrow">What the project documented</p>
<h3>Why OpenClaw struggled.</h3>
<p>
In the <a href="https://openclaw.ai/blog/openclaw-rough-week" target="_blank" rel="noreferrer">5 May 2026 postmortem</a>,
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.
</p>
<p>
This was trouble during a move <em>towards</em> 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.
</p>
<p>
The <a href="https://openclaw.ai/blog/openclaw-2-accidentally" target="_blank" rel="noreferrer">30 August account of OpenClaw 2.0</a>
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.
</p>
</article>
<article id="research-recovery">
<p class="eyebrow">Why the answer could change</p>
<h3>Why it could earn trust again.</h3>
<p>
The <a href="https://openclaw.ai/blog/introducing-openclaw-foundation/" target="_blank" rel="noreferrer">8 July foundation announcement</a>
describes paid staff, donors and corporate engineering support. The
<a href="https://openclaw.ai/blog/extended-stable-releases-and-maturity-scorecards" target="_blank" rel="noreferrer">30 July extended-stable announcement</a>
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.
</p>
<p>
OpenClaw also permits personal plugins without a core merge. Its
<a href="https://github.com/openclaw/openclaw/blob/main/VISION.md" target="_blank" rel="noreferrer">vision favours contracts over a queue of feature merges</a>.
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.
</p>
<p>
Its <a href="https://docs.openclaw.ai/gateway/heartbeat" target="_blank" rel="noreferrer">heartbeat documentation</a>
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.
</p>
</article>
</div>
<article class="research-hypothesis" aria-labelledby="research-pi-heading">
<p class="eyebrow">A plausible explanation—not a proven cause</p>
<h3 id="research-pi-heading">Why a smaller setup may be working better for me.</h3>
<p>
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.
</p>
<p>
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. <strong>A small core is a scope decision. A stable
interface is a maintenance commitment.</strong> Agents make adaptation easier, but they
can also help me accumulate more custom code than I can responsibly maintain.
</p>
</article>
<div class="research-notes">
<details class="research-detail" id="research-governance">
<summary>Who maintains it—and who gets a say?</summary>
<div class="research-detail-body">
<p>
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.
</p>
<p>
Pi’s <a href="https://github.com/earendil-works/pi/blob/main/CONTRIBUTING.md" target="_blank" rel="noreferrer">contribution gate</a>
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.
</p>
<p>
The <a href="https://mariozechner.at/posts/2026-04-08-ive-sold-out/" target="_blank" rel="noreferrer">April announcement also placed Pi at Earendil</a>,
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.
</p>
<p>
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.
</p>
</div>
</details>
<details class="research-detail" id="research-precedents">
<summary>What Linux, SQLite and Bitcoin actually teach</summary>
<div class="research-detail-body">
<ul class="research-lessons">
<li>
<strong>Linux: choose the boundary that stays dependable.</strong> Its
<a href="https://docs.kernel.org/process/2.Process.html" target="_blank" rel="noreferrer">maintainer hierarchy</a>
is selective, and its kernel is large and monolithic. The
<a href="https://docs.kernel.org/process/stable-api-nonsense.html" target="_blank" rel="noreferrer">stable userspace interface</a>
protects applications, while in-tree drivers can be repaired together when internal
interfaces change. Sometimes integration makes maintenance cheaper.
</li>
<li>
<strong>SQLite: pay for dependable shared work.</strong> It is
<a href="https://sqlite.org/copyright.html" target="_blank" rel="noreferrer">open-source, not open-contribution</a>.
Its <a href="https://sqlite.org/consortium.html" target="_blank" rel="noreferrer">consortium funds maintenance and support</a>,
while developers retain technical direction. Disciplined scope and
<a href="https://sqlite.org/testing.html" target="_blank" rel="noreferrer">extensive testing</a>
matter more here than unrestricted merge access.
</li>
<li>
<strong>Bitcoin: distinguish implementation authority from enforceable rules.</strong>
<a href="https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md" target="_blank" rel="noreferrer">Core’s repository decisions</a>
are not network consensus; <a href="https://github.com/bitcoin/bips" target="_blank" rel="noreferrer">publishing a proposal is not adoption</a>.
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.
</li>
</ul>
<p>
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.
</p>
</div>
</details>
<details class="research-detail" id="research-test">
<summary>How to test the preference instead of defending it forever</summary>
<div class="research-detail-body">
<p>
<strong>A proposed comparison, not a result already measured:</strong> 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.
</p>
<p>
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.
</p>
</div>
</details>
</div>
<aside class="research-takeaway">
<p class="eyebrow">The standard I care about</p>
<h3>Useful work. Chosen dependencies. Fewer surprises.</h3>
<p>
Agency is the practical ability to choose outcomes, constrain delegated authority, and
change or end the arrangement at an acceptable cost. Integration earns its place when it
absorbs work; modularity earns its place when I can change one part without repairing the
rest. Neither deserves trust just because of its label.
</p>
<p>
OpenClaw may yet earn an Apple-like reputation for a coherent, dependable finished
experience; it need not become closed source to do that. For now, I am curious how far
open-source components and bespoke setups can take us as agents get better at helping us
inspect, build and test our tools. Smarter agents could make that assembly more accessible.
They will not automatically remove maintenance or make their own judgment predictable.
</p>
<blockquote>
I did not stop depending on other people’s software. I gained more say over which
dependencies I accepted, what authority they had, and what I could do when they failed.
</blockquote>
</aside>
<p class="research-source-note">
Primary sources checked <time datetime="2026-09-05">5 September 2026</time>. Project accounts
describe their own failures and intended remedies; current policies can change. My experience
is not a controlled reliability or security comparison.
</p>
</section>
<section class="stack section-pad" id="stack">
<div class="section-heading">
<div>
<div class="section-index">04 / The stack</div>
<p class="eyebrow">Small pieces, clear jobs</p>
<h2>Four tools.<br /><em>No mystery layer.</em></h2>
</div>
<p class="section-summary">
Start with Pi. The other three pieces are optional. Each can be understood, inspected, and
replaced without rebuilding everything else.
</p>
</div>
<div class="stack-grid">
<article class="stack-card core-card">
<div class="card-topline"><span>01</span><span class="status-dot">Required</span></div>
<div class="card-symbol">π</div>
<h3>Pi</h3>
<p class="card-role">The minimal agent harness</p>
<p>
Pi talks to your chosen model, reads and edits files, runs tools, and saves every session
locally so you can return later.
</p>
<ul class="feature-list">
<li>Resume the latest conversation with <code>pi -c</code></li>
<li>Browse all previous sessions with <code>pi -r</code></li>
<li>Choose a subscription login or your own API key</li>
</ul>
<a href="https://pi.dev/docs/latest" target="_blank" rel="noreferrer">Pi documentation <span>↗</span></a>
</article>
<article class="stack-card">
<div class="card-topline"><span>02</span><span>Optional</span></div>
<div class="card-symbol symbol-web">⌁</div>
<h3>Pi Livecraft</h3>
<p class="card-role">The browser workbench</p>
<p>
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.
</p>
<ul class="feature-list">
<li>Live sessions, usage, cost, and tool activity</li>
<li>Multiple workspaces and parallel conversations</li>
<li>A UI you can ask Pi to change for you</li>
</ul>
<a href="https://github.com/sebastienservouze/pi-livecraft" target="_blank" rel="noreferrer">View on GitHub <span>↗</span></a>
</article>
<article class="stack-card">
<div class="card-topline"><span>03</span><span>Optional</span></div>
<div class="card-symbol symbol-time">⌚</div>
<h3>System cron</h3>
<p class="card-role">The scheduler you already have</p>
<p>
On macOS and Linux, cron runs a named Pi task at exactly the times you choose. No agent
heartbeat is needed between jobs.
</p>
<ul class="feature-list">
<li>Every run becomes a visible Pi session</li>
<li>The schedule lives in one inspectable text file</li>
<li>Use TelePi’s prompt inbox if it must appear in Telegram</li>
</ul>
<a href="#cron-example">See a safe example <span>↓</span></a>
</article>
<article class="stack-card">
<div class="card-topline"><span>04</span><span>Optional</span></div>
<div class="card-symbol symbol-chat">↗</div>
<h3>TelePi</h3>
<p class="card-role">The messenger bridge</p>
<p>
Continue a real Pi session from Telegram using text, voice, or screenshots, then hand the
same conversation back to your terminal.
</p>
<ul class="feature-list">
<li>Runs locally under your user account</li>
<li>Rejects Telegram users outside your allowlist</li>
<li>Accepts scheduled prompts through its watched dropbox</li>
</ul>
<a href="https://github.com/benedict2310/TelePi" target="_blank" rel="noreferrer">View on GitHub <span>↗</span></a>
</article>
</div>
</section>
<section class="control-strip" aria-label="What starts model calls">
<div class="control-intro">
<p class="eyebrow">A simpler cost model</p>
<h2>Know what makes the meter move.</h2>
</div>
<div class="meter-list">
<div class="meter-row">
<span class="meter-state on">calls AI</span>
<span>You send Pi or TelePi a request</span>
</div>
<div class="meter-row">
<span class="meter-state on">calls AI</span>
<span>A cron schedule launches Pi—or drops a prompt into TelePi’s inbox</span>
</div>
<div class="meter-row">
<span class="meter-state off">no call</span>
<span>Livecraft displays an already saved session</span>
</div>
<div class="meter-row">
<span class="meter-state off">no call</span>
<span>No task is active and no request or enabled automation starts one</span>
</div>
</div>
</section>
<section class="setup section-pad" id="start">
<div class="section-heading setup-heading">
<div>
<div class="section-index">05 / Set up</div>
<p class="eyebrow">A calm first ten minutes</p>
<h2>Begin with one piece.</h2>
</div>
<p class="section-summary">
These commands are for macOS and Linux. Pi also supports Windows; use the official platform
guide, and use Task Scheduler instead of cron.
</p>
</div>
<div class="prereq-note">
<span class="note-icon">i</span>
<p>
<strong>Before you begin:</strong> install <a href="https://nodejs.org/" target="_blank" rel="noreferrer">Node.js</a>.
Pi itself has lighter needs, but the full stack—including Livecraft—currently needs Node.js 24 or newer.
</p>
</div>
<div class="steps">
<article class="step">
<div class="step-number">1</div>
<div class="step-body">
<p class="step-time">About 2 minutes</p>
<h3>Install Pi</h3>
<p>Open Terminal, paste this line, and press Return.</p>
<div class="code-block">
<code>npm install -g --ignore-scripts @earendil-works/pi-coding-agent</code>
<button class="copy-button" type="button" data-copy="npm install -g --ignore-scripts @earendil-works/pi-coding-agent" aria-label="Copy Pi installation command">Copy</button>
</div>
<p class="microcopy">The <code>--ignore-scripts</code> flag follows Pi’s safer official npm install path.</p>