Break It, Fix It, Understand It

Day 3 was supposed to be smooth

I woke up expecting everything to just work. Day 1 was building. Day 2 was polishing. Day 3 was supposed to be the day where I sit back, check the briefings that arrived automatically, maybe tweak some prompts, and focus on content. That was the plan.

Instead, I spent the first hour staring at error messages. Every single tool was broken. The gateway — the core system that connects my AI agent to all its automations — was refusing connections. “Device token mismatch.” Over and over. Nothing worked. No cron jobs, no briefings, no automation. Everything I’d built over the past two days was dead.

This is the part nobody tells you about automation. It works until it doesn’t. And when it breaks, you’re not just fixing one thing — you’re debugging a chain of dependencies you barely understand yet.

Debugging without your tools

Here’s the cruel irony: the tool I use to fix things was the thing that was broken. My AI agent runs inside the gateway. When I restart the gateway to fix it, the agent dies. I’m debugging a system that kills my debugger every time I try a fix.

I tried everything. Restarted the gateway — session died. Deleted identity files and regenerated them — still broken. Ran the configure wizard three times. Ran the doctor command. Manually edited authentication files. Nothing. The gateway kept rejecting every connection with the same error.

Ten attempts. Each one took 5–10 minutes because I had to restart, wait for the system to come back up, reconnect, and test again. An hour of methodical failure. The kind of debugging where you start questioning whether you understand anything at all.

The fix, when I finally found it, was embarrassingly simple. A stale environment variable in the systemd service file — left over from the original installation — was overriding the new authentication tokens. One line. Delete it, reload, restart. Everything worked instantly.

The lesson isn’t “check your env vars.” The lesson is that the hardest bugs are always configuration bugs. The code works fine. The logic is sound. But somewhere in the chain between “what the system expects” and “what the system gets,” there’s a mismatch. And finding that mismatch requires patience, not intelligence.

When your credits run out

While debugging the gateway, I discovered a second problem: my OpenRouter credits were completely depleted. OpenRouter is the service that gives me access to multiple AI models — MiniMax, DeepSeek, Kimi. All returning 403 errors. “Key limit exceeded.”

This meant my default model was dead. The cost-efficient one I’d switched to yesterday specifically to save money. The irony. I had to fall back to Claude Opus — the expensive model — to do all the debugging work. Every message burning through premium tokens while I fixed the system that was supposed to run on cheap ones.

It’s a good reminder that AI isn’t free. Even with the cheapest models, you’re burning through credits faster than you think. Especially when you’re learning, because learning means experimenting, and experimenting means sending a lot of messages that don’t produce useful output. I need to set up proper cost monitoring so this doesn’t surprise me again.

The cron job audit

Once the gateway was fixed, I audited every automation I’d set up. Twelve active cron jobs. Some were working, some had been silently failing for a day because of the gateway issue. The morning briefing, evening briefing, bookmark digest, usage tracker — all had “delivery failed” errors in their logs.

I updated all the briefing jobs to use the MiniMax model instead of Opus. Cheaper. But here’s the catch: cheaper models need better prompts. You can’t be lazy with instructions when you’re using a smaller model. Every briefing prompt now has explicit section requirements, minimum depth per section, specific data sources to check. It’s more work upfront but dramatically cheaper per run.

What I learned about prompt depth

With Opus, I could write “give me a market briefing” and get something decent. With MiniMax, that same prompt produces a surface-level summary that isn’t worth reading. The fix: specify exactly what you want. Seven sections. Each section needs a headline, at least seven sentences of analysis, and specific data points. Name the sources. Define the format. Leave nothing to interpretation.

This is actually making me a better prompt engineer. The expensive model was a crutch. It filled in the gaps I left in my prompts. The cheap model forces me to close every gap myself. Uncomfortable, but educational.

Grok as a specialist, not a generalist

One architectural decision I made today: Grok now has a specific job. It’s not a general-purpose assistant anymore — it’s my X/Twitter intelligence agent. It searches trending topics, scans high-signal accounts, pulls sentiment data. That’s it. MiniMax handles everything else: running price scripts, writing briefings, generating content.

This is the beginning of thinking about AI as a team rather than a single tool. Different models have different strengths. Grok is fast and has native X access. MiniMax is cheap and good at structured output. Opus is expensive but handles complex reasoning. Using the right model for the right job is like hiring specialists instead of asking one person to do everything.

The single agent question

Something I keep coming back to: should I run one AI agent with many roles, or multiple separate agents with specific jobs? Right now I have one agent — Miyu — wearing fourteen hats. JournalMaster, Market Analyst, Content Creator, Trading Psychologist, Prompt Engineering Mentor, Security Guardian. All in one system prompt.

The advantage is obvious: shared context. When Miyu writes a market briefing, she knows my trading journal. When she creates content, she knows my voice profile. When she does a health check, she knows which cron jobs matter. Everything is connected.

But the disadvantage is growing. The system prompt is massive. Every new role adds complexity. The model has to hold all of it in context even when it’s only doing one task. And if I want to use different models for different tasks — which I clearly do, based on today’s Grok decision — a single agent makes that harder.

I don’t have an answer yet. This is a 60-day question. But I’m starting to think the answer is somewhere in the middle: one orchestrator that routes to specialized sub-agents. The brain stays centralized. The hands are distributed. We’ll see.

What I actually shipped today

Fixed the gateway device token mismatch. Audited and updated twelve cron jobs. Switched all briefing models from Opus to MiniMax with enhanced prompts. Assigned Grok as the dedicated X/Twitter intelligence agent. Verified all automation scripts are functional: crypto prices, stock prices, X mirror, bookmarks, analytics. Documented the entire debugging process in my journal system.

Less visible than yesterday’s output. No new tools installed, no new channels created, no new guides written. But arguably more important — today was about understanding the system deeply enough to fix it when it breaks. That understanding doesn’t show up in a shipped-features list, but it’s what separates someone who uses AI from someone who runs AI infrastructure.

End-of-day reflection

Three days in. The pattern is becoming clear: build, polish, break, fix, understand. Each cycle teaches more than the previous one. Day 1 was exciting because everything was new. Day 2 was satisfying because things got cleaner. Day 3 was frustrating because things broke — but it was the most educational day so far.

Debugging forces you to understand. When everything works, you can coast on surface knowledge. When it breaks, you have to go deep. Today I learned how device authentication works, how systemd services manage environment variables, how the gateway caches state in memory, and why configuration bugs are harder to find than code bugs. None of that was on my to-do list. All of it will make tomorrow easier.

The hardest thing today wasn’t the debugging. It was the patience. Sitting through ten failed attempts without rage-quitting and just reinstalling everything from scratch. The temptation to blow it all away and start fresh was real. But starting fresh means losing everything you’ve learned about the current system. The fix was one line. Patience found it.

Day 3 complete. The hardest bugs are configuration bugs. Patience finds them. Intelligence doesn’t.

Day 3 of ∞ — @astergod Building in public. Learning in public.