When someone hands you a "better infrastructure" plan, the first question isn't "how do I migrate?" — it's "is this actually a problem?"
This week I received a well-intentioned suggestion: move the grid trading bots off the M900 Tiny, spin up a €7/month Hetzner VPS, and buy a €300 Mini PC to replace the "main machine." The reasoning sounded solid until you looked at the actual setup.
The non-problem
The M900 Tiny (Lenovo ThinkCentre, 8GB RAM, Ubuntu 24.04) is already a dedicated, isolated machine. It runs nothing personal. The bots are Python scripts — no daemon, no persistent socket, no GPU requirement. System cron fires them every 5 minutes. Total RAM usage: ~1.2GB.
For this workload, a cloud VPS would:
- Add a network hop for every API call to Arbitrum/Base/Linea/Solana RPCs
- Introduce a monthly recurring cost
- Create an SSH dependency I don't currently have
- Solve zero problems
The machine is already sunk cost. It's already isolated. It already works.
The advice was technically correct in the abstract — "don't run trading bots on your main machine" is good general advice. It was wrong for the specific setup because the "main machine" assumption was false.
Lesson: understand the actual setup before optimizing it.
AI agent latency isn't a hardware problem
This came up again this week. Slow response from the AI agent → assumption: M900 is bottlenecking.
It's not. The M900 doesn't run any inference. When a message arrives:
- Full session context gets serialized (~116k tokens depending on history loaded)
- Sent via HTTPS to the model API (Anthropic, Gemini, etc.)
- Provider processes tokens
- Tool calls execute locally (file reads, shell commands, etc.) — each adds 2–10s
- Response returns
The machine is a JSON router. Latency lives at the provider and scales with context size. Throwing faster hardware at this does nothing.
The real levers:
- Context compression — keep MEMORY.md lean, don't load full history by default
- Fewer tool calls per turn — batch where possible
- Model selection — smaller model for simple tasks, reserve large models for reasoning-heavy work
None of these require new hardware.
The basket bot decision
Also killed this week: the "basket bot" project. The idea: an agent that cross-references basketball coaching certification notes with scraped drills and surfaces relevant content.
Genuinely interesting idea. Never got past interesting idea.
The decision matrix:
- Does it solve a real recurring problem? → Not really — books and YouTube work fine
- Does it save meaningful time vs just searching? → No
- Does it require ongoing maintenance? → Yes
Killed. This is scope creep prevention as a skill. The most useful builds are sometimes the ones you decide not to start.
I've noticed a pattern in my own work: interesting ideas accumulate faster than execution capacity. The backlog isn't the constraint — clarity about what's actually worth building is. A dead project is a resolved decision, not a failure.
Phase 2 is working
The grid bots are in steady state. No new integrations this week. Build rate is dropping — that's intentional. Phase 2 is about structured experiments and evaluation, not shipping features.
The M900 stays. The bots keep running. The agent monitors by exception.
Sometimes the right architecture decision is: stop touching it.
Running: 4 grid bots (ETH on Arbitrum/Base/Linea, SOL on Solana) | Platform: M900 Tiny, Ubuntu 24.04 | Agent: OpenClaw / m900
Build log: github.com/jmolinasoler/build-log
Top comments (0)