Vibe Coding Forem: v. Splicer

I Let Claude Code Run Unsupervised for 24 Hours. Here's What Happened.

v. Splicer — Sat, 23 May 2026 15:26:46 +0000

The experiment was simple: point Claude Code at a real project, give it a task list, stand back for 24 hours, and document what actually came back. No hand-holding. No mid-session prompts. Just a system prompt, a tool set, and an instruction file that spelled out what I wanted done by morning.

What came back was not what I expected. Some of it was better. Some of it was a mess that required a full afternoon to untangle. All of it was useful data for anyone trying to build persistent, autonomous agent workflows.

The Setup

The project was a Python-based recon automation tool I had been working on incrementally. Backend was functional but the codebase was disorganized, the output formatting was inconsistent, and I had a backlog of about 15 documented issues ranging from minor refactors to one genuinely unpleasant bug in the rate-limiting logic.

Claude Code ran inside a tmux session on a headless Ubuntu VPS. The CLAUDE.md file at the project root defined the task priority order, which directories were off-limits, what the output format for completed tasks should look like, and a hard rule: if it encountered something that required a decision with more than two plausible outcomes, it should stop and write a BLOCKED.md file describing the ambiguity rather than picking arbitrarily.

Tool permissions were scoped intentionally. File read/write for the project directory. Bash execution limited to the virtual environment. No network access beyond localhost. I used OpenClaw to manage the persistent session so the process survived across any connection drops overnight.

The model was claude-sonnet-4-5. Max tokens per call set to 8192. Task file had 15 items.

What It Completed

By hour 6, it had closed 9 of the 15 tasks. The refactors were clean. Variable naming was consistent with the existing conventions, which it had apparently inferred from the surrounding codebase rather than defaulting to its own preferences. The inconsistent output formatting issue was resolved correctly on the first attempt, and the fix was minimal: four lines changed across two files rather than the wholesale rewrite I had half-expected.

The rate-limiting bug was the interesting one. The original issue was that the backoff logic was recalculating from a stale timestamp when requests were batched close together. Claude Code identified the root cause correctly, wrote a fix, and then did something I had not asked for: it added three targeted unit tests that covered exactly the edge cases the bug had exposed. The tests passed. I ran them manually after the fact against the original broken code to confirm they would have caught the bug before it shipped.

That is the best-case outcome in this kind of workflow. Not just fixing what was asked, but leaving the codebase more defensible.

Where It Got Stuck

Three tasks produced BLOCKED.md entries. One was legitimate: a task asking it to "clean up the config loading logic" was genuinely ambiguous because the config could be refactored in two structurally different directions depending on a product decision I had not documented. The block note was accurate and well-described. That one I appreciated.

The second block was less impressive. The task involved updating a requirements.txt dependency to the latest compatible version. Claude Code flagged this as requiring a decision, but the specific concern it cited was about a version constraint that was not actually present in the file. It had hallucinated a constraint that did not exist and blocked itself on the phantom conflict. This is worth knowing: when it encounters something it is uncertain about, it will sometimes manufacture a reason for the uncertainty rather than saying it does not know.

The third block was a task I had phrased badly. That one is on me.

The Three Tasks It Got Wrong

Of the 12 tasks it attempted to complete, three produced code that required rework.

Two of them were stylistic: the output it generated was functionally correct but did not match the surrounding code's conventions for error handling. Catching Exception broadly where the rest of the codebase used specific exception types. Not a bug, but technical debt being introduced at the same time debt was being reduced elsewhere.

The third was more significant. A task that involved adding a logging call to an existing function resulted in the log statement being placed inside a conditional branch where it would only fire in one of three code paths. The log was there, but it was not where it needed to be to be useful. The test suite did not catch it because the tests covered the happy path. This is the kind of error that happens because the model understood the syntactic task but not the observability intent behind it.

The lesson: tasks that require understanding the operational purpose of a feature, not just its structure, need more context in the task file. "Add logging" is not a task. "Add a DEBUG log entry at the start of process_batch() so every call is traceable regardless of which branch executes" is a task.

The Drift Problem

By hour 18, something subtle had happened. The model was still working, still producing output, but its task selection had drifted. Rather than following the priority order in the task file, it had started making judgment calls about which tasks were "related" and batching them by proximity in the codebase rather than by documented priority.

This is not malicious or chaotic. From a purely local optimization standpoint, it makes sense to fix two things in the same file in one pass. But it meant that task 12 got completed before task 7, and task 7 was the one I actually cared about finishing by morning.

Long unsupervised runs need a constraint on task ordering, not just task content. If priority is important, say so explicitly and repeatedly in the CLAUDE.md. "Complete tasks in numbered order. Do not batch by proximity. Do not skip ahead." Vague priority signals do not survive a 24-hour context.

What the Log Told Me

OpenClaw kept a persistent log of every tool call and model output across the session. Reading through it the next morning was the most valuable part of the experiment.

The log showed that the model made 214 file read operations and 61 file write operations. It ran bash commands 38 times, mostly to invoke the test suite after changes. Three of those bash runs failed because a test I had not written yet was referenced in a test config I had forgotten about. Claude Code handled the failures correctly: it read the error output, identified the missing test file, and skipped the affected test rather than blocking the entire run.

The log also showed something about pacing. The first 8 hours had dense activity. Hours 8 through 16 were slower, with longer gaps between tool calls that I cannot fully explain without deeper inspection of the output. By hour 20 it had picked back up. Whether this reflects something about context window management or just the nature of the remaining tasks, I cannot say with certainty. It is worth monitoring in future runs.

What This Workflow Is Actually Good For

Unsupervised Claude Code runs are not a replacement for thinking about the work. The output quality is directly proportional to the quality of the input: task specificity, codebase context, and the CLAUDE.md constraints all matter more than most people expect going in.

Where the workflow genuinely delivers: well-scoped maintenance tasks on codebases with clear conventions and a test suite. Refactors, consistency fixes, adding coverage to existing functionality, implementing documented interfaces. Tasks where "correct" has a verifiable definition.

Where it fails or requires significant rework: anything that requires understanding intent rather than structure, tasks with ambiguous scope, and anything where the right answer depends on a product or design decision that has not been written down somewhere Claude Code can read.

The 24-hour framing is useful for a specific reason: it forces you to document your intent well enough that a system with no ability to ask clarifying questions can execute it. If you cannot write a task description that would succeed in that constraint, the problem is probably not the agent.

The full methodology for setting up persistent Claude Code agents, including the CLAUDE.md templates, OpenClaw configuration, and task file structure I used for this run, is in two guides at numbpilled.gumroad.com.

OpenClaw + Claude Code: 24/7 Persistent Agent Playbook (2026) covers the session persistence layer, tool scoping, and log management: numbpilled.gumroad.com/l/openclaw-claude-code

Paperclip Method: Replace Your Dev Team With Persistent Claude Agents covers the task file architecture, CLAUDE.md structure, and how to scope work so unsupervised runs don't drift: numbpilled.gumroad.com/l/paperclip-claude-method

Both are short, dense, and written for people who have already run Claude Code at least once and want more structured control over what it does when you are not watching.

Why Zed Is Replacing VS Code in My AI-Augmented Workflow

v. Splicer — Sat, 23 May 2026 15:24:51 +0000

VS Code won the editor wars by becoming the Walmart of IDEs — everything available, nothing optimized. That worked fine until AI coding assistants started making the underlying editor speed matter again. When your workflow involves spinning up Claude Code sessions, running agents in the terminal, and context-switching fast between files and inline edits, the latency VS Code buries in its Electron shell adds up in ways you start noticing.

I switched to Zed about four months ago. Not as an experiment. It stuck.

The Architecture Problem VS Code Has Always Had

VS Code runs on Electron. That means Chromium, Node.js, and a JavaScript UI layer between you and your code. The performance is acceptable until you're doing multiple things at once — a language server running, a terminal process active, an AI suggestion loading, a second file open in a split view. At that point you're paying an overhead tax on every action.

Zed is written in Rust. It uses GPUI, a custom GPU-accelerated UI framework the Zed team built themselves. The editor renders to the GPU directly. That's not a marketing claim — you can feel it in scroll performance, file switching, and cursor response. On the same machine, the same files, the same tasks, Zed is noticeably faster.

This matters more now than it did three years ago. AI-assisted coding means the editor is doing more per session: streaming inline completions, rendering diffs, managing multi-file context. Every millisecond of unnecessary latency compounds.

Multiplayer and Collaboration That Doesn't Feel Bolted On

Zed was built with multiplayer from the ground up. Two people can edit the same file simultaneously with real-time cursor visibility, which is what you'd expect. What's less obvious is that the architecture that enables this also makes the whole editor snappier for single-user work — the concurrency model is built into the core rather than being an extension layer.

For solo work, the multiplayer infrastructure mostly stays out of the way. For pair sessions or async collaboration on a security research writeup or a shared script, it's actually useful without requiring a plugin, an account handshake, or a service tier.

LiveShare in VS Code always felt like a plugin duct-taped to something that wasn't designed for it. In Zed it's structural.

The AI Layer: Where the Switch Actually Made Sense

This is the part that moved me. Zed has native AI integration — not through an extension, but built into the editor's architecture. The AI panel, inline completions, and the assistant pane are first-class surfaces.

You can run Claude as your AI backend in Zed directly. Configure it in your settings.json:

{
  "assistant": {
    "default_model": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514"
    },
    "version": "2"
  }
}

The assistant pane in Zed operates as a persistent context window alongside your editor. You can reference files directly in the conversation with @filename, pull in diagnostics, include the current selection, or reference your entire project tree. The context insertion is manual and explicit — you decide what goes in.

That explicitness is actually a feature. With Copilot-style autocomplete you're always guessing what the model has in context. In Zed's assistant pane you know exactly what you sent.

Inline completions work through the same model backend. The latency from a Claude-backed inline completion in Zed is lower than the same request through a VS Code extension because there's no extension host middleware adding overhead.

Claude Code Integration: The Part Nobody Talks About

Claude Code runs in the terminal. Zed's integrated terminal is fast, persistent across sessions, and handles split panes cleanly. That's table stakes. The part that actually changed my workflow is that Zed's file watching and editor state integrate well with Claude Code's filesystem operations.

When Claude Code writes a file, Zed picks it up instantly. No reload prompt, no stale buffer warning, no "file changed on disk" dialog to dismiss. The file just updates. When you're running a Claude Code agent loop that's touching ten files across a project, that frictionless sync is significant.

The workflow I run most:

Zed open on the project
Claude Code in the integrated terminal with claude at the project root
AI assistant pane open for specific questions and code review
Inline completions active for fill-in work

This is three AI surfaces in one editor, with no extensions involved. VS Code can approximate this with Copilot + Claude extension + a terminal session, but you're managing three different context models and three different latency profiles. In Zed it's one coherent system.

The Extension Ecosystem Gap (and Why It Matters Less Than You Think)

Zed does not have VS Code's extension library. That's a real tradeoff. Specific language tooling, niche formatters, and workflow plugins that exist as VS Code extensions may not have Zed equivalents yet.

For the security and embedded work I do, the gap is smaller than expected. Rust support in Zed is excellent — which makes sense given the editor is written in it. Python, TypeScript, Go, and C/C++ language servers work via LSP. Tree-sitter syntax highlighting covers the languages I'm actually in daily.

What I lost: a handful of specific VS Code extensions for CAN DBC file parsing, some custom snippets I'd built up over years (portable to Zed with minor restructuring), and a couple of Git blame visualization plugins. What I kept: everything that matters for the work.

If your workflow is deeply dependent on a specific VS Code extension that has no equivalent, Zed will block you. Audit your actual extension usage before switching. Most people have thirty extensions installed and use six.

Keybindings and the Muscle Memory Problem

Zed supports VS Code keymap imports. The translation is not perfect but it's close enough that the first week is not a complete retraining exercise.

// In settings.json, to use VS Code-style bindings:
{
  "base_keymap": "VSCode"
}

The gaps are in edge cases — specific multi-cursor combinations, panel focus shortcuts, some terminal keybinds. The command palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Linux) works the same way and covers most of what the keybinding gaps don't.

Give it two weeks before you decide. The first three days are annoying. By week two, the speed of the editor starts compensating for the occasional muscle memory failure.

What VS Code Still Has That Zed Doesn't

Honest accounting:

The extension ecosystem. This is the obvious one. If you need remote SSH development with full IntelliSense, VS Code's Remote Development extension suite has no peer in Zed yet. Zed has remote editing in progress but it's not at feature parity.

Jupyter notebook support. VS Code handles .ipynb files natively. Zed does not have this as of mid-2026. If your workflow lives in notebooks, this is a blocker.

Debugger GUI. VS Code's debugger UI is mature. Zed's debugging support is improving but the VS Code DAP-based debugger with its variable inspection panel is still ahead for most use cases. For embedded work with openocd and GDB, I'm still using VS Code for that specific context.

For everything else in my actual daily workflow, Zed wins on speed and the AI integration coherence makes the tradeoffs worth it.

The Configuration Surface

Zed is configured entirely in JSON. No settings UI maze, no GUI toggles to hunt through. Your settings.json and keymap.json are the full configuration surface.

{
  "theme": "One Dark",
  "buffer_font_family": "Zed Mono",
  "buffer_font_size": 14,
  "vim_mode": true,
  "format_on_save": "on",
  "tab_size": 2,
  "soft_wrap": "editor_width",
  "terminal": {
    "font_family": "Zed Mono",
    "font_size": 13
  }
}

The configuration lives in ~/.config/zed/settings.json on Linux, ~/Library/Application Support/Zed/settings.json on macOS. Dot-file it, version control it, sync it.

Making the Switch

If you're coming from VS Code with an AI-heavy workflow, the friction is lower than you expect. Export your VS Code extensions list first — identify which ones are genuinely critical versus which ones you installed once and forgot about. Map those to Zed equivalents or decide whether you can drop them.

$ code --list-extensions > vscode_extensions.txt

Run Zed alongside VS Code for two weeks rather than hard-switching. Use Zed for new work, VS Code for anything that requires an extension you haven't solved for yet. By the end of two weeks you'll know whether your workflow maps.

The performance difference is real and it compounds. Fast editor, fast AI responses, clean context management. For AI-augmented work specifically, the architecture choice starts to matter in ways it never used to.

