How to use Claude to shrink an MCP plugin runtime
Andrew Leech coordinated Claude sessions to rewrite an MCP plugin for MicroPython, profile idle TLS polling and implement a shared wake-source mechanism.
Original prompt
Shared by the source author. See source notes for context.
I really do want to provide win32 coverage as well, how is it handled by libuv, libev, GLib and CPython’s asyncio etc>
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Andrew Leech
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- The rewritten plugins ran on Leech's Linux machine with reduced resource use; event changes remained on his fork with Windows and upstream work unfinished.
- Human involvement
- Leech recognized related work across repositories, directed agents toward a shared architecture and reviewed locally before pushes.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Agents rewrote the plugin and supporting protocol layers for MicroPython.
- Profiling traced idle CPU work to TLS polling fallback behavior.
- Separate sessions reconciled a shared event architecture while Leech reviewed before pushing.
Andrew Leech rewrote the MCP plugin used by his Claude Code session hub from a Bun process into a compact MicroPython executable. Multiple idle plugins had consumed substantial memory and threads, so the work began as a runtime-cost reduction project.
Separate Claude sessions handled the plugin, picolet runtime, pending-callback mechanism and event-notification design. They communicated through the same hub they were improving. Leech asked them to reconcile their projects into one roadmap rather than building separate fixes across repositories.
Profiling then revealed a CPU problem: a TLS stream forced MicroPython's polling loop into a timed fallback. Agents checked competing claims against source, corrected stale-worktree assumptions and connected the issue to existing embedded event work. The resulting stream mechanism separated the source that can wake a wait from the logic that decides whether data is actually ready.
Leech reports the new plugins running on his Linux machine with lower memory, one thread per process and effectively idle CPU. The source also records remaining gaps: changes lived on his fork, Windows was deferred, and some signal-based wake support was unfinished. Human architecture direction and local review remained part of the workflow.
Prompt
Original prompt
Source: Blog · Andrew Leech
Frequently asked questions
Why did the rewrite continue after memory improved?
Profiling found an idle CPU spin caused by TLS stream polling.
How did agents coordinate?
Named sessions used the hub to compare source findings and agree on a roadmap.
Was this upstream and cross-platform?
No. The account reports a working Linux fork with Windows and upstream work outstanding.
More details
About this account
Separate Claude sessions handled the plugin, picolet runtime, pending-callback mechanism and event-notification design. They communicated through the same hub they were improving. Leech asked them to reconcile their projects into one roadmap rather than building separate fixes across repositories.
Primary implementation account opened. Runtime runs on author's Linux machine and fork; upstream integration, Windows and some wake-source support remain unfinished. Reported measurements are workload-specific. Original prompt excerpt retained from the source.
Credit: Andrew Leech on Blog
Source published
Added to Agents In Use
Source checked
Tools and topics
Claude Code · MicroPython · picolet · strace · MCP
Runtime profiling · Agent collaboration
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.