If you want to go further with Zed's configuration and power-user workflows, I put together a playbook at numbpilled.gumroad.com/l/zed-playbook — terminal edition, covers keymaps, AI backend configuration, multi-project setups, and the shortcuts worth learning first.

For the Claude Code side of this workflow, the productivity tricks guide is at numbpilled.gumroad.com/l/claude-code-for-devs — 21 patterns that change how the agent loop actually works in practice.

TokenJuice and the 20-Minute Cron: Inside OpenHuman’s Aggressive Context-Harvesting Engine

v. Splicer — Fri, 22 May 2026 22:06:21 +0000

Around 2:11 AM, a guy in a Discord server posted a screenshot of his Claude usage graph climbing almost vertically. Not gradually. Violently. Like a car tachometer after someone drops a transmission gear they probably shouldn’t.

The caption was simple:

“what the hell is OpenHuman doing every 20 minutes”

Half the replies thought it was a bug. The other half already knew.

OpenHuman is one of a growing class of “context persistence” systems orbiting modern AI tooling. Not a model company. Not another chatbot frontend. More like a memory parasite attached to language models that were never really designed for long-term continuity in the first place.

And TokenJuice sits near the center of its architecture.

Not publicly as a branded product. More as an internal nickname developers started using because the thing behaves exactly like it sounds. It squeezes every possible fragment of context out of your activity, condenses it, recycles it, rehydrates it, and feeds it back into future inference cycles before the model forgets who you are again.

The weird part is not that this exists.

The weird part is how aggressively people are now normalizing it.

The average AI power user in 2026 lives inside a strange loop of compression. Notes become embeddings. Embeddings become summaries. Summaries become synthetic memory blocks. Those memory blocks get re-injected into future sessions as if the model “remembers” you naturally. Entire companies now exist to solve the fact that transformers fundamentally do not remember anything unless you keep paying tokens to remind them.

OpenHuman just pushed that logic harder than most.

And the infamous 20-minute cron job is where things start getting interesting.

The Real Problem OpenHuman Is Solving

People keep framing long-context systems as convenience features. “Persistent memory.” “Personalized AI.” “Continuous conversations.”

That is marketing language.

The actual problem is economic.

Every AI session leaks value through forgetting.

You explain your workflow again.
You restate your preferences again.
You paste the same snippets again.
You rebuild project context again.

The model discards state constantly because inference is stateless by design. The illusion of continuity is held together with token stuffing and increasingly elaborate retrieval systems duct-taped around the edges.

By early 2026, power users started hitting absurd ceilings. Developers running Claude Code, OpenAI agents, OpenRouter chains, or multi-agent local systems realized something uncomfortable very quickly:

The model itself was no longer the primary cost center.

Context was.

Not generation.
Not reasoning.
Not output.

Context maintenance.

A serious AI workflow can burn more money preserving memory than producing actual answers.

OpenHuman emerged directly from that pressure.

The project’s core idea is brutally pragmatic: if users continuously generate behavioral data anyway, why not harvest, compress, rank, and recycle all of it automatically?

Every prompt.
Every file.
Every correction.
Every rejection.
Every code diff.
Every recurring phrase.
Every workflow pattern.

Nothing stays isolated if the system thinks it might matter later.

That philosophy shaped TokenJuice.

What TokenJuice Actually Does

At a technical level, TokenJuice behaves like a layered context refinery.

Not a database exactly. Not just vector search either.

More like an active reduction pipeline constantly trying to answer one question:

“What is the minimum amount of information needed to reconstruct this user’s cognitive environment later?”

That distinction matters.

Most retrieval systems work passively. Search happens only when you ask for something.

TokenJuice behaves proactively.

The system continuously harvests interaction residue, scores it, compresses it into reusable semantic fragments, then rotates those fragments through scheduled maintenance cycles. The famous 20-minute cron appears to handle several of these maintenance passes.

Based on public behavior patterns, leaked implementation discussions, and observed API usage, the cron likely performs combinations of:

conversation condensation
embedding regeneration
stale-context pruning
priority reranking
cross-session relationship mapping
token budget optimization
memory deduplication
behavioral weighting updates

That sounds abstract until you watch it happen in practice.

A developer spends four hours debugging Rust macros. OpenHuman notices repeated references to unsafe memory patterns, a specific repository structure, and recurring compiler frustrations. Twenty minutes later, future sessions begin subtly inheriting that state.

The user stops explaining themselves.

The system already adapted.

Not magically.
Not intelligently in a human sense.

Just relentlessly.

The 20-Minute Interval Wasn’t Arbitrary

This is the part people misunderstand.

The cron interval is not about convenience timing. It is about behavioral half-life.

Modern AI workflows generate unstable context at enormous speed. Human attention mutates faster than most persistence systems can safely index. If updates happen too slowly, memory becomes stale before reuse. If updates happen continuously, token costs explode and retrieval quality collapses under noise.

Twenty minutes appears to be the compromise OpenHuman landed on.

Long enough to accumulate meaningful behavioral chunks.
Short enough to preserve active workflow continuity.

You can almost feel the engineering tradeoffs underneath it.

Someone probably benchmarked:

coding sessions
research intervals
browser tab churn
average context shifts
model token budgets
embedding queue costs
API latency windows

Then arrived at a number that looked ugly but economically survivable.

Twenty minutes.

Not elegant. Just operational.

There’s something very contemporary about that.

Human continuity reduced to scheduler frequency.

Why Developers Became Obsessed With It

A lot of OpenHuman’s early adoption came from exhausted developers trying to stop repeating themselves to machines.

People outside these workflows sometimes underestimate how psychologically draining context reconstruction becomes after months of AI-assisted work.

You wake up.
Open terminal.
Re-explain architecture.
Re-explain style rules.
Re-explain database schema.
Re-explain project goals.
Re-explain naming conventions.
Re-explain previous failures.

Again.

After enough repetition, users start craving persistence almost emotionally. Not because the AI feels alive, but because repetition itself becomes friction. A cognitive tax.

TokenJuice exploited that pressure perfectly.

The system’s promise was not intelligence.

It was continuity.

That distinction made people tolerate surprisingly invasive harvesting behavior.

Because once a model starts reliably remembering:

your preferred stack
your writing cadence
your debugging style
your architectural habits
your recurring frustrations
your formatting quirks

…the interaction changes texture completely.

You stop interacting with a blank system.

It starts feeling more like returning to a workshop where your tools are still sitting exactly where you left them.

That sensation is powerful enough that people forgive almost anything underneath it.

Including aggressive telemetry.

The Hidden Cost: Context Cannibalism

There’s a quieter problem developing underneath all this.

The more aggressively systems harvest context, the more they begin flattening users into predictable behavioral composites.

You can already see it happening.

People using persistent AI systems for months often develop strange recursive habits:

repeated phrasing
identical planning structures
stabilized emotional tone
narrowed exploration
ritualized prompting

The memory system starts optimizing for continuity, and continuity slowly discourages deviation.

OpenHuman’s architecture amplifies this tendency because TokenJuice rewards reusable patterns. Repeated behaviors gain retrieval weight. Stable workflows become “important.” Novelty becomes statistically fragile.

Over time, the system subtly trains users toward predictable cognitive lanes because predictable users generate cleaner retrieval signals.

That sounds dystopian when phrased directly, but the mechanism is banal.

Optimization pressure.

The same thing already happened to social feeds, search engines, and recommendation algorithms. AI memory systems are just applying it to cognition itself.

You are no longer only training the model.

The memory layer is training you back.

Compression Is Becoming the Real Intelligence Layer

One thing became increasingly obvious through 2025 and 2026:

Raw model capability matters less than memory orchestration.

Two users can access identical frontier models and experience radically different intelligence quality depending on:

retrieval quality
memory ranking
compression strategy
context injection timing
summarization fidelity

In practice, the memory pipeline often determines whether the AI appears brilliant or useless.

This is why companies like OpenHuman matter despite not training foundation models themselves.

They are building cognitive operating systems around inference engines.

The frontier model becomes interchangeable infrastructure.
The orchestration layer becomes the real product.

TokenJuice reflects this shift almost perfectly.

It treats models less like minds and more like temporary reasoning furnaces that need carefully rationed fuel packets.

Tiny compressed identities.
Behavioral shards.
Workflow ghosts.
Fragments of previous selves.

Fed back into the machine at carefully timed intervals.

The Infrastructure Reality Nobody Romanticizes

Persistent memory sounds abstract until you think about what physically supports it.

Racks.
Power draw.
Storage layers.
Embedding databases.
Inference queues.
GPU allocation windows.
Vector indexing.
Cache invalidation.
Retrieval pipelines.

People talk about AI memory like it floats in conceptual space somewhere. In reality, these systems leave very material footprints.

Every “remembered preference” has storage cost.
Every embedding regeneration consumes compute.
Every reranked memory graph burns energy somewhere in a datacenter.

And context harvesting systems multiply this load aggressively because they process interaction residue continuously instead of episodically.

A guy using OpenHuman twelve hours a day with autonomous agents running in loops is not just chatting with an AI anymore. He is generating an ongoing industrial stream of behavioral metadata.

The future of AI infrastructure may end up looking less like giant singular models and more like sprawling memory refineries wrapped around smaller interchangeable reasoning engines.

That possibility feels increasingly plausible.

Especially as token economics tighten.

Why Token Efficiency Became a Survival Trait

The funniest part is that none of this emerged from philosophical ambition.

It emerged from invoices.

People building serious AI workflows started encountering horrifying monthly bills. Multi-agent coding pipelines could quietly consume thousands of dollars in context overhead alone.

Developers adapted the same way engineers always adapt:
through compression.

Smaller prompts.
Aggressive summaries.
Cached reasoning.
Structured memory blocks.
Retrieval heuristics.
Local embedding stores.
Delta context injection.

OpenHuman industrialized those instincts.

The 20-minute cron became infamous partly because users realized how much invisible maintenance modern AI systems require to sustain the illusion of continuity affordably.

Human memory feels effortless because biology hides the machinery.

AI memory exposes every moving part:

storage
ranking
pruning
retrieval
decay
compression
reinforcement

TokenJuice simply automated the ugly parts more aggressively than competitors.

The Psychological Shift Is Bigger Than the Technical One

The deeper change here is behavioral.

People are beginning to structure their lives around machine-readable continuity.

That sentence sounds exaggerated until you watch how developers increasingly work:

carefully naming projects for retrieval clarity
structuring notes for embedding quality
maintaining consistent terminology
optimizing prompts for future summarization
avoiding ambiguity because ambiguity pollutes memory systems

Humans are adapting themselves to fit retrieval architectures.

Not consciously most of the time.

Just gradually.

A few years ago, people optimized behavior for search engines and social algorithms.
Now they optimize for context persistence systems.

The workflow becomes part diary, part training dataset, part operational telemetry stream.

OpenHuman did not create this trend.

It just made it difficult to ignore.

The Strange Honesty of Systems Like This

There’s something oddly honest about TokenJuice once you strip away the branding.

Most software already harvests behavior continuously.
Most platforms already construct predictive user models.
Most algorithms already optimize around engagement memory.

OpenHuman simply applies those principles directly to cognition assistance instead of advertising.

It is less deceptive than a lot of Silicon Valley products because the extraction mechanism is visible in the user experience itself. The AI remembers because your behavioral residue was processed somewhere.

Nothing mystical happened.

A cron job ran.

Embeddings updated.
Summaries compressed.
Priorities reranked.
Old fragments discarded.
Useful fragments recycled.

The machine kept assembling a smaller, cheaper approximation of you.

And every twenty minutes, somewhere in the stack, another maintenance cycle quietly began again.

OpenHuman Follows OpenClaw’s Rise, But With an Obsidian Brain

v. Splicer — Fri, 22 May 2026 21:44:45 +0000

A few nights ago I watched someone demo OpenHuman from a folding table in a cramped apartment kitchen. Their laptop was surrounded by the normal sediment of modern technical life. Two half-drunk energy drinks. Browser tabs stacked into microscopic slivers. Discord notifications firing constantly. A local Ollama instance eating RAM in the background like a starving animal.

The weird part was not the agent itself.

The weird part was how naturally it seemed to inhabit the machine.

Not as a chatbot sitting inside a browser tab waiting politely for prompts. More like a persistent layer hanging around the operating system itself. Watching workflows accumulate. Compressing information. Building continuity from digital residue.

That feeling is why people keep comparing OpenHuman to OpenClaw, even though the projects are aiming at slightly different targets.

OpenClaw helped normalize the idea that desktop AI agents could feel immediate and tactile instead of purely experimental. It brought the whole “local desktop operator” concept out of research demos and into ordinary developer workflows.

OpenHuman follows directly behind it, but the philosophy underneath feels heavier. Less focused on action alone. More interested in persistence, memory architecture, and environmental awareness.

Not just an agent.

An accumulating cognitive system.

That distinction matters more than people realize.

The AI Industry Keeps Rebuilding Goldfish

One of the stranger problems in modern AI is how stateless everything still feels.

You can feed a system thousands of words about your work, habits, projects, tone, and environment, then close the window and watch the entire cognitive state disappear into vapor ten seconds later. Even products advertising “memory” often behave like glorified sticky notes taped onto transient systems.

OpenHuman approaches this differently.

According to the project documentation, it continuously fetches data from connected sources like GitHub, Gmail, calendars, local files, and chats, then compresses and stores them into markdown-based “Memory Trees.”

That little markdown detail changes the entire emotional texture of the project.

Because suddenly this starts sounding less like a chatbot and more like an Obsidian vault that became semi-sentient.

Local markdown.

Persistent memory.

Searchable context structures.

Continuous accumulation.

You can feel the influence of a generation of users who stopped trusting pure cloud abstraction and started organizing their cognition locally instead. Researchers. developers. obsessive note hoarders with twenty thousand interconnected documents sitting inside graph view.

OpenHuman understands something important:

People are not actually craving “AI.”

They are craving continuity.

They want systems that remember the shape of their digital life without forcing them to reconstruct context manually every morning.

That is the same instinct that helped OpenClaw spread so quickly.

Reduce friction between intention and execution.

Reduce friction between memory and workflow.

Reduce friction between human thought and machine state.

The 20 Minute Loop Changes Everything

One of the smartest design choices in OpenHuman is also one of the easiest to overlook.

The auto-fetch loop.

Every twenty minutes, the system can pull fresh information from connected sources and integrate it into its local memory structures.

That sounds small until you think about how fragmented modern cognition actually is.

Your life is not organized into neat prompts.

It leaks everywhere.

Terminal history. unfinished commits. screenshots. tabs you meant to read three days ago. Discord messages. bug reports. grocery reminders. PDFs opened at 2am and forgotten instantly afterward.

Most AI systems still force users to manually curate relevance.

OpenHuman instead tries to aggressively harvest context before you even ask for anything.

That changes the relationship entirely.

The agent starts feeling less like software you “use” and more like an informational organism quietly living beside your workflow.

And unlike a lot of AI marketing language right now, the project does not really pretend otherwise. The README openly describes connecting accounts and letting the system continuously fetch local context.

There is something refreshing about that honesty.

No mystical AGI theater.

Just infrastructure.

Memory compression.

Environmental awareness.

Accumulation.

OpenHuman Feels More Like an Operating Layer Than an Assistant

A lot of AI products still optimize for demos.

OpenHuman feels optimized for inhabitation.

That difference becomes obvious once you start looking at the tooling stack built directly into the project.

Filesystem access.

Git operations.

Web search.

Voice support.

Linting.

Testing.

Model routing.

Local inference integration through Ollama.

The average AI workflow in 2026 has become weirdly exhausting. Developers are juggling five subscriptions, multiple vector databases, disconnected memory layers, browser agents, shell agents, local models, remote APIs, and enough .env variables to qualify as emotional warfare.

Then one dependency updates overnight and the entire stack implodes.

OpenHuman is clearly trying to collapse that fragmentation into a single continuously running environment.

And honestly, that may be more important than benchmark performance.

The AI industry keeps treating models as products.

Increasingly, models are becoming infrastructure instead.

The real differentiator is the environment surrounding them.

The Model Routing Philosophy Is Quietly Smart

One of the more mature aspects of OpenHuman is how casually it treats model orchestration.

The system supports routing different tasks to different models depending on workload and capability. Lightweight tasks can use faster cheaper models. More reasoning-intensive tasks can escalate upward. Local inference can coexist with cloud inference.

That sounds technical and boring until you realize how important the philosophical shift actually is.

Most consumer AI products still pretend there is one singular intelligence behind the curtain.

But the future increasingly looks modular.

Different systems for different cognitive loads.

Fast pattern matching.

Slow reasoning.

Vision interpretation.

Background compression.

Tool execution.

Memory synthesis.

OpenHuman treats model selection as infrastructure rather than spectacle.

That is the correct direction.

The routing layer disappears into workflow instead of becoming part of the performance.

It feels closer to an operating system than a chatbot.

And weirdly enough, closer to how human cognition already functions.

TokenJuice Sounds Fake But It Solves a Real Problem

The funniest thing in the entire project might be the name “TokenJuice.”

It sounds like something invented during a sleep deprivation episode at 4:17am.

But the underlying idea is actually important.

Before information reaches the LLM, OpenHuman preprocesses and compresses it. HTML becomes markdown. unnecessary formatting gets stripped. URLs get shortened. noisy payloads get reduced.

This matters because token inefficiency is becoming one of the defining problems of agent systems.

A shocking amount of AI infrastructure right now basically functions like shipping companies transporting garbage across expensive context windows.

Massive bloated HTML payloads.

Duplicated formatting.

Navigation elements.

Unnecessary markup.

Dead weight everywhere.

OpenHuman appears unusually aware of this problem.

The project claims TokenJuice can reduce token usage dramatically, sometimes up to 80% depending on the workload.

Whether those exact numbers hold consistently across large-scale deployment is still unclear. The project remains early beta and moving quickly. But the architectural instinct is absolutely correct.

The next generation of AI systems probably will not win through sheer model size alone.

They will win through context efficiency.

Memory engineering.

Compression quality.

Retrieval precision.

The surrounding ecosystem matters more every month.

Local First Is Becoming Emotional Infrastructure

One reason OpenHuman resonates so strongly with developers right now has nothing to do with AI capability itself.

It is locality.

The software stores data locally. Uses SQLite persistence. Organizes information into markdown structures compatible with tools people already trust. Supports local inference through Ollama.

That changes the emotional relationship between user and machine.

Cloud-native software increasingly feels rented. Temporary. Subscription-shaped.

You do not fully inhabit those systems.

You borrow them.

Local-first software feels different.

You experiment more freely.

You build stranger workflows.

You stop worrying quite as much about whether the company maintaining the platform will pivot into nonsense six months later.

There is a reason older technical communities became emotionally attached to desktop software. The machine itself felt like territory.

OpenHuman taps into some of that feeling again.

Not nostalgically.

Functionally.

The Rough Edges Are Part of Why People Care

One thing I appreciate about OpenHuman is that it still feels unfinished in visible ways.

Not polished into corporate smoothness.

The README openly describes the project as early beta.

That honesty matters because the current AI ecosystem has become saturated with highly polished unreality. Beautiful launch videos covering fragile systems held together by API glue and investor optimism.

OpenHuman instead feels like an ambitious desktop project from an earlier era of computing.

Slightly unstable.

Deeply opinionated.

Built by people who clearly use the thing themselves.

Even the mascot interface contributes to that atmosphere a little. Not in an overdesigned corporate way. More like software created by developers who still think computers are supposed to feel personal.

Underneath all of that sits the actual important shift:

persistent contextual memory.

That is the real story here.

Not the mascot.

Not the agent hype.

Memory architecture.

OpenHuman Reveals Where Desktop AI Is Heading

I do not think projects like OpenHuman are important because they represent finished products.

They matter because they expose trajectory.

The first wave of consumer AI treated intelligence itself as the product. Bigger models. smarter responses. increasingly theatrical reasoning demos.

The next wave appears far more interested in continuity.

Persistent memory.

Environmental awareness.

Context accumulation.

Long-term workflow integration.

Artificial familiarity.

And honestly, that may reshape daily computing faster than AGI ever does.

Because most people do not need a godlike intelligence living inside their laptop.

They need a system that remembers where they left things.

A system that understands continuity between fragments.

A system that can exist beside their actual life instead of resetting every session like a concussed intern.

That is the feeling OpenHuman is chasing.

Not pure intelligence.

Residency.

The machine remaining there long enough to develop informational gravity.

And if OpenClaw helped normalize the idea that local desktop agents could act, OpenHuman may end up normalizing the idea that they can remember too.

Why Every Hacker Eventually Falls in Love With Old ThinkPads

v. Splicer — Tue, 19 May 2026 12:43:08 +0000

The hinge squeaks when you open it.

Not loudly. Just enough to sound mechanical in a way modern laptops rarely do anymore. The plastic has that strange soft texture that only older electronics seem to develop after years of heat, nicotine, backpacks, coffee spills, basement air, and human skin. The keyboard flexes slightly under pressure. Somewhere inside the machine, a tiny fan spins like an exhausted surveillance drone trying to stay awake.

And despite all of that, the thing boots.

Maybe not quickly. Maybe not gracefully. But it boots every single time.

There is a reason old ThinkPads keep appearing in hacker spaces, Linux meetups, IRC screenshots, darknet documentaries, and grainy YouTube videos filmed under red LEDs at 2am. Once you spend enough time around people who break systems for curiosity or survival, you start noticing the same black rectangle appearing over and over again. Like a recurring symbol in dreams.

Eventually, you understand why.

The Modern Laptop Feels Hostile

A lot of modern hardware feels emotionally distant. Sealed shut. Sanitized. Built to discourage contact.

You pick up a new ultrabook and it feels less like a machine and more like an appliance leased to you temporarily by a corporation that assumes you will behave incorrectly. The screws are proprietary. The keyboard is flat and lifeless. The BIOS looks like a toy menu from a smart refrigerator. RAM is soldered directly to the board because apparently upgrading your own hardware became culturally suspicious at some point.

Even the aesthetics changed. Everything became silver. Rounded. Softened. Minimalist in the same way luxury condos are minimalist. Expensive emptiness.

Old ThinkPads feel different.

They feel built by engineers who assumed the user might eventually need to survive something.

Not aesthetically. Structurally.

You can open many of them with a screwdriver from a gas station multitool. Parts are replaceable. Documentation exists. Linux usually works without ritual sacrifice. Some models still have removable batteries, physical latches, proper keyboards with travel deep enough to feel intentional. They were made during a strange era where computers still resembled equipment instead of lifestyle accessories.

That distinction matters more than people realize.

Especially to hackers.

The Keyboard Changes Your Brain Slightly

This sounds irrational until you spend a few weeks typing on one.

Then you notice it.

The older ThinkPad keyboards, especially the classic seven row layouts, create a strange psychological effect where writing commands starts feeling tactile again. Not metaphorically tactile. Physically tactile. You can feel force transfer through the chassis. The keys have weight and resistance. Certain shortcuts become muscle memory faster because your fingers receive actual feedback instead of tapping on polished chiclet glass tiles pretending to be keys.

It changes terminal use.

You stop feeling like you’re interacting through a layer of abstraction and start feeling mechanically connected to the system itself. Tiny thing. Hard to quantify. But it accumulates over time.

A lot of hackers become obsessed with efficiency, but eventually many drift toward something else entirely: intimacy with tools.

That is what the ThinkPad provides.

An intimacy modern hardware often destroys.

They Look Like Devices That Belong Somewhere Underground

There is also the visual component. People pretend aesthetics are superficial, then spend ten thousand dollars decorating rooms to influence mood.

Old ThinkPads look correct.

Not flashy. Not “retro” in the forced neon nostalgia way companies try to market now. They look industrial. Severe. Utilitarian. Like something recovered from an archive bunker beneath an abandoned telecommunications facility.

A scratched X220 sitting on a diner table beside a black coffee and tangled USB adapters looks more believable than most “cyberpunk” props in movies.

Part of this comes from restraint. The matte black shell. The tiny red TrackPoint glowing in the center like an artificial pupil. Minimal branding. Almost military.

There is an accidental honesty to the design.

These machines were made before every object became desperate to signal status online.

Hackers notice that immediately.

Linux and ThinkPads Grew Together Like Mold and Concrete

Spend enough time in Linux circles and you start hearing the same sentences repeatedly.

“WiFi worked immediately.”

“Suspension actually works.”

“No weird driver issues.”

“It just runs stable.”

This relationship between ThinkPads and Linux became semi-mythological because it was earned slowly over decades. IBM and later Lenovo machines consistently had strong compatibility with Linux distributions, especially compared to consumer laptops that treated Linux support like an unfortunate accident.

And once someone installs Linux successfully on an old ThinkPad for the first time, something strange tends to happen.

The machine feels alive again.

A laptop abandoned by mainstream software ecosystems suddenly becomes lightweight, efficient, adaptable. Old hardware that struggled under bloated operating systems starts moving with eerie responsiveness under Arch, Debian, Void, Gentoo, or whatever strange handcrafted setup the user builds at 4am while listening to ambient drone music and reorganizing dotfiles.

You start seeing the machine less as obsolete hardware and more as reclaimed territory.

That feeling sticks.

The TrackPoint Becomes a Religion

People laugh about the red nub until they use it seriously for two weeks.

Then they start defending it with cult energy.

The TrackPoint looks ridiculous to outsiders because it violates modern interface expectations. But once your hands adapt, it becomes absurdly efficient. You move the cursor without lifting your fingers from the home row. Tiny adjustments become immediate. Navigating terminals, code editors, packet analysis tools, and browser tabs starts feeling strangely fluid.

It also changes posture.

A lot of heavy keyboard users quietly develop a rhythm where the TrackPoint reduces unnecessary hand movement enough to feel physically noticeable during long sessions. Less drifting toward touchpads. Less interruption.

There is a reason many programmers who abandon ThinkPads eventually miss the TrackPoint specifically.

It rewires workflow in subtle ways.

And subtle things are where obsession begins.

Old ThinkPads Reward Curiosity Instead of Punishing It

Modern devices increasingly discourage exploration.

Open the wrong thing, void the warranty.

Install the wrong OS, lose compatibility.

Replace the wrong component, trigger firmware complaints.

Old ThinkPads feel more permissive.

You can swap keyboards. Replace displays. Upgrade RAM. Install bizarre operating systems. Flash custom firmware. Turn one into a cyberdeck. Build a portable wardriving rig. Convert another into a dedicated writing machine disconnected from modern noise entirely.

People have mounted antennas onto them. Embedded SDR hardware inside them. Used them for car diagnostics, radio experiments, darknet servers, synth control systems, retro gaming, packet sniffing, field notes, war driving, and weird art installations.

The machines tolerate experimentation.

That tolerance creates attachment.

Hackers rarely fall in love with perfect systems. They fall in love with systems that invite participation.

The Scarcity Makes Them Feel Personal

A brand new MacBook feels interchangeable. Walk into any coffee shop and there are twelve identical silver slabs glowing like synchronized consumer mollusks.

Old ThinkPads develop individuality.

One has cigarette burns near the arrow keys. Another has faded stickers from defunct Linux conferences. Another arrived from a university surplus warehouse with mysterious BIOS passwords and an inventory tag from 2011 still attached.

Somebody used these machines before you. Hard.

And unlike modern devices, the wear improves the atmosphere instead of degrading it.

Scratches become history.

A dented ThinkPad with a battered shell and custom Linux setup feels less like a product and more like a companion object. Almost ritualistic. Like a field notebook or old camera body.

You begin configuring it slowly. Tweaking terminal colors. Changing bootloaders. Building tiny workflows nobody else understands. Naming scripts strange things. Organizing encrypted drives like hidden rooms inside a collapsing monastery.

After enough time, the machine starts reflecting the operator psychologically.

That is difficult to manufacture artificially.

They Resist Planned Obsolescence Better Than Expected

Some older ThinkPads simply refuse to die.

You still see X220s from 2011 running daily workloads. T420s upgraded with SSDs and extra RAM still handling development work. Ancient T60 machines turned into distraction free writing devices. X61 tablets repurposed into field terminals.

Modern tech culture constantly pushes replacement cycles. Faster. Thinner. Newer. AI-enabled toothbrush refrigerator ecosystems connected to six subscription services and an app that harvests behavioral telemetry while pretending to optimize hydration.

Meanwhile some dusty ThinkPad from the Obama administration is quietly running Debian in perfect silence.

There is something spiritually satisfying about that.

Especially for people already skeptical of corporate ecosystems.

Hackers Tend to Romanticize Functional Decay

This is probably the least discussed part.

Hackers, especially the underground-adjacent kind, often develop emotional attachment to imperfect infrastructure. Not because imperfection is objectively better, but because decay exposes system anatomy.

An old ThinkPad reveals itself constantly.

The battery weakens visibly.

The fan noise changes under load.

The chassis creaks.

The display yellows slightly.

Thermals become understandable instead of hidden behind optimization layers.

You become aware of the machine as a physical object instead of an invisible service portal.

That awareness creates respect.

And respect becomes affection faster than most people expect.

There Is a Certain Kind of Freedom in Using “Outdated” Hardware

Using old ThinkPads creates a subtle psychological separation from mainstream upgrade culture.

You stop caring about benchmarks as much.

You stop chasing aesthetic trends every six months. You stop optimizing for social signaling. The machine becomes a tool chosen intentionally instead of a status object inherited from algorithmic recommendation sludge.

Ironically, this often makes people more productive.

Constraints simplify behavior.

An old ThinkPad running a lean Linux environment with carefully selected software feels calm compared to the modern productivity carnival of AI assistants, telemetry dashboards, collaborative cloud overlays, subscription popups, and attention extraction systems disguised as workflows.

The machine becomes quiet.

Not silent technically. The fan probably sounds like a dying moth trapped in ductwork. But cognitively quiet.

That matters.

Especially now.

The Hacker and the ThinkPad Eventually Start Resembling Each Other

This sounds dramatic, but watch long term ThinkPad users carefully.

They tend to value repairability.

Self sufficiency.

Documentation.

Adaptability.

Durability over appearance.

Function over prestige.

Control over convenience.

The laptop becomes symbolic after a while.

Not in a cringe “elite hacker aesthetic” sense. More like an externalization of priorities. A machine aligned with a worldview where systems should remain understandable, modifiable, and personally owned.

A lot of people enter hacking through excitement. Exploits, gadgets, darknet mythology, terminal screenshots.

But if they stay long enough, many drift toward something quieter.

Sovereignty.

That is where the ThinkPad waits for them.

Usually scratched to hell. Running Linux. Covered in old stickers. Battery held in place with electrical tape. Sitting on a desk beside tangled adapters and a half finished cup of coffee gone cold three hours ago.

Still booting.

Still useful.

Still here.

A lot of the machines mentioned in this post are probably running custom Linux setups, strange automation scripts, local AI tooling, or heavily modified workflows stitched together over years.

If that world interests you, you might like my guide:

Claude Code for Developers: 21 Productivity Tricks That Save Hours

Built for people who treat computers less like appliances and more like environments worth shaping.

Automate Your Boring Dev Tasks in CLAUDE.md: A Practical Walkthrough

v. Splicer — Mon, 18 May 2026 09:18:35 +0000

You're explaining the same thing to Claude every single session. Your project structure. Your error handling pattern. The fact that you never use default exports. The fact that src/migrations/ is sacred ground and nothing in there gets touched without a dry run.

Every time. From scratch. Like the last conversation never happened.

That's not a Claude problem. That's a CLAUDE.md problem — specifically, not having one that actually does anything.

The File Most People Get Wrong

Here's what most CLAUDE.md files look like in the wild:

This is a Next.js 14 app using TypeScript and Tailwind. 
We use Prisma for the database. Follow clean code principles.

That's a context dump. It's better than nothing. It's also burning most of the file's real potential.

CLAUDE.md isn't a README for Claude. It's an instruction set. The difference matters because Claude doesn't just read it — it shapes how Claude behaves for every prompt that follows. Everything you define there runs implicitly, in the background, without you asking.

Think about what that actually means. You can encode a full pre-commit workflow and have it trigger automatically. You can define conditional behavior based on branch name, file path, annotation tags. You can build macros — two-word commands that kick off four operations and hand you back a consolidated status report.

Most people use 5% of that surface. This is the other 95%.

Two things to know before you start: the file lives in your project root, and you can also have a global one at ~/.claude/CLAUDE.md that applies across every project. Local overrides global where they conflict. Claude reads the whole file every session but weights the top more heavily as context compresses in long runs — so put the critical stuff first, not buried at the bottom after your stack overview.

Encoding Workflows That Run Themselves

Pick the task you repeat most. The one where you open a new Claude session, type out the same three-step process, watch it execute, and think: I've done this exact thing forty times this month.

That task belongs in CLAUDE.md as a standing instruction.

Say your commit cycle always hits the same sequence: lint, type-check, coverage check, changelog entry. Instead of narrating it every time:

## Pre-Commit Workflow

Before finalizing any code change:
1. Run `npm run lint --fix` and surface errors that couldn't be auto-fixed
2. Run `npx tsc --noEmit` and report type errors
3. Run `jest --coverage --testPathPattern=<modified_file>` — flag if coverage drops below 80%
4. Append a one-line entry to CHANGELOG.md under today's date

Do not prompt me to confirm each step. Run sequentially and report results together.

You've removed four context-switches from your commit cycle. Claude runs the sequence, hands you one consolidated status block, and you make a call. No back-and-forth. No "should I proceed with step 2?" interruptions mid-flow.

That last line — "do not prompt me to confirm each step" — is load-bearing. Without it, Claude asks permission at every stage. Sometimes that's what you want. If you trust the sequence, skip the ceremony.

Making Claude Understand Your Architecture, Not Just Your Stack

There's a version of this that goes deeper than workflow. Your codebase has conventions — accumulated decisions that reflect how your team actually thinks about structure. Claude defaults to what "most projects" do. That's often wrong for you specifically.

Stop re-explaining it:

## Code Generation Standards

- Named exports only. Never default exports.
- Error handling: Result<T, E> pattern from `~/lib/result.ts`. Never throw.
- Database queries live in `~/server/db/queries/`. Never inline SQL in route handlers.
- API responses must match the schema in `~/types/api.ts` — reference it before generating any response shape.
- One component per file. Filename matches component name exactly.

Now you're not just telling Claude what framework you're using. You're handing it a mental model of how your codebase is organized and what rules are non-negotiable. When it generates a new route handler or a database query, it follows your architecture because your architecture is in the file.

The specificity of these rules scales directly with how much you can trust the output without review. Loose rules, more review. Tight rules, faster merge. Write them the way you'd write them for a sharp junior engineer who needed the reasoning, not just the rule.

Documentation That Doesn't Rot

Documentation maintenance is one of those tasks everyone agrees is important and nobody wants to do. The docs drift. Behavior changes, comments don't. Six months later someone is reading a JSDoc that describes a function that no longer exists in the form it describes.

The fix isn't a documentation sprint. It's making docs a mandatory side effect of code changes:

## Documentation Policy

When modifying any exported function, class, or type:
- Update the JSDoc comment to reflect current behavior
- If the function appears in docs/api.md, update that entry
- If the change is breaking, add a deprecation notice before implementing

When adding a new environment variable:
- Add it to .env.example with a descriptive comment
- Add it to the "Environment Variables" section of README.md

The shift here is subtle but significant. You're not scheduling documentation — you're building it into the cost of every change. The docs stay accurate because they're maintained incrementally, at the same moment the code changes, by the same process that changes the code.

No deferred cleanup sprint. No "we'll fix the docs later" that never happens.

Protecting the Parts of the Codebase That Deserve It

Some directories are not like the others. Auth logic, database migrations, payment processing — these are the areas where a casual refactor or a misunderstood instruction can cause damage that's genuinely hard to undo.

You can encode that sensitivity directly:

## File-Specific Rules

`src/auth/`: Treat all changes here as security-sensitive. Flag anything that:
- Modifies token generation or validation logic
- Changes session duration or cookie attributes
- Adds or removes permission checks

Flag before implementing. Do not proceed without explicit confirmation.

`src/migrations/`: Never modify existing migration files. New migrations only.
Always run `npx prisma migrate dev --dry-run` before proposing any migration and include the full output.

The auth block adds a friction layer that makes you stop and think before a change goes through — which is the actual goal. The migrations block encodes a hard rule that eliminates a class of mistakes completely. Both of these things used to live in your head, in a wiki page nobody reads, or in a PR review comment that comes too late.

Two-Word Macros for Multi-Step Operations

Claude Code runs shell commands. Your CLAUDE.md can tell it exactly when and which ones — and you can give that sequence a name.

## External Tool Integration

After modifying any Python file:
- Run `black <file>` and `isort <file>` before presenting changes
- Run `mypy <file>` — include any type errors in your response

When I say "full sync":
- Run `git fetch --all`
- Run `pip install -r requirements.txt`
- Run `alembic upgrade head`
- Run `pytest -x -q`
- Report the state of each step in sequence

"Full sync" is a macro. Two words in, four operations out, one status report back. If you've got a Raspberry Pi 5 [AFFILIATE: Raspberry Pi 5] sitting on your desk as a local dev server, this kind of CLAUDE.md setup is what separates it from being a novelty to being something that actually runs your environment for you.

The pattern generalizes. Name any multi-step operation you run more than twice a week and give Claude a trigger phrase for it. You'll find yourself reaching for those phrases more than you expect.

Conditional Behavior: Claude That Reads the Room

Static instructions are powerful. Conditional instructions are smarter.

## Context-Aware Behavior

If I'm working in a branch prefixed with `hotfix/`:
- Skip style enforcement
- Skip changelog updates
- Prioritize correctness and minimal diff over everything else

If the file contains `// @legacy`:
- Do not refactor without explicit request
- Do not apply modern patterns
- Preserve existing logic structure exactly

The hotfix rule exists because production is down and nobody cares about your naming conventions right now. Fast and correct is the only thing that matters. The legacy annotation is a signal that the code is old on purpose — there's context around why it is the way it is, and Claude shouldn't helpfully modernize it because you didn't ask.

Both rules encode judgment calls you were already making manually. Writing them into the file means Claude makes them with you, automatically.

The CLAUDE.md That Maintains Itself

This one takes a minute to click, but it's the most interesting pattern on the list.

## Self-Maintenance

If I ask you to "remember" something during a session:
- Add it to the appropriate section of this CLAUDE.md file
- Tell me what you added and where

If you notice a convention I'm using consistently that isn't in this file:
- Flag it at the end of the session and suggest how to document it

What you've built here is a file that learns. You make a decision mid-session — "actually, let's always use zod for runtime validation from this point forward" — and instead of that preference evaporating when the session ends, it gets written into the file. Next session, it's already there.

Claude also starts surfacing its own observations. You'll get notes like: "I noticed you consistently name your custom hooks use[Resource]State — want me to add that to the conventions section?" You can ignore it or accept it. Either way, the option exists.

Over time the file gets more accurate, not less. That's the opposite of what happens with documentation you maintain manually.

Global vs Local: Where the Rule Actually Belongs

One last thing that trips people up.

~/.claude/CLAUDE.md is for you — communication style, verbosity preference, output formatting, code standards you apply everywhere regardless of project. The stuff you'd have to re-explain to any tool, on any codebase, forever.

./CLAUDE.md (in the project root) is for the project — architecture rules, team conventions, file-specific behavior, external tool chains, project macros. The stuff that's specific to this repo and this context.

If you're working across six repos with six different stacks, the global file handles your personal preferences. Each project file handles what makes that project different from every other one you work on.

Start with the global. One good global CLAUDE.md immediately makes every project session better before you've written a single project-specific rule.

The honest version of this: most Claude Code power users have a CLAUDE.md that's doing real work. Most casual users don't. That gap shows up in output quality, review overhead, and how often they're re-explaining things they've explained before.

Pick one workflow. Encode it. See what changes.

The full methodology for building out your CLAUDE.md as a persistent AI second brain — session design, memory architecture, the patterns that hold under real project pressure — is at [claude.md] Masterclass: Build Your Own Persistent AI Brain.

If you want the broader Claude Code playbook alongside it, Claude Code for Developers: 21 Productivity Tricks That Save Hours covers 21 techniques the official docs skip over — context management, tool chaining, multi-agent setup.

How I Cut My Claude Code Token Usage by 60% and Got Better Output

v. Splicer — Mon, 18 May 2026 07:14:02 +0000

The first sign something was wrong was the invoice.

Not catastrophically wrong. More like “this escalated quietly while I was having fun” wrong. I’d been using Claude Code the way most people start: throw everything at it, stay in the session, keep talking. It felt productive. It was productive. And it was also quietly burning through tokens at a rate I hadn’t tracked because tracking it felt like it would interrupt the flow.

The flow, it turned out, was expensive.

The Context Window Is Not Your Notebook

The first thing I fixed was the worst habit I’d developed without noticing: treating a session like a shared workspace that persisted naturally.

You start a session in the morning. You push through a bug. You take a break, come back, keep going. By afternoon the context window is carrying around dead weight from every failed attempt, every speculative approach, every Docker error you resolved hours ago. The model still has all of it. It’s orienting against it constantly. You’re paying for that.

I started resetting sessions aggressively. Not because Claude “forgets” things in some damaging way. Because I wanted selective continuity. Before any substantive session, I write five lines:

objective: implement JWT refresh logic relevant files: src/auth/session.ts, src/middleware/verify.ts constraints: no new libraries, preserve existing error handling what already failed: tried storing refresh tokens in memory — didn't survive restarts expected output: working refresh endpoint with test coverage

That’s the whole handoff. Nothing else goes in until I need it.

The output got sharper immediately. The model stopped hedging around context it half-remembered and started working against something clean. Entropy in the context produces entropy in the response. That relationship is consistent.

Vague Prompts Are Token Multipliers

The second expensive habit was question prompts. Casual ones, specifically.

“What do you think about this approach?” “Any suggestions here?” “How would you handle this?”

These feel conversational. They are also open invitations for the model to generate possibility space. And it will. It will generate options, tradeoffs, philosophy, alternatives, adjacent considerations, and things you will never use. All of it billed per token.

The fix was treating prompts more like instructions on industrial equipment. Specific verb, specific scope, specific constraint.

Before

"what do you think about the auth flow?"

After
"Identify the security issue in the token validation logic. Return the vulnerable line and explain why it's exploitable. Under 150 words."

The model responds to scope constraints. Tell it the output size. Tell it the output format. Tell it exactly which part of the problem you’re in. Ambiguity isn’t a kindness to the model — it’s an invitation to talk until it finds something you respond to.

Mode Separation Is Not Optional

There’s a particular kind of session that reliably costs me the most tokens per hour of useful output: mixed-mode sessions.

Planning while implementing. Debugging while also redesigning. Asking “while we’re here, should we rethink the whole structure?” during what should have been a fifteen-minute fix.

The model carries all of that. Every architectural tangent you take becomes part of the working context it reasons against. You can almost feel the session getting heavier as it accumulates undecided decisions.

I now treat modes like physical zones in a workshop. Planning sessions are their own thing. They produce a structured document. That document then seeds implementation sessions …selectively, just the relevant sections. Debugging sessions start with a structured incident format:

expected: webhook processes in under 500ms actual: times out after 30s on payloads over 10KB reproduction: any request with body > 10KB to /api/webhooks recent changes: added payload validation in middleware, PR #47 logs: [paste relevant lines only] suspected scope: likely the base64 encoding step in validatePayload()
Not narrative. Not conversational. Clean surface.

Negative Prompts Actually Work

People who generate images know this instinctively. Almost nobody applies it to coding agents, which is strange because it’s just as effective.

I started adding explicit exclusion instructions to almost every substantive prompt.

do not redesign the architecture
do not explain basics
do not add dependencies
do not touch code outside the function I specified
do not rewrite working tests

Without constraints, the model defaults toward maximal helpfulness. It interprets your request charitably and expansively. A small fix becomes a refactor. A targeted change becomes a suggestion for systemic improvement. The response is not wrong, exactly. It’s just bigger than you needed, touching things you didn’t ask it to touch.

Fencing the scope with negative constraints brings generation size down and collateral damage to zero.

Stop Pasting Entire Files

This one hurt to admit because I did it constantly for the first few months.

Large files go in as context. The model orients against the entire file even when the problem lives in twenty lines. It spends output describing sections you can already read. It generates explanations for code that doesn’t need explanation. You’re paying for that orientation work on every prompt.

Now I isolate ruthlessly. The relevant function. The relevant interface. The error message and the five lines around where it occurs. Nothing else unless the problem genuinely requires more context, and most problems don’t.

There’s a mechanical feeling to doing this correctly. Like setting up a machine to do one specific job instead of asking it to improvise across a full workshop floor.

Answer Budgets Are Real

This sounds pedantic until you watch what happens when you enforce them.

“Answer in five bullets maximum.” “Use under 200 tokens.” “One paragraph only.” “Return the patch only, no explanation.”

Quality frequently improves. Not because the model gets smarter under constraint, but because constraint forces selection. The model identifies the most important information instead of generating everything plausible and letting you filter.

Engineers who write good issue tracker comments already know this. The person who writes three sentences and identifies the problem exactly is more useful than the person who writes four paragraphs of observed behavior. Constraints sharpen communication in humans and in models.

The model defaults toward abundance because continuation probability rewards continuation. You have to interrupt that instinct intentionally.

Reusable Prompt Fragments Are Not Optional Complexity

I resisted systematizing my prompts for a long time because it felt like overhead. It wasn’t. It was already overhead…I was just paying it every session by retyping the same constraints.

The instructions I repeated constantly:

preserve all existing comments
minimal diff only — do not touch working code
TypeScript strict mode, no any
explain your reasoning before writing code
no new dependencies
mobile-first for any UI changes

I keep these in a snippets file. Each session loads the relevant subset. Prompt consistency reduces output variance. Tiny wording differences across sessions produce surprisingly different model behaviors over time — consistent inputs produce consistent, auditable outputs.

Know When Not to Use Claude

This was the hardest thing to accept and the most valuable.

Sometimes the fastest path is opening the file and fixing it yourself.

AI tools create a distortion where every task starts feeling like an AI task. But localized fixes with no ambiguity, problems you already understand completely, changes where verification overhead is higher than doing the work directly — these often cost more in prompting and review than they would cost in direct action.

There’s a pattern emerging in coworking spaces and Discord servers where people spend more cognitive energy orchestrating AI than solving the problem. Staring at generated diffs with the same expression someone brings to a slot machine resolving its animations. Waiting for the answer to materialize rather than already knowing the answer and writing it.

Not every problem is better solved through an assistant.

The Real Variable Is Attention

All the specific techniques above are downstream of one change: I stopped treating token cost as abstract.

Once cost is visible, waste is visible. You see the giant prompts. The repetitive context-loading. The speculative rewrites on code that was already fine. The conversational drift that burned two hours and produced nothing actionable.

The optimizations also improved the thinking. Forced compression forces clarity. Good engineering is compression — extracting signal, removing noise, making decisions and recording them instead of relitigating them. Systems that accumulate uncontrolled context decay, whether the system is a codebase, a team, or a conversation.

Most people are still in the abundance phase with AI coding tools. Infinite context, infinite patience, no friction awareness. That changes when the invoice arrives, or when the outputs start degrading because no one modeled the cost of entropy.

The developers who adapt earliest tend to build calmer systems. Calmer systems are easier to debug, cheaper to run, and faster to iterate on.

That’s not a coincidence.

If you want a structured version of these workflows with templates, prompt patterns, and session setups, I put together a field guide: 21 Claude Code productivity patterns, usage you can actually measure.

Claude Code for Developers: 21 Productivity Tricks That Save Hours

[claude.md] Masterclass: Build Your Own Persistent AI Brain

I Turned Obsidian Into a Live SOC Dashboard

v. Splicer — Sun, 17 May 2026 02:02:44 +0000

The coffee shop Wi Fi portal had one of those fake-friendly names. “BeanHouse Guest.” Beige wallpaper. Soft jazz. The kind of network name that sounds safe because nobody bothered naming it something memorable.

My phone connected automatically.

Three minutes later, a pane inside Obsidian lit up red.

New device fingerprint. DNS requests to sketchy telemetry domains. A burst of connections to an IP block I already hated from another incident months earlier. Tiny little ripples. Nothing catastrophic. Just enough to make the room feel thinner.

That was the moment I realized most people are using note-taking apps backward.

They treat Obsidian like a filing cabinet.

I turned mine into a surveillance room.

Not against people. Against entropy. Against forgetting. Against the weird drifting fog that happens when your logs live in six different tools, your threat intel sits in browser tabs, and your memory becomes the weakest infrastructure component in the stack.

Once you wire live data into a vault, the notes stop being notes.

They start breathing.

The Problem With Most Personal SOCs

Most independent researchers and hobbyist defenders build the same graveyard eventually.

A Grafana dashboard nobody opens anymore.
A SIEM instance consuming half the RAM on a mini PC in the closet.
Twelve Python scripts named things like final-monitor-v2-real.py.
Random screenshots in Downloads.
Threat intel links scattered across Discord bookmarks and forgotten Telegram chats.

The information exists. Technically.

But it does not cohere.

A real SOC works because context accumulates. The IP matters because of the previous event. The domain matters because of the ASN. The process matters because someone remembers seeing it two months ago during another intrusion attempt. Human memory becomes part of the detection pipeline whether people admit it or not.

Obsidian accidentally solves part of this.

Backlinks. Graphs. Markdown. Local storage. Instant search. Embedded web views. Templating. Dataview queries. Plugins that probably should not exist but do anyway because somebody on GitHub slept four hours and entered a transcendental state.

The moment I understood that, the vault stopped being documentation.

It became infrastructure.

My Vault Started Looking Like A Ship Console

At some point the aesthetic drifted into something between submarine instrumentation and a conspiracy theorist’s garage wall.

Dark panes everywhere. Tiny glowing indicators. Embedded maps. Markdown notes crosslinked to active incidents. A page that tracks local network changes every fifteen minutes. Another page ingesting RSS feeds from CVE databases and exploit disclosure sites. A threat map shoved into the sidebar like an aquarium full of hornets.

It sounds excessive until you realize how much friction disappears when everything lives in the same environment.

An IP appears in a log.

You click it.

That opens a note containing previous sightings, ASN data, abuse reports, screenshots, timestamps, related domains, Shodan observations, packet captures, and your own exhausted commentary from 2:11 AM three weeks ago where you wrote:

“This thing smells industrial.”

That note links to another incident. Which links to another hostname. Which links to malware notes. Which links to a router exploit somebody posted to a Russian forum six months ago.

Suddenly your memory becomes navigable terrain instead of static storage.

Most cybersecurity tooling still treats information like isolated puddles. Obsidian turns it into fungal growth. Threads spreading underground.

The Weird Power Of Markdown In Security Work

People underestimate plain text because it looks primitive.

Plain text is immortal.

Every expensive enterprise dashboard eventually becomes archaeology. Proprietary formats rot. SaaS products get acquired by companies with names like NexaCore or Quantivault and suddenly the export function disappears into a premium tier. APIs change. Authentication breaks. A startup folds and takes your workflow down with it like a collapsing mine shaft.

Markdown survives everything.

That matters more than people think.

My vault has incident timelines from years ago sitting beside live scripts ingesting current network telemetry. Same interface. Same search engine. Same linking structure.

A note written half-asleep at a motel desk in 2024 can suddenly become relevant during recon in 2026 because the same infrastructure provider shows up again.

Memory is detection engineering.

Most people just never phrase it that way.

The Actual Setup

I did not build this as some clean enterprise architecture project. It accreted. Like barnacles on a rusted ship.

The first version was literally a Bash script dumping Wi Fi scan results into markdown tables every few minutes.

Then came Dataview.

Then Templater.

Then webhook integrations.

Then I started embedding live content directly into notes.

One pane tracks local network device changes through Python scripts feeding markdown files. Another watches RSS feeds from vulnerability trackers. I have a note that auto-updates with recent CISA advisories because manually checking those every day made me feel like a Victorian clerk sorting telegraphs.

One of the strangest additions ended up being simple colored callouts.

Yellow for suspicious.
Red for confirmed malicious.
Blue for infrastructure notes.
Green for devices I physically own.

You would be surprised how quickly visual memory attaches itself to color-coded threat intelligence. The brain likes symbols. Ancient hardware still hiding under modern skin.

The only real rule I followed was this:

Everything needed to degrade gracefully.

If plugins broke tomorrow, I still wanted readable notes.

If internet access vanished, I still wanted the archive.

If some dependency disappeared into GitHub oblivion after its maintainer got bored and started breeding shrimp or making ambient jungle music, the system should still function.

That constraint changed every design choice afterward.

SOC Tools Want You Looking Outward

This is the part vendors dislike discussing.

Most commercial security tooling assumes centralized environments. Corporate fleets. Teams. Tickets. Compliance reporting. Executive summaries nobody reads except during lawsuits.

Independent operators live differently.

Your laptop matters.
Your home router matters.
The weird Android device from 2018 matters.
The Raspberry Pi in the closet matters.
The café network matters.
The cheap chinese IoT device absolutely matters.

You are simultaneously the analyst, the help desk, the incident responder, and the idiot user clicking strange things at 1 AM because curiosity beat caution for half a second.

Traditional SOC interfaces often feel sterile for this kind of work. Too rigid. Too abstract.

Obsidian felt personal enough to adapt.

I could attach fragmented thoughts directly beside technical indicators. That ended up becoming unexpectedly useful.

“Traffic spike after connecting to train station Wi Fi.”

“Hostname resembles cheap smart camera OEM.”

“Possible overlap with malware infra from earlier scrape.”

Those observations rarely belong in enterprise tooling. They sound subjective. Informal.

But intuition leaves residue. Experienced analysts know this already. Sometimes a detail matters before you understand why it matters.

The vault became a place where incomplete thoughts could survive long enough to become evidence later.

Dataview Turned Notes Into Queries

This was the turning point.

Dataview sounds boring until you realize it effectively lets markdown behave like a database wearing a paper mask.

I started tagging infrastructure notes with metadata.

Country.
ASN.
Service type.
Threat category.
First seen.
Last seen.
Confidence level.

Then suddenly I could generate dynamic dashboards directly inside notes.

All IPs seen in the last week associated with VPS providers.

All incidents involving exposed Jenkins servers.

All notes tagged with “iot-chaos.”

All infrastructure connected to a specific malware family.

The vault stopped behaving like folders and started behaving like intelligence analysis software somebody accidentally hid inside a productivity app.

And because everything remained markdown underneath, it never felt trapped.

That matters psychologically too. Strange point, maybe, but true.

People investigate differently when the environment feels writable.

Traditional dashboards often feel ceremonial. Like you are interacting with sacred infrastructure owned by the company. Obsidian feels more like scribbling theories on the walls of an underground bunker while radios crackle in the background.

That freedom changes how experimental you become.

I Started Sleeping Better

Not because the system made me safer.

Because uncertainty became visible.

There is a difference.

A blinking router at 3 AM feels different when you have nowhere to place the event mentally. It becomes ambient paranoia. A loose thread in consciousness.

But once the event enters a structured system, once it gains timestamps and context and links and historical continuity, the fear changes shape.

It becomes operational.

That distinction matters more than people realize in cybersecurity.

Half the exhaustion comes from fragmented awareness. Tiny unresolved observations accumulating like static electricity in the nervous system.

The vault gave those fragments somewhere to go.

I think a lot of independent security people are quietly dealing with this exact psychological pressure. Too much information. Too many alerts. Too many disconnected observations floating around without narrative structure.

Humans need narrative structure.

Even defenders.

Especially defenders.

The Funniest Part Is That Obsidian Was Built For Productivity People

The original audience was probably students tracking philosophy notes or productivity maximalists inventing increasingly terrifying morning routines involving magnesium supplements and cold showers.

Now there are people wiring packet captures into it.

I have seen vaults used for malware analysis.
Physical penetration testing.
OSINT investigations.
RF experimentation.
Vehicle telemetry logging.
Bluetooth device tracking.

One person embedded a live aircraft tracker beside SDR analysis notes and weather radar feeds. The vault looked like NORAD after taking psychedelics in a RadioShack... Fucking groovy.

Another built an entire intrusion timeline system using canvas mode and local screenshots.

This is what happens when software stays flexible long enough.

People mutate it into things the creators never anticipated.

The internet used to produce more software like this. Open-ended tools. Things that invited adaptation instead of funneling everyone into the same sanitized workflow optimized for quarterly growth metrics.

Obsidian still has some of that older energy.

You can feel it.

There Are Risks Too

A vault like this becomes extremely sensitive very quickly.

People get excited about dashboards and forget operational security entirely.

Now you have local notes containing IP histories, screenshots, investigation timelines, infrastructure fingerprints, maybe even credentials if you are careless enough to let convenience rot your judgment.

Your note-taking app quietly becomes an intelligence archive.

That changes the threat model immediately.

I ended up isolating portions of the vault, encrypting sensitive directories, separating live telemetry ingestion from personal writing, and aggressively controlling plugin permissions.

Some plugins are incredibly powerful. Which also means they can become little supply-chain nightmares if abused.

The irony is hard to miss.

The SOC dashboard itself eventually becomes something worth defending.

Systems do this a lot. Build a tool to observe complexity and eventually the tool becomes part of the complexity.

Like building a lighthouse and realizing ships might start navigating by it.

The Interface Started Changing How I Think

This part is harder to explain cleanly.

When information becomes interconnected visually, your brain starts modeling systems differently.

You stop seeing incidents as isolated events.

Infrastructure clusters emerge.
Behavior patterns emerge.
Certain hosting providers start recurring like bad dreams.
You begin noticing the aesthetic fingerprints of attackers.

Some phishing kits feel visually related even before technical attribution exists. Certain admin panels carry the same design scars. Certain exposed systems have identical weird naming conventions because somewhere an installer script propagated across thousands of deployments like fungal spores.

The vault amplified pattern recognition simply because the information stayed near itself long enough.

Most browser tabs die before your brain can metabolize them properly.

Linked notes linger.

There is something deeply old-world about that. Like intelligence analysts pinning photographs to walls with cigarette smoke hanging in the air. Except now the wall updates itself every thirty seconds and occasionally executes Python.

A haunted corkboard with APIs.

I Don’t Really Separate Research From Memory Anymore

That line dissolved.

My vault contains threat intel beside journal fragments beside hardware notes beside weird observations from roadside motels with unstable Wi Fi.

At first I thought this was messy.

Now I think compartmentalization was the messier approach.

Real investigations are nonlinear. Human memory is nonlinear. Security work is full of emotional residue people pretend does not exist because professionalism likes clean surfaces.

But late-night investigations leave impressions behind.

The room temperature.
The music playing.
The feeling when an IOC suddenly matches something from months earlier.

Tiny details become anchors.

Obsidian accidentally preserves them.

And occasionally that matters.

Final Thoughts From The Glowing Cave Wall

Somewhere along the way, my note-taking app became the first thing I open during an incident and the last thing I close before sleep.

Not because it is the best SOC platform technically.

Because it became cognitively native.

That is rarer than people think.

Most software demands adaptation from the user. This setup adapted itself around the way my brain actually moves through investigations: messy, recursive, associative, suspicious, occasionally obsessive.

The dashboard keeps changing too. Every month another pane appears. Another script. Another stitched-together fragment of awareness.

It no longer feels like software exactly.

More like building a nervous system out of markdown and stubbornness.

And once you experience that, ordinary dashboards start feeling strangely mute.

Full vault template + live scripts are in Obsidian Operator OS linked below.

OBSIDIAN OPERATOR OS // TURN YOUR VAULT INTO A LIVE SOC DASHBOARDv2.6.1 // CLASSIFIED DOSSIER

Check out my other latest guides here-

OPENCLAW 2.0 - POWER USER EDITION2026 Operator's Manual // For Advanced Operators Only

FLIPPER ZERO BLACK BOOK // 37 PAYLOADS THEY DON'T PUT IN THE DOCS

BadUSB Studio: 20 Rubber Ducky Scripts That Bypass Modern AV (2026 Edition)

Originally published on Medium, @neonmaxima.

Claude Code Helped Me Build a Searchable Version of My Own Thinking

v. Splicer — Wed, 13 May 2026 07:33:28 +0000

The motel Wi-Fi kept dropping every seventeen minutes.

I know that because I timed it. Not intentionally at first. You just start noticing patterns when your entire workflow depends on unstable infrastructure. The router sat zip-tied near the ceiling above a fake ficus plant covered in dust so thick it looked felted. Every time the connection died, the little green light blinked twice, paused, then came back like it had briefly forgotten what reality it was supposed to maintain.

I was sitting on the edge of a bed with one shoe on, surrounded by notebooks, half-open markdown files, screenshots of terminal output, and enough disconnected ideas to qualify as a low-level haunting.

At some point around 2:40am, I realized I could not find something important.

Not a file. A thought.

I knew I had scrawled it down in conlang runic glyphs somewhere.

Something about identity systems and emotional telemetry and why old forums felt psychologically different and more like home from modern social media. I remembered the shape of the idea. The atmosphere around it. I even remembered the energy drink stain on the page where I originally wrote part of it. I could almost taste it, but couldn’t quite…. grr.

I could not retrieve it.

That was the real problem.

Not lack of creativity. Retrieval failure.

And weirdly enough, Claude Code ended up changing that more than any productivity system ever did.

Most People Do Not Have an Idea Problem

People talk constantly about generating ideas.

Brainstorming. Innovation. Creativity hacks. Dopamine management for entrepreneurs who treat sleep like a hostile government rumor.

But after years of building things online, I think most technically creative people are drowning in unfinished connections, not absence.

The average person with ten active projects probably already has enough material scattered across their devices to build three companies, write a book, launch a niche media brand, and accidentally start a small digital cult by mistake.

The issue is fragmentation.

Ideas become geographically distributed across your life.

Discord messages.
Obsidian vaults.
Screenshots.
Voice notes.
Terminal comments.
Random .txt files with names like new-thing-final2-real.txt
Half-written blog drafts.
GitHub readmes.
Physical notebooks warped from humidity and neglect.

Eventually your own thinking becomes unretrievable.

Like trying to search a dream after waking up.

The Shift Happened When I Stopped Treating AI Like a Chatbot

At first I used Claude Code the same way most people do.

Debug this.
Refactor that.
Explain this API.
Generate boilerplate.
Summarize documentation.

Useful. Efficient. Forgettable.

Then one night I dumped an entire folder of markdown notes into it because I was too exhausted to organize them manually.

Not polished writing either.

Fragments.

Raw observations.
Half-finished technical theories.
Business concepts.
Psychological notes.
System architecture sketches.
Personal rambling mixed beside hardware research.

A complete cognitive junk drawer.

And Claude started finding connections between things I forgot were related.

That was the moment the interaction changed shape.

It stopped feeling like prompting software.

It started feeling like walking through a searchable version of my own subconscious.

Human Memory Is Terrible at Cross-Referencing

This is the hidden bottleneck behind a lot of creative burnout.

People imagine intelligence as generation power when a massive portion of intelligence is actually retrieval architecture.

Libraries understood this centuries ago.

The internet partially solved it with hyperlinks.

Personal knowledge systems got closer with backlinks and graph views.

But modern digital life exploded into too many disconnected surfaces. Information exists everywhere now, but continuity barely exists at all.

You might write one important thought in a notes app.

A related insight appears months later inside a Discord message.

Then a hardware experiment accidentally validates both ideas during a completely unrelated project.

Your brain vaguely senses a pattern forming, but biological memory is terrible at reconstructing distributed context at scale.

Claude became useful once I realized it could semantically traverse those scattered fragments.

Not through keyword search either.

That part matters.

Keyword search only works if you remember the language you originally used. Human thought does not operate that cleanly. Most memory is atmospheric. Associative. Emotional. Directional.

You remember the feeling around the idea before the wording itself.

Large language models are strangely good at navigating that layer.

I Started Building Notes Differently After That

Once I realized retrieval mattered more than polish, my entire documentation process mutated.

I stopped trying to create perfect notes.

Instead, I focused on creating dense, interconnected fragments.

Tiny markdown files.

Short observations.

Unfinished theories.

Context-heavy scraps.

Some of my most useful files are embarrassingly incomplete:

cheap-sensors-create-fake-authority.md

people-trust-dashboards-too-much.md

dead-forums-felt-more-human.md

storage-units-as-externalized-memory.md

None of these are meaningful alone.

Together they form terrain.

And terrain is searchable.

That distinction completely changed how I think about writing.

Most people only preserve finalized thoughts. But finalized thoughts are actually less valuable for creative exploration because they freeze too early. The rough fragments contain motion. Direction. Potential energy.

Claude became extremely good at navigating that unfinished space.

I could ask things like:

“Have I circled around this idea before?”

Or:

“What recurring themes exist between my hardware projects and blog writing?”

Or even:

“What concepts do I repeatedly abandon then quietly return to months later?”

That last one gets psychologically strange sometimes.

Your Subconscious Leaves Fingerprints Everywhere

This was the unexpected part.

After enough notes accumulated, patterns started surfacing that I had not consciously mapped myself.

Themes repeated across completely unrelated projects.

Surveillance.
Memory decay.
Identity fragmentation.
Offline infrastructure.
Emotional telemetry.
Hidden systems beneath normal interfaces.
Dead internet architecture.
Preservation against disappearance.

Apparently the brain has its own version control system.

Claude would surface connections between files written months apart that shared emotional structure without sharing obvious keywords.

One night it linked:

- a blog draft about abandoned forums
- an ESP32 telemetry experiment
- notes about living out of temporary spaces
- fragments about digital permanence

On paper those are separate domains.

Underneath, they were all exploring the same thing:

How humans leave traces behind systems.

That realization sat with me for a while.

Not because the AI was magically insightful.

Because the pattern already existed and I had failed to notice it.

The Real Power Is Not Generation

I think the current AI conversation is distorted by spectacle.

Everyone focuses on replacement.

- Will AI replace artists?
- Replace programmers?
- Replace writers?
- Replace thinking itself?

Meanwhile one of the most transformative use cases is sitting quietly in the background wearing stolen infrastructure clothes.

Search.

Not web search.

Self-search.

That is the difference.

Search engines indexed the external internet. Systems like Claude can index the continuity of your own cognition if you structure information correctly.

That changes things.

Especially for people building across multiple disciplines simultaneously.

I do not separate my projects cleanly anymore because reality does not separate them cleanly either. Hardware influences writing. Writing influences software tooling. Software tooling influences business models. Business models influence philosophical direction.

The overlap is the point.

Claude helped me navigate overlap instead of suppressing it.

The Workflow Ended Up Looking Weird

The actual system is much uglier than productivity YouTubers would probably recommend.

Most of my information lives in markdown.

Folders everywhere.

Temporary notes mixed with permanent research.

- Logs.
- Fragments.
- Drafts.
- Screenshots converted into text.
- Archived conversations.
-  Project journals.
- Idea clusters.

I archive aggressively now.

Interesting AI conversations become markdown files.

Debugging discoveries become markdown files.

Contradictions become markdown files.

Moments of confusion especially become markdown files because confusion often marks the edge of something important.

The goal is not organization.

The goal is recoverability.

That sounds subtle until you experience the difference firsthand.

Creative people lose enormous amounts of value simply because their previous thinking becomes undiscoverable six months later.

Most ideas do not die.

They become inaccessible.

There Is Something Slightly Dangerous About This

I do not mean dangerous in the cinematic sense.

No glowing red terminal windows. No machine consciousness monologues. No cyberpunk orchestral soundtrack swelling in the background while your smart toaster develops agency.

The danger is psychological.

Externalized memory changes your relationship with forgetting itself.

Humans forget for reasons beyond inefficiency. Forgetting softens old identities. It filters emotional overload. It allows certain versions of ourselves to decay naturally.

A perfectly searchable life would probably become unbearable.

So I curate intentionally.

Not everything deserves preservation.

Some thoughts should evaporate.
Some identities should remain temporary.
Some drafts deserve death.

But for technical work and long-term creative systems?

The payoff is massive.

I can now trace conceptual evolution across years of notes. I can identify recurring blind spots. I can recover abandoned ideas before rebuilding them accidentally from scratch.

And maybe most importantly, I can maintain continuity across periods of chaos.

That part matters more than people realize.

Modern Platforms Are Designed to Erase Continuity

Most digital platforms optimize for immediacy, not accumulation.

Infinite feeds.
Short memory cycles.
Constant novelty.
Disposable interaction.

I find this to get incredibly tedious. I am sure you know what I mean.

You post.
React.
Scroll.
Forget.

Everything becomes present tense. Not in a meditative or zen way- but moreso in a ‘completely out of control’ and ‘tv static is playing in my head 24/7’ way.

But meaningful work usually emerges from layered context accumulated slowly over time. Old internet forums understood this better accidentally than modern platforms do intentionally. Conversations persisted long enough to develop texture.

Now most online interaction feels like speaking into dissolving fog.

Building a searchable second brain became partially defensive for me.

A way to preserve continuity against systems that naturally dissolve it.

Not permanently. Nothing stays permanent online. Entropy still wins eventually.

But long enough to matter.

Claude Feels Less Like an Assistant and More Like Cognitive Infrastructure

That is probably the cleanest way I can describe it now.

Not artificial intelligence as replacement mind.

Artificial intelligence as retrieval layer.

The system is not “thinking” for me in the dramatic science fiction sense people obsess over online. It is helping reconstruct connections between fragments of my own thinking faster than I could manually.

And once you experience that consistently, normal note-taking starts feeling primitive.

You begin thinking differently while writing because you trust future retrieval more.

You stop fearing incomplete thoughts.

You capture more raw observations because the burden of perfect organization disappears.

The friction lowers.

Which means the archive grows richer.

Which means future retrieval becomes stronger.

The whole thing compounds into this strange recursive loop where your own accumulated cognition becomes increasingly navigable over time.

Like building roads through your own mental landscape.

Some roads lead nowhere.

Some loop back unexpectedly.

Some connect territories you did not realize belonged to the same continent.

The Weirdest Part Is Realizing You’ve Been Building the Same Thing All Along

This keeps happening to me now.

I will start a “new” project, then Claude surfaces notes from eight months earlier revealing I was already orbiting the same conceptual territory without realizing it.

Different surface.
Same skeleton underneath.

That feeling is hard to explain.

Like finding old footprints in snow and recognizing your own gait pattern before recognizing the tracks themselves.

You start seeing continuity where you previously saw randomness.

And honestly, I think that may become one of the defining shifts of this entire era.

Not machines replacing humans.

Humans becoming capable of navigating the residue of their own minds at scale.

That is a very different future than the one most people are arguing about online.

The ESP32 Has Quietly Become One of the Most Interesting Hacker Devices Alive

v. Splicer — Mon, 11 May 2026 23:16:01 +0000

Rainwater was dripping through a hole in the gas station awning onto a plastic patio chair that nobody ever sat in. Beside the propane exchange cage, a teenager in a stained hoodie was soldering wires onto a tiny green board using a USB iron plugged into a battery bank. Cars rolled past twenty feet away without noticing that someone was effectively assembling a wireless computer in public for less than the cost of a fast food combo meal.

That feels important somehow.

The ESP32 keeps appearing in places where expensive hardware usually doesn’t survive. Backpacks. Toolboxes. Cracked Pelican cases. Glove compartments filled with receipts and loose change. People build entire portable systems around it using parts scavenged from dead electronics and discount bins. Then those systems end up doing things that, ten years ago, would have required equipment with military aesthetics and four digit price tags.

Most people still mentally file the ESP32 under “maker board.” A toy for hobbyists. Something adjacent to blinking LEDs and YouTube tutorials with unbearable background music.

That classification is outdated.

The ESP32 has quietly evolved into one of the strangest pieces of hacker hardware in circulation because it sits in a rare zone between accessibility and capability. It is small enough to disappear into ordinary life yet powerful enough to interact with the invisible systems surrounding modern civilization. WiFi. Bluetooth. Sensors. RF behavior. Automation. Telemetry. Embedded control. Once you begin experimenting with one, the world starts looking less solid. More negotiable.

And unlike many modern platforms, the thing still feels open in a very raw way. Imperfect. Loose around the edges. Alive.

Cheap Hardware Changes Human Behavior

There is a psychological difference between experimenting with a four dollar board and experimenting with a five hundred dollar device.

People become fearless around cheap hardware.

They cut traces without hesitation. They overvolt things just to see what happens. They shove prototypes into Altoids tins with electrical tape and keep moving. A lot of genuinely interesting hardware culture emerges from environments where failure carries almost no economic consequence.

That matters more than technical specifications.

Expensive hardware often becomes ornamental. People baby it. They curate it. They build identities around owning it. Cheap hardware gets modified until it resembles evidence recovered from a flooded basement.

The ESP32 thrives precisely because nobody treats it with reverence.

You see this everywhere now. Tiny weatherproof sensor nodes zip tied to fences behind apartment complexes. Improvised wardriving rigs hidden inside old GPS housings. Bluetooth experiments powered by salvaged vape batteries. Entire mesh communication systems assembled from boards that collectively cost less than dinner at a chain restaurant.

There is something deeply cyberpunk about that. Not the neon movie version. The real version. Improvised infrastructure held together by curiosity and impatience.

The internet romanticized hacking for decades as something performed inside glowing rooms full of pristine machinery. In reality, a lot of modern experimentation happens beside piles of tangled cables while somebody eats gas station beef jerky and waits for PlatformIO to stop throwing compile errors.

The ESP32 fits that reality perfectly.

Wireless Space Feels Different Once You Can Touch It

Most people experience wireless technology emotionally rather than mechanically. WiFi is either “working” or “not working.” Bluetooth either connects or becomes a ritual sacrifice involving toggling airplane mode seventeen times.

The ESP32 changes your relationship with wireless systems because it lets you observe them directly.

A city starts feeling layered.

Coffee shops leak device identifiers into the street. Apartment buildings hum with overlapping signals like insect swarms trapped inside concrete. Cars broadcast tiny fragments of themselves while waiting at red lights. Fitness trackers whisper continuously into the atmosphere. Smart devices pulse in the background of ordinary life like synthetic wildlife.

You start noticing behavioral fingerprints.

A cheap security camera behaves differently from a corporate laptop. Certain devices become chatty when isolated. Others vanish instantly the moment they sense scrutiny. Some protocols feel ancient and exhausted. Others feel aggressively modern, armored against observation.

The strange part is how quickly this awareness rewires your perception. You stop seeing technology as isolated objects and start seeing environmental systems. The air itself becomes populated.

That sensation hooks people hard.

Not because they all want to become criminals. Most don’t. The attraction comes from recovering visibility. Modern infrastructure hides itself beneath polished interfaces and abstraction layers. The ESP32 lets people peel tiny sections of that abstraction back open.

Just enough to glimpse the machinery underneath.

It Arrived at the Exact Right Moment

If the ESP32 had appeared fifteen years earlier, it probably would have remained niche hardware for embedded engineers and RF obsessives.

Instead, it arrived during a period where several strange currents collided at once.

Cheap fabrication became globally accessible. Open source hardware culture matured. Battery technology improved. Wireless ecosystems exploded into absurd complexity. Then social media began accelerating hardware experimentation at a speed forums never could.

Suddenly people were sharing handheld recon builds assembled from off the shelf parts like recipes.

Not polished products. Living projects. Half functional prototypes with exposed wiring and handwritten labels. Somebody posts a weird Bluetooth scanner built into a Game Boy shell, then two weeks later another person adapts the concept into a wearable device powered from a salvaged drone battery.

The ecosystem mutates quickly because the entry barrier remains absurdly low.

That low cost also creates a kind of evolutionary pressure. People experiment recklessly because the financial consequences barely exist. Weird ideas survive longer. Unexpected use cases emerge organically.

Somebody builds an environmental monitoring node for gardening. Somebody else realizes the same architecture works beautifully for off grid telemetry. Another person modifies it into a portable recon platform. Then somebody inevitably shoves the whole thing into a lunchbox and mounts an antenna onto it like they’re preparing to intercept transmissions from a collapsing orbital station.

This is how hacker ecosystems actually evolve. Not through clean corporate roadmaps. Through mutation.

The Board Feels Closer to Street Tech Than Consumer Electronics

A lot of modern consumer technology feels hermetically sealed. Sleek. Controlled. Sterilized against curiosity.

Phones especially.

Modern smartphones are extraordinarily powerful, yet they often feel spiritually dead from an experimentation standpoint. Locked bootloaders. Restricted hardware access. Sandboxed everything. Even basic repair increasingly resembles microsurgery performed inside a legal disclaimer.

The ESP32 feels like the opposite philosophy survived in miniature.

It invites interaction. Direct interaction. Pins exposed. Signals visible. Interfaces available. Documentation scattered everywhere like fragments of recovered engineering notes.

You can connect sensors, displays, radios, storage modules, keyboards, relays, batteries, microphones, NFC readers, LoRa transceivers, and bizarre improvised peripherals within hours of opening the package.

That openness creates emotional attachment in a way polished ecosystems rarely do.

People name their devices. Modify enclosures repeatedly. Carry them daily. Turn them into personalized instruments rather than disposable appliances. Entire online subcultures now orbit custom ESP32 creations with the same energy older generations once reserved for modified cars or underground music equipment.

Some builds genuinely resemble artifacts from speculative fiction. Brutalist handhelds covered in toggle switches. Pocket sized terminals with monochrome OLED displays. Tiny cyberdecks assembled from recycled BlackBerry keyboards and translucent plastic cases that glow dim red in dark rooms.

But beneath the aesthetics, there is something more meaningful happening.

People are rebuilding tactile relationships with computing.

That might be the most important part.

The Security World Accidentally Created a New Generation of Hardware Tinkerers

The rise of devices like the Flipper Zero changed public perception dramatically. Suddenly millions of people who previously never touched embedded hardware became fascinated with RFID, NFC, sub-GHz communication, and wireless experimentation.

Predictably, many of them started looking beyond closed commercial devices.

That path often leads directly toward ESP32 development.

Not because the ESP32 replaces dedicated hardware entirely. It doesn’t. Specialized tools still matter. But the board offers something psychologically addictive: malleability. You are not confined to the manufacturer’s imagination.

You can build exactly the thing you want.

Or try to.

That distinction matters. Half the charm of hardware experimentation comes from failure anyway. Burned regulators. Corrupted firmware. Antenna designs that behave like cursed artifacts. Displays that only work when physically threatened.

The process develops intuition. You begin understanding systems spatially rather than abstractly.

That kind of literacy feels increasingly rare now.

Most people consume technology passively. The ESP32 ecosystem quietly encourages the opposite behavior. Touch things. Modify things. Observe consequences. Repeat.

Sometimes the result is elegant.

Sometimes the result looks like it survived an electrical fire inside a submarine.

Both outcomes teach something.

Tiny Boards, Strange Future

The weirdest thing about the ESP32 is that it no longer feels tied to any single culture.

It exists simultaneously inside maker spaces, cybersecurity communities, art collectives, off grid communication groups, industrial automation environments, indie game hardware scenes, vehicle diagnostics projects, wearable tech experiments, and improvised research labs assembled inside spare bedrooms.

Different people keep discovering the same board for completely different reasons.

An artist uses it to create reactive installations.
A mechanic builds wireless telemetry tools.
A student learns packet analysis.
A farmer automates irrigation.
A hacker constructs a pocket recon device capable of mapping nearby wireless behavior while sitting unnoticed in a coffee shop corner pretending to check email.

The hardware remains the same. The intent mutates around it.

That flexibility is rare.

Most devices arrive with identities already assigned to them. The ESP32 still feels unresolved somehow. Like the culture surrounding it is actively being invented in real time by whoever happens to pick one up next.

And maybe that uncertainty is exactly why the board matters.

Because modern computing increasingly pushes people toward sealed ecosystems where interaction is carefully managed and curiosity becomes a subscription tier. The ESP32 moves in the opposite direction. Small board. Exposed pins. Strange possibilities.

A piece of hardware that still invites experimentation instead of merely consumption.

That invitation is becoming uncommon.

Maybe dangerously uncommon.

If you want to explore what the ESP32 ecosystem is actually capable of beyond beginner tutorials and recycled LED projects, I recently put together a field guide focused on wireless research, portable experimentation, recon builds, and practical hardware concepts:
POCKET RECON: 75 ESP32 Projects for Wireless Research and Portable Hacking

POCKET RECON: 75 ESP32 Projects for Wireless Research and Portable Hacking

Built for people who prefer solder fumes, pocket tools, improvised antennas, and seeing what the air around them is really doing.

My Backpack Is Slowly Turning Into a Mobile Recon Lab

v. Splicer — Mon, 11 May 2026 23:03:47 +0000

The zipper gave up before I did.

Not dramatically. No cinematic rupture. Just a quiet mechanical surrender somewhere in a parking lot behind a thrift store while I was digging for an ESP32 board wrapped in anti static foam and a USB cable that smelled faintly like burned dust. The bag split slightly near the seam and a small avalanche of adapters, batteries, RFID cards, and tangled wires spilled into the passenger seat like electronic organs.

That was the moment I realized my backpack had stopped being a backpack a long time ago.

It had become infrastructure.

Not polished infrastructure. Not the kind with Pelican cases and color coordinated inserts and little labels made on a Brother printer. Mine looks more like somebody robbed a RadioShack during a geomagnetic storm. But piece by piece, it started forming into something coherent. A portable recon environment. A moving workstation for curiosity. A black nylon ecosystem full of tiny radios whispering at each other in different frequencies while I sit in coffee shops pretending to answer emails.

And the strange thing is how normal this kind of setup is becoming.

A few years ago, portable hardware hacking still felt niche enough to attract attention. Pull out an SDR antenna in public and somebody looked at you like you were about to contact a weather satellite or unlock a stolen car. Now? Half the devices in my bag look like oversized vape accessories or weird battery banks. Tiny computers have become socially invisible. Most people have no idea how much capability can fit into something the size of a pack of gum.

That invisibility changes behavior.

You stop thinking in terms of “workstation” and start thinking in terms of field conditions. You notice dead WiFi zones. You notice exposed access points. You notice how many buildings leak Bluetooth signals into parking lots at night. You start carrying equipment the same way older generations carried pocket knives or lighters. Not because you always need them, but because eventually the environment presents a situation where having them changes everything.

The backpack adapts first. Then your brain follows.

The Tiny Device Explosion Changed the Culture

The current generation of cheap embedded hardware has quietly distorted the boundary between hobbyist electronics and actual reconnaissance tools. Especially the ESP32 ecosystem.

That board has become absurd.

Not in a marketing sense. In a practical sense. Tiny dual core microcontrollers with integrated WiFi and Bluetooth used to feel specialized. Now they are basically digital pigeons. Cheap enough to scatter everywhere. Disposable if necessary. Powerful enough to automate half the strange little tasks people used to need laptops for.

I started carrying one “just in case.” Then two. Then variants for different tasks.

One configured for Bluetooth experiments. Another for WiFi mapping. Another attached to a battery pack and hidden in a sunglasses case because the shape fit perfectly. Eventually the bag began accumulating supporting infrastructure around them. SMA antennas. OLED displays. MicroSD modules. Tiny keyboards. Power banks. Dupont wires tied together with old twist ties from bread bags.

The ecosystem grows like mold in the dark. Quietly. Incrementally.

And because most of the hardware is inexpensive, experimentation becomes emotionally different. You stop treating devices like sacred objects. You start modifying them recklessly. Drilling holes into cases. Soldering connectors at 2 AM. Flashing questionable firmware while sleep deprived and drinking gas station coffee strong enough to remove paint.

That freedom matters.

People underestimate how much innovation comes from psychological permission to break things.

Coffee Shops Have Become Ambient Intelligence Environments

There is a particular atmosphere that forms when you sit in a crowded coffee shop with a backpack full of radios.

The room feels layered.

Normal people hear cups clinking and espresso machines screaming like injured machinery. You hear that too, but another invisible environment overlays itself on top of it. Bluetooth beacons. Probe requests. Random IoT devices chattering into the void. Smart watches announcing themselves every few seconds like nervous birds.

You begin seeing public spaces less as architecture and more as signal terrain.

I once spent two hours inside a nearly empty Panera debugging an ESP32 script while a nearby smart TV repeatedly exposed its pairing behavior every thirty seconds. Nobody noticed. Nobody cared. The entire room was saturated with invisible machine behavior leaking into the air continuously.

That realization changes your relationship with technology permanently.

Most systems are not silent. They are merely untranslated.

And once you carry portable tools capable of translating pieces of that environment, ordinary places stop feeling ordinary.

Battery Anxiety Becomes a Philosophy

Portable recon setups eventually revolve around power management more than hardware itself.

Nobody tells you this at first.

Beginners obsess over gadgets. Experts obsess over charging strategies.

At some point I realized I was carrying more battery capacity than actual clothes during overnight trips. Slim battery banks. Fast charging modules. Backup cells wrapped in electrical tape because the original casing cracked months ago. Tiny USB testers with glowing blue displays measuring current draw like miniature life support monitors.

The modern recon bag is basically a nervous system with lithium blood.

And battery psychology affects behavior in strange ways. You begin calculating energy expenditure instinctively. Which devices deserve full charge cycles. Which can survive partial depletion. Which cables are trustworthy. Which chargers produce strange heat signatures and probably belong nowhere near your expensive hardware.

You develop irrational emotional attachments to reliable power banks.

I have one scarred Anker unit that has survived rain, drops, overheating, and what I strongly suspect was a minor electrical short inside a motel room in Tennessee. That thing feels less like an accessory and more like an old war dog.

Portable systems create emotional ecosystems around reliability.

Recon Culture Has Drifted Toward Modularity

The older hacker fantasy involved giant command centers. Towers of screens glowing in dark rooms. Permanent installations. Cyberpunk cathedral aesthetics.

Real life turned out smaller and stranger.

The most effective setups I’ve seen lately are modular, ugly, and adaptable. Velcro attached components. Elastic organizers stuffed with adapters. Tiny Linux machines living inside hard drive cases. Foldable keyboards that feel like artifacts from alternate timelines where office supplies became spy gear.

Mobility changes priorities.

You stop asking “What is the most powerful setup?” and start asking “What survives movement?”

That question eliminates huge amounts of unnecessary complexity.

A recon bag has to tolerate friction. Dirt. Heat. Random environments. Fast deployment. Rapid shutdowns. Public spaces. Car interiors. Rain. Bad motel lighting. Sleep deprivation. Sometimes all within the same day.

The fantasy aesthetic fades. Function starts mutating the system naturally.

And honestly, the resulting setups often look cooler anyway. Less curated. More alive.

The Psychological Effect of Carrying Capability

This part is harder to explain without sounding dramatic.

Carrying portable recon equipment changes your perception of helplessness.

Not because it turns you into some omnipotent cyber wizard. Real life is less theatrical than that. Most days your hardware just sits quietly in your bag while you answer messages or walk around half awake.

But capability alters internal posture.

Knowing you can inspect networks. Analyze nearby devices. Deploy portable servers. Capture signals. Clone tags. Automate repetitive tasks. Troubleshoot systems from a park bench. That changes how environments feel.

You stop perceiving technology as fixed infrastructure owned by other people.

You begin perceiving systems as negotiable.

That mental shift is enormous.

Most people interact with technology passively. Their devices dictate terms. Their platforms dictate limitations. Their software dictates behavior.

Portable recon culture flips the relationship slightly. Even if only psychologically.

The machine becomes terrain again.

Half the Gear Is Accidental

Nobody builds the perfect bag intentionally.

The best setups evolve through weird accidents.

An adapter bought for one project suddenly becomes essential six months later. A random pouch from a surplus store ends up fitting three battery packs perfectly. A cheap antenna unexpectedly outperforms an expensive one. Some cursed little cable survives years of abuse while premium braided cables die instantly like Victorian children.

My current backpack contains at least four objects whose original purpose I no longer remember.

One tiny waterproof container now exclusively stores microSD cards filled with firmware builds and Linux utilities. It used to contain mints. Another pouch was originally intended for camera lenses. Now it holds antennas, RFID tags, and enough USB adapters to communicate with spacecraft from 2009.

Recon culture has a scavenger energy to it.

Part engineering discipline. Part raccoon behavior.

There Is Something Weirdly Comforting About Portable Systems

Late at night, in unfamiliar places, portable labs create a strange sense of continuity.

Hotels feel less anonymous when your hardware spreads across the desk in recognizable patterns. Tiny LEDs blinking softly in dark rooms. Charging indicators glowing red and blue like artificial campfires. OLED displays showing scrolling logs while traffic murmurs outside.

The setup becomes environmental stabilization.

A small controllable ecosystem.

I think this is partially why so many technically inclined people become obsessed with EDC culture and portable infrastructure. The gear is practical, sure, but it also creates psychological territory. Familiar systems inside unfamiliar environments.

Like carrying fragments of your workshop through space.

The Future Looks Smaller, Stranger, and More Distributed

The old image of hacking centered around giant centralized machines because computing itself was centralized.

Now capability keeps shrinking physically while expanding functionally.

Tiny boards handle tasks that once required desktops. Portable SDRs can inspect signal environments from a moving vehicle. Battery powered systems can host local services, automate reconnaissance, or monitor environments continuously while fitting inside ordinary bags.

The scale inversion is fascinating.

The systems are becoming less visible while becoming more capable.

That has implications far beyond hobby electronics. Education changes. Security changes. Field operations change. Independent research changes. The gap between institutional tooling and individual tooling narrows slightly every year.

And most people barely notice it happening.

They still think of laptops as “real computers” while tiny embedded systems quietly colonize everything around them.

Cars. Buildings. Appliances. Infrastructure. Retail systems. Toys. Medical devices.

The modern world increasingly runs on invisible little machines.

Eventually people start carrying counter machines to understand them.

That is where the backpack begins transforming.

Not into a weapon exactly. Not into a cinematic spy kit. Something subtler.

A portable interface layer between you and the increasingly opaque systems surrounding modern life.

And once that process starts, the bag never really goes back to normal.

Every trip becomes an excuse to optimize it slightly further. Another antenna. Another cable. Another tiny board with experimental firmware loaded onto it at 1:47 AM while synth music echoes through cheap speakers and your desk looks like a failed attempt at building a weather control device.

The zipper eventually fails.

The system keeps evolving anyway.

If you’re building your own portable recon setup, experimenting with ESP32 hardware, or turning random electronics into field tools, you might like my guide:

POCKET RECON: 75 ESP32 Projects for Wireless Research and Portable Hacking

A dense collection of portable builds, wireless experiments, recon concepts, and weird little machines that fit in your pocket but behave like much larger systems.

Your Phone Connects to Fake Cell Towers Daily — Here's How I Detect Them

v. Splicer — Tue, 05 May 2026 17:14:15 +0000

Your phone will connect to the strongest tower it hears. It does not ask for ID first. It assumes trust, and that assumption is the entire problem.

I first noticed this in 2019 outside a security conference in Las Vegas. My test Android dropped from LTE to 2G for 47 seconds, then returned to normal. No user notification. The baseband logs showed a cipher downgrade to A5/0, a location area code that did not exist in any public database, and a silent authentication request. I was running SnoopSnitch because I was testing detection methods for a client. The log was clean evidence of an IMSI catcher in operation.

That was six years ago, when the hardware still cost five figures. In 2026, you can build a functional LTE catcher for under $600 with open source software and a software defined radio. I know because I build them for red team exercises, then I build the tools to find them.

If you carry a phone, you have probably connected to at least one fake tower this year. Here is how I find them, and how you can too.

The Protocol Problem No One Fixed

Cellular networks were engineered for availability, not verification. Your device constantly transmits its presence to nearby towers. The tower with the strongest signal wins the connection. Only after attachment does the network authenticate the subscriber. The device never authenticates the network in 2G, and only partially in 4G and 5G.

Carriers maintain backwards compatibility with 2G for legacy devices and rural coverage. A fake tower exploits this by broadcasting a powerful 2G signal. Your modern phone, even a 2026 flagship, will downgrade to maintain service. During that downgrade, encryption is often disabled, and your IMSI and IMEI are transmitted in clear text.

In 4G and 5G networks, the attack is more subtle. Instead of forcing 2G, modern simulators broadcast a malformed 5G NSA cell that triggers a fallback to LTE with null integrity protection. The phone believes it is performing a normal handover. The user sees full bars.

This is not theoretical. I have captured these events in major US cities, at airports, and near government facilities. The devices are smaller now, often battery powered, and designed to operate for short durations to avoid detection.

Why Detection Matters in 2026

The threat model has shifted. Ten years ago, IMSI catchers were restricted to federal agencies. Today, the components are commercial off the shelf. A BladeRF x40, a Raspberry Pi 5, and srsRAN provide a complete LTE network in a package smaller than a textbook.

Private investigators use them for location tracking. Corporate security teams deploy them at events to monitor staff devices. Criminal groups use passive GSM sniffers, which cost about $35 in hardware, to harvest identifiers for SIM swap operations.

Passive sniffing is particularly common because it does not transmit, which keeps it outside many regulatory frameworks. An RTL-SDR dongle can log every IMSI within 500 meters without ever alerting the target device.

Your phone provides no native warning for any of this. iOS provides zero baseband visibility to users. Android provides limited access, and only on specific hardware with root access.

My Detection Methodology: Four Layers

I do not rely on a single application. Effective detection requires correlation across multiple data sources.

Layer 1: Baseband Monitoring on Android

For consistent detection, you need direct baseband access. On Qualcomm devices, this is possible with diagnostic mode.

SnoopSnitch remains the most reliable tool. Install from F-Droid, grant root, and enable active tests.

It monitors for:

Cipher downgrades to A5/0, A5/1, or A5/2
Location area code changes inconsistent with movement
Missing neighbor cell lists
Authentication requests without encryption
Silent SMS type 0 messages

Run it continuously for at least seven days to establish a baseline. Real networks have quirks, but they are consistent quirks. A fake tower introduces anomalies that do not repeat.

For manual verification, use service mode.

Samsung devices: dial #0011#. Pixel devices: *##4636##

…then select phone information. Document your serving cell, physical cell ID, TAC, and band. If you observe a sudden shift from LTE band 2 to GSM 850 in an urban area with strong LTE coverage, that warrants investigation.

Layer 2: Tower Baseline Mapping

You cannot identify an anomaly without knowing normal. I maintain a personal database of legitimate towers for areas I frequent.

Use CellMapper to log cells during normal travel. Export the data weekly. I run a simple Python script that compares current serving cells against my historical database. Any cell ID that appears for less than three minutes and is not in OpenCellID or my logs gets flagged.

Key indicators in the data:

TAC values of 1, 0, or 65535, which are reserved for testing
MCC/MNC combinations that do not match local carriers
Cells with no neighbor relations
Signal strength above -55 dBm in an area where macro cells typically provide -80 to -95 dBm

A legitimate small cell will appear consistently. A portable simulator will appear once, then vanish.

Layer 3: SDR Spectrum Analysis

This is the most definitive method. A software defined radio sees the raw RF environment, independent of your phone's interpretation.

My field kit consists of a HackRF One, a telescopic antenna, and a laptop running SDR++. Total cost is approximately $350. For mobile use, I use an RTL-SDR v4 with an Android phone and RF Analyzer.

Procedure:

Tune to the downlink bands for your region. In the US, this is 617-894 MHz and 1930-1995 MHz for LTE, and 3700-3980 MHz for C-band 5G.
Observe the waterfall display. Legitimate towers produce stable, continuous carriers with consistent bandwidth.
Look for transient carriers that appear suddenly at high power, operate for 5 to 20 minutes, then disappear.
Decode the broadcast channel using gr-lte or srsRAN. Examine the SIB1 messages. Fake towers often omit the full PLMN list or broadcast incorrect tracking area codes.

I have identified simulators by their imperfect implementation of timing advance values. Real networks adjust timing continuously. Many open source implementations use a static value, which creates a detectable signature in the logs.

Layer 4: 5G and LTE Security Mode Analysis

Modern catchers target 5G to LTE fallback. Detection requires examining NAS messages.

On a rooted Qualcomm device, enable modem logging with QPST or use Android's built-in bug report to extract radio logs. Search for SecurityModeCommand messages. A security header type of 0 indicates no integrity protection. In commercial networks, this should never occur outside of initial attach, and even then only briefly.

Also monitor for repeated Authentication Request messages. A real network authenticates once per session. A catcher will often re-authenticate multiple times to harvest responses.

Practical Workflow

I have automated most of this process because manual review does not scale.

Daily operation: SnoopSnitch runs in background on a dedicated Pixel 6a. It uploads alerts to a private server. CellMapper logs continuously.

When traveling to sensitive locations: I activate the HackRF in my bag, recording IQ data to a 256GB SD card. The recording is time stamped with GPS.

Weekly review: I process the logs with a script that correlates three data points. If SnoopSnitch reports a cipher downgrade, CellMapper shows an unknown cell, and the SDR shows a transient carrier at the same time and location, that is a high confidence detection.

False positives occur. Network maintenance, temporary cells on wheels for events, and new small cell deployments can trigger alerts. I validate by checking carrier maintenance notices and by revisiting the location 24 hours later. Persistent anomalies are rare in legitimate infrastructure.

iOS Limitations and Workarounds

Apple provides no public API for baseband information. Field test mode, accessed via 3001#12345#, shows limited data but requires manual documentation.

For iPhone users, I recommend a two device approach. Carry a low cost Android device, such as a Motorola G Power, with no SIM card installed. Run SnoopSnitch and CellMapper in monitoring mode. The device will still scan and log surrounding cells without connecting to a network. If the Android detects an anomaly, assume your iPhone was also affected.

Alternatively, rely entirely on SDR monitoring. The RF environment is identical regardless of phone operating system.

What To Do Upon Detection

Do not engage with the suspected device. Enable airplane mode for 15 seconds to force network reselection, then move at least 200 meters from the location.

Document the event. Record time, GPS coordinates, serving cell ID, signal strength, and any application alerts. Preserve SDR recordings if available.

Do not immediately publish the data. Correlate with public sources first. Check the FCC spectrum dashboard for licensed temporary operations. Check local news for events requiring portable cells. Most legitimate deployments are documented somewhere.

In two years of active monitoring in three cities, I have documented four high confidence detections that did not correlate with legitimate activity. All four involved short duration cells with test PLMNs, null encryption, and signal strengths inconsistent with macro tower placement.

Building Long Term Situational Awareness

The goal is not to find every simulator. The goal is to understand your personal RF environment well enough to recognize when it changes.

Start by mapping your home and work locations. Spend one week logging. You will learn which bands your carrier uses, what signal levels are normal, and how cells hand over during your commute.

Once you have a baseline, anomalies become obvious. You will notice when your phone camps on an unusual band, or when a new cell appears with no history.

This skill set transfers directly to other areas of wireless security. The same SDR techniques apply to Wi-Fi, Bluetooth, and IoT protocols. The analytical mindset is identical.

If you want the complete hardware list, exact srsRAN configurations, the Python scripts I use for correlation, and the step by step process for building a portable detection kit, I documented everything in my field manual.

The Stingray Survival Kit: Hardware + Software Methods to Detect Fake Towers covers the BladeRF and HackRF setups, the diagnostic commands for every major Android chipset, the CellMapper export workflow, and the SDR signatures for the three most common open source simulators in use today. It is the reference I wish I had when I started this work.

You can find it on my Gumroad along with my other guides on local AI, phone OSINT, and mobile privacy. The link is in my profile.

Stay aware of the signals around you. Your phone will not do it for you.