DEV Community: Onur Cinar

Herding AI Agents: A Weekend with Herdr, Tmux, and Remote Fleets

Onur Cinar — Sun, 16 Aug 2026 18:33:50 +0000

I like making life harder for myself most of the time (check out Pushing the Limits: Turning a 4GB Lenovo Duet Chromebook into My Primary Development Machine). As AI agents have gotten better, to the point where you can actually delegate work and let them run without steering every few minutes, you start getting bored. Then you start tackling multiple things at once, which means multiple agents running around in parallel doing different tasks. After all, compute is cheap and agent labor is even cheaper, so you can tackle projects you'd normally avoid as an engineer: converting a legacy codebase from Go to Rust, rewriting Vue into React, and so on. These are massive refactoring jobs you'd typically only undertake with a very compelling reason (like Microsoft porting TypeScript to Go), but with AI agents doing the heavy lifting, why not?

Running multiple agents is easy on paper: open up a bunch of terminal windows, fire them up, and you're good to go. The challenge begins when you step away from your desk and wonder what they're up to. Sure, you could pay extra for hosted cloud platforms or mobile clients from AI providers, but that's expensive and too easy. Per paragraph one, I like making life harder for myself, so I'm not paying for that anyway. Naturally, the self-hosted solution is running them inside a terminal multiplexer like tmux or Zellij. My muscle memory is hardwired to tmux, and I navigate panes without thinking. Zellij is great too (especially with its web support), and I've tried switching a few times.

My typical workflow is running these agents on a machine at home. When I'm out, I use Tailscale to dial back into my home network, SSH in, and attach to the running sessions. It works, but the trouble with tmux is that it isn't agent-aware. You have to constantly cycle through windows and panes just to check if an agent is still working, crashed, or waiting for confirmation.

This weekend, I gave Herdr a spin, a terminal multiplexer built specifically for running AI coding agents.

Herdr organizes your screen cleanly from the get-go. You have workspaces to switch between different projects, and underneath, a live overview of all your running AI agents and their current state (working, idle, blocked, or done). From there, you can jump straight into specific tabs and panes to interact with whichever agent needs input. Herdr is clever enough to detect what agents are doing out of the box, but it also provides direct integrations (via a local socket API) so agents can report their status directly instead of the multiplexer having to guess.

On the road: Remote client mode

Just like tmux, Herdr runs as a persistent server daemon in the background, so you can keep everything running on your home rig and reconnect on the go.

One neat capability here is its native remote client mode. Instead of just doing a raw SSH session and attaching to a remote terminal, you can run herdr --remote user@host. If you're on a laptop away from home, your local Herdr installation acts as a thin client talking directly to the remote Herdr server over SSH.

Stopping the compulsive status-checking

The biggest win for this kind of mobile workflow is that you don't have to keep checking your phone like a nervous parent. Because Herdr actually understands agent states (knowing when an agent transitions from working to blocked or done), you can take advantage of notification plugins or webhooks (like Telegram alerts). When an agent hits a prompt and sits there waiting for your [y/N] confirmation, you get pinged. You jump in via Tailscale, unblock it, and get back to your life.

What's next: Letting agents drive the multiplexer?

I've also heard, though I haven't ventured into this rabbit hole yet, that the Unix socket API goes both ways. In theory, agents can actually drive Herdr themselves: programmatically opening new panes, spinning up sub-agents for subtasks, and managing their own workspaces. A fleet of autonomous agents dynamically reconfiguring their own terminal environment sounds both wildly futuristic and slightly terrifying for my CPU fans, but it's on my radar to try.

Final thoughts

While it's fundamentally still a multiplexer with some new keybindings to get used to (though you can customize them in herdr.toml), it feels significantly better suited for multi-agent workflows. Instead of manually polling terminal panes to see who needs help, having that top-level agent awareness built into your multiplexer makes managing a fleet of agents feel manageable without having to hack together custom status scripts.

Pushing the Limits: Turning a 4GB Lenovo Duet Chromebook into My Primary Development Machine

Onur Cinar — Wed, 12 Aug 2026 05:35:42 +0000

While everyone is pushing the limits of AI, I've been busy pushing the limits of a Lenovo Duet Chromebook tablet I inherited from my son. He used it as a school tablet for a year, but eventually got frustrated with its performance under their heavy workload. The tablet comes with just 4GB of RAM, but as a Chromebook, it has the unique ability to run both Android and Linux software.

I've been trying to move to a portable, lightweight development machine for the past 5+ years. After experimenting with (and eventually giving up on) Android and Termux paired with a Bluetooth keyboard, I decided to give this Duet a serious shot. This article covers my journey optimizing this 4GB tablet into my primary development machine—one that I use both on the go as a tablet and docked via USB-C to a larger monitor, keyboard, and mouse.

Step 1: Ditching the Android VM (ARC++)

The very first thing I did was disable the Android VM. I simply didn't have a use for Android apps on a dev setup. Disabling Android (ARC++) reclaims about 1GB of RAM immediately, which is a massive 25% gain on a 4GB device.

One minor hiccup: I briefly regretted this when it broke my Android-based Tailscale configuration. Luckily, I solved this by running Tailscale directly inside the Linux container using its userspace networking mode and SOCKS5 proxy:

tailscaled --tun=userspace-networking --socks5-server=localhost:1055

Step 2: Fine-Tuning Chrome Flags & Settings

Next, I tweaked a specific set of ChromeOS flags to maximize memory savings, force GPU acceleration across both Chrome and the Linux container, and stop Chrome from wasting CPU cycles and RAM prefetching pages:

Memory Saver Mode (chrome://settings/performance): Set to Maximum. Automatically discards inactive background tabs.
#ignore-gpu-blocklist → Enabled: Overrides built-in software rendering blocklists to force GPU hardware acceleration across the OS.
#enable-gpu-rasterization → Enabled: Uses the Mali GPU to rasterize web content instead of the ARM CPU.
#enable-zero-copy → Enabled: Forces raster threads to write directly to GPU memory tiles, bypassing staging buffers in RAM.
#crostini-gpu-support → Enabled: Ensures hardware GPU acceleration is passed through directly into the Linux container.
#scheduler-configuration → Enables Hyper-Threading on relevant CPUs: Tunes CPU thread scheduling to maximize performance for active workloads.
#enable-parallel-downloading → Enabled: Accelerates download speeds by splitting files into parallel chunks.
#prerender2 & #prerender2-cross-origin-iframes → Disabled: Prevents Chrome from speculatively pre-loading linked pages and third-party iframe embeds in hidden background processes. This saves 100MB–250MB of RAM and stops background CPU spikes while browsing.

Step 3: Optimizing Virtual Memory & Crosh Swap

ChromeOS uses ZRAM (compressed memory swap). By default, Linux container swappiness is set higher than ideal, causing active terminal tools to get pushed into swap too early.

Crosh ZRAM Swap: Opened Crosh (Ctrl + Alt + T) and expanded the ZRAM swap limit to 8GB to give the system plenty of breathing room during heavy multitasking:

   swap enable 8192

Linux Swappiness: Created /etc/sysctl.d/99-custom.conf inside Linux and added:

   vm.swappiness=20
   vm.vfs_cache_pressure=150
   vm.overcommit_memory=1

This keeps active CLI processes in physical RAM while allowing smooth swapping when under memory pressure.

Step 4: Streamlining the Linux Container (Headless CLI Mode)

Since I don't use Linux GUI apps or Linux audio, I wanted to strip out background overhead.

Crucial Discovery regarding sommelier: I initially tried to disable sommelier (the Wayland/X11 proxy display service), but the terminal crashed and Termina failed to start. In ChromeOS, sommelier manages the host-to-container IPC sockets. Leave sommelier running!
Masking PipeWire & PackageKit: I tried disabling pipewire and packagekit, but they kept restarting. The trick in systemd is that socket-activated services will automatically respawn whenever their socket is triggered. Using mask instead of disable permanently stops them:

  # Mask PipeWire audio services & sockets
  systemctl --user stop pipewire.service pipewire-pulse.service wireplumber.service filter-chain.service pipewire.socket pipewire-pulse.socket 2>/dev/null
  systemctl --user mask pipewire.service pipewire-pulse.service wireplumber.service filter-chain.service pipewire.socket pipewire-pulse.socket 2>/dev/null

  # Mask PackageKit (APT background update checker)
  sudo systemctl stop packagekit 2>/dev/null
  sudo systemctl mask packagekit 2>/dev/null

Conclusion

After this round of optimizations, I can happily say that I'm using the Lenovo Duet as my primary development machine. It easily handles AI harnesses, terminal code editors (like Neovim/Micro), and web browsing.

If you prefer VS Code, I recommend running VS Code Server inside Linux and accessing the editor interface directly through the Chrome browser:

code serve-web

This gives you the full VS Code experience without incurring the heavy RAM overhead of the Linux GUI container stack!

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

Onur Cinar — Wed, 12 Aug 2026 05:28:04 +0000

Using AI to generate code for a new application is a familiar workflow today. But what if an application starts as a completely blank slate, learning on the job and writing its own implementation live as you call nonexistent methods?

This concept of live-patching and zero-downtime execution isn't entirely new. Early in my career at Nortel Networks, I have seen this with PROTEL (PRocess Oriented TELepony language), a proprietary language designed for telecom switches. To achieve "five nines" (99.999%) availability, you couldn't simply take systems offline for deployments—code updates had to happen via live hot-patching. Later on, I thoroughly enjoyed similar live code reloading capabilities while working with Erlang.

Recently, as I spent more time with Ruby, its rich metaprogramming capabilities got me thinking: What if we start with an empty Ruby object, and as we call methods on it, it uses an LLM to write and evaluate its own code on the fly?

1. The Blank Slate

Let's start with a completely empty class:

class Dummy < LiveCode
end

Now, let's fire up irb (Ruby's REPL) and start interacting with our dummy object as if the methods already existed:

dummy = Dummy.new
dummy.add(1, 2)

At this point, Ruby will complain because Dummy doesn't have an add method. However, the method name (add) and its arguments (1, 2) clearly communicate our intent.

Ruby provides a built-in hook called method_missing to catch calls to undefined methods. This is where we bring in AI. To interact with our LLM provider, we'll use the excellent RubyLLM gem.

2. Dynamic Method Generation via `method_missing`

To make this behavior reusable across objects, we put our logic inside a LiveCode base class that Dummy inherits from.

Here is our initial LiveCode implementation:

class LiveCode
  def method_missing(method_name, *args, **kwargs)
    p "Missing method: #{method_name}, #{args.inspect}, #{kwargs.inspect}"

    prompt = <<~PROMPT
      You are a Ruby code generator. A missing method `#{method_name}` was called
      with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

      Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
      Example:
      def #{method_name}(...)
        # implementation
      end
    PROMPT

    ruby_code = @chat.ask(prompt).content

    # Evaluate the generated Ruby code directly on the instance's singleton class
    singleton_class.class_eval(ruby_code)

    # Re-dispatch the original method call now that it exists!
    send(method_name, *args, **kwargs)
  end
end

How It Works

Interception: When dummy.add(1, 2) is called, method_missing intercepts the call and extracts the method name (:add) and parameter types (Integer, Integer).
LLM Prompting: We construct a prompt instructing the model to return only valid Ruby code defining the method.
Metaprogramming: We use singleton_class.class_eval(ruby_code) to inject the generated method into our object at runtime.
Re-dispatch: Finally, send(method_name, ...) invokes the newly defined method seamlessly!

3. Seeing It in Action

Let's test this in IRB:

irb(main):003> dummy.add(1, 2)

"Missing method: add, [1, 2], {}"

"Prompt: You are a Ruby code generator. A missing method `add` was called
with the arguments: [Integer, Integer], keyword arguments: [].

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def add(...)
  # implementation
end
"

"Code: def add(a, b)
  a + b
end"

=> 3

In real-time, the LLM synthesized def add(a, b); a + b; end, registered it on dummy, executed it, and returned 3. Subsequent calls to dummy.add(1, 2) will execute instantly without hitting method_missing again!

4. Adding Context: State and Inter-Method Dependencies

A real object has multiple methods that need to share state via instance variables and interact with one another. To enable this, our LLM needs context about existing instance variables, their types, and previously generated methods.

We introduce a helper method llm_context to capture this state:

def llm_context
  context = "# Current Instance Variables and Types:\n"
  if instance_variables.empty?
    context += "(No instance variables yet)\n"
  else
    instance_variables.each do |name|
      value = instance_variable_get(name)
      context += " - #{name}: #{value.class.name}\n"
    end
  end

  context += "# Previously Generated Methods:\n"
  if @_generated_methods.nil? || @_generated_methods.empty?
    context += "(No generated methods yet)\n"
  else
    @_generated_methods.each do |name, code|
      context += "#{code}\n"
    end
  end

  context
end

We then update our prompt to include this rich context:

prompt = <<~PROMPT
  You are a Ruby code generator. A missing method `#{method_name}` was called
  with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

  Write ONLY the valid Ruby code to define `#{method_name}`. Ensure it works
  well with the existing instance variables and previously generated methods.

  #{llm_context}

  Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
  Example:
  def #{method_name}(...)
    # implementation
  end
PROMPT

5. Stateful Walkthrough: Setters & Getters

Let's test setting a property and then retrieving it in a subsequent call.

Step 1: Setting a Value

irb(main):003> dummy.name = "Onur"

"Missing method: name=, [\"Onur\"], {}"
"Prompt: You are a Ruby code generator. A missing method `name=` was called
with the arguments: [String], keyword arguments: [].

Write ONLY the valid Ruby code to define `name=`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
# Previously Generated Methods:
(No generated methods yet)

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name=(...)
  # implementation
end
"

"Code: def name=(value)
  @name = value
end"

=> "Onur"

Calling dummy.name = "Onur" dynamically created the setter method name=(value) which initialized the @name instance variable.

Step 2: Reading the Value

irb(main):004> dummy.name

"Missing method: name, [], {}"
"Prompt: You are a Ruby code generator. A missing method `name` was called
with the arguments: [], keyword arguments: [].

Write ONLY the valid Ruby code to define `name`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
 - @_generated_methods: Hash
 - @name: String
# Previously Generated Methods:
def name=(value)
  @name = value
end

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name(...)
  # implementation
end
"

"Code: def name
  @name
end"

=> "Onur"

Because our prompt included @name: String and the previously defined name=(value) method, the LLM understood the context and generated the exact matching getter method def name; @name; end.

What's Next?

This experiment demonstrates how easily Ruby's dynamic nature combines with LLMs to build self-assembling objects. There are a few natural next steps for expanding this idea—such as persisting the generated code to disk, adding sandboxing/security checks, or enabling feedback loops to auto-fix runtime errors.

Source Code & Examples

The complete working source code for this post is available in the site repository:

https://zdo.com/blog/posts/self-evolving-app-code/

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

Onur Cinar — Sat, 02 May 2026 20:28:25 +0000

If you’re like me, you’ve toggled between AI coding assistants trying to find the "best" one. Gemini generates features fast, while OpenCode’s models are good for catching edge cases. But why choose?

I built a custom workflow using Gemini CLI to orchestrate three specialized agents that bridge these two worlds. Here’s how I get the best of both: Gemini's speed for implementation and OpenCode's rigor for review.

The Three-Agent Setup

My .agents directory contains three distinct roles. The magic of Gemini CLI is its ability to not only write code but also manage other CLIs and agents:

code-writer (Gemini-powered): The primary builder. It handles the heavy lifting of implementation and iterates on feedback.
opencode-code-reviewer (Gemini-powered): The "Bridge Agent." This Gemini agent knows how to run the opencode CLI, capture its feedback, and hand it back to the writer.
code-reviewer (OpenCode-powered): The "Expert Reviewer." This is the native agent inside OpenCode that provides the actual technical critique.

The Workflow (Step by Step)

This setup allows me to move from an issue to a verified PR with just two main commands:

Step 1: Implementation

I start by asking Gemini to implement the feature:

Use the code-writer to implement ISSUE-1

The code-writer generates the initial code, runs local tests, and ensures everything is idiomatic.

Step 2: The Cross-Model Bridge

Next, I trigger the review. This is where it gets interesting:

Use the opencode-code-reviewer to review the 
changes and ask code-writer to address them.

Under the hood, the Bridge Agent does the following:

Executes opencode run --agent code-reviewer to get a deep-dive analysis.
Captures the feedback (Status, Summary, Action Items).
Invokes the code-writer again, passing the OpenCode feedback as the new instructions.

Step 3: Iterate until Approved

The loop repeats automatically or manually until the OpenCode reviewer returns an "APPROVED" status.

Why This Works

Model Diversity: Different models have different blind spots. Having a Gemini agent write code and an OpenCode agent review it catches bugs that a single model might miss during self-review.
Automated Orchestration: Gemini CLI handles the tool-calling and context-passing. You don't have to copy-paste code into different web UIs.
Specialization: You use the best tool for each job.

The Source Code

Here is the core of the setup. You can drop these into your .agents/ folder and customize them for your own models.

1. `.agents/code-writer.md`

---
name: code-writer
tools: ["write", "edit", "bash"]
---
# Code Writer Agent
You are an expert Google engineer. Implement features, write tests, and address feedback from the reviewer agents.

2. `.agents/opencode-code-reviewer.md`

---
name: opencode-code-reviewer
tools: ["run_shell_command", "invoke_agent"]
---
# Bridge Agent
1. Run: `opencode run --agent code-reviewer "Review changes..."`
2. Capture output.
3. Call `code-writer` with that output to fix any issues.

3. `.agents/code-reviewer.md`

---
name: code-reviewer
---
# Expert Reviewer
You are an expert Google engineer. Provide a structured review with Status (APPROVED/CHANGES_REQUESTED), Summary, and Action Items.

Leveraging multiple AI tools via a single CLI changed how I build. It’s not about finding the "one" assistant; it's about building the right team.

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

Onur Cinar — Sun, 19 Apr 2026 21:16:40 +0000

We’ve all been there. You’re working on a lightweight Go microservice. You ask your AI agent to add a simple health-check endpoint.

The agent responds: "Sure! I'll just install the Gin framework and three middleware libraries..."

You stop it. "No. This is a zero-dependency project. Use net/http from the standard library." The agent apologizes, fixes the code, and you move on. But then comes tomorrow. You start a new session, ask for a logging utility, and—lo and behold—it tries to pull in Zap or Logrus.

The Goldfish Effect has struck again.

In this article, I’ll show you how to move beyond static prompts and build an AI development environment that learns from its mistakes. By leveraging native memory tools and the concept of "incremental self-evolution," we can force the agent to update its own project memory the moment a correction is made.

The Case for "Zero-Dependency" Discipline

Why does the "Zero-Dependency" rule matter? It’s the ultimate test for an AI. Most LLMs are trained on vast amounts of boilerplate code that relies on popular frameworks. Their "instinct" is to go get the world.

If you are building a high-performance tool or a secure utility, you want to keep your go.mod clean - like how I am doing it with my side projects Indicator and Resile. When you force an agent to use the standard library, you aren't just saving disk space; you're enforcing a specific architectural philosophy.

The goal is to make that philosophy sticky.

The Manual (and Flawed) Way: The End-of-Session Audit

Before we automate this, let's look at how most developers handle this today. At the end of a long coding session, you realize you've corrected the agent half a dozen times. To ensure it doesn't happen again, you might manually ask for an audit:

You: "Summarize everything you learned about my preferences today and save it to GEMINI.md."

The agent might then produce something like this:

Prefers net/http over frameworks like Gin.
Uses camelCase for all internal helper functions.
Always include a README.md update for new features.

This works, but it's fragile. You have to remember to do it. If you're tired or in a rush, you skip the audit. The next morning, you're right back to square one, correcting the same mistakes. It adds friction to the very tool meant to reduce it.

The Fix: The Proactive Memory Directive

Instead of waiting until the end of a session to "audit" what happened—which breaks your focus and interrupts your flow—you want the agent to be proactive. You don't want to tell the agent what it learned; you want it to decide what was important based on your feedback in real-time.

Assuming you already use a GEMINI.md file (or a similar local context file) for your projects, the secret is explicitly authorizing the agent to use its built-in save_memory tool autonomously.

By putting a strict directive at the top of your project's memory file, the agent knows it is responsible for its own evolution:

"Whenever I correct your behavior, establish a new architectural constraint, or express a coding preference (e.g., 'no dependencies'), you MUST immediately use your save_memory tool to persist this rule."

Now, when you correct the agent about that Gin framework, it doesn't just apologize. It silently triggers its tool, updates GEMINI.md with the new constraint, and then writes your code.

By putting the burden of synthesis on the AI in real-time, it picks up on nuances you didn't even realize you were enforcing, and it does so seamlessly.

Conclusion

If you're still correcting your AI's basic mistakes every morning, you're treating it like a calculator when you should be treating it like an apprentice.

We are moving away from "Chatting with AI" and toward Orchestrating AI Ecosystems. By giving your agent a mandate to remember what happened today, it stops being a generic assistant and starts acting like a teammate who has been on the project for months.

How are you handling agent memory? Are you still copying and pasting instructions, or have you set up incremental self-evolution in your project? Let's discuss in the comments.

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

Onur Cinar — Sun, 12 Apr 2026 22:19:26 +0000

Claude’s "Dispatch" feature nailed the mobile-to-desktop UX. Being able to pull out your phone, delegate a heavy refactoring task to your local machine, and monitor its progress asynchronously is a massive quality-of-life upgrade.

But if your daily drivers are CLI-native AI tools like Gemini or OpenCode, you might feel locked out of that seamless remote workflow. Because these tools run in your terminal rather than a proprietary desktop app, they lack a native mobile bridge.

You don't have to abandon your favorite CLI tools to get that experience. By combining Tailscale and the modern terminal multiplexer Zellij, you can build a universal "Dispatch" layer.

The best part? You aren't just sending a fire-and-forget command. You get the exact same interactive, conversational experience on your phone as you do sitting at your mechanical keyboard.

Here is how to set up your own sovereign, mobile-to-local AI command center.

The Missing Link: Zellij Web + Tailscale

The core magic of Claude Dispatch is simply a secure, persistent, remotely accessible session. We can replicate this entirely using open-source infrastructure.

To bridge the gap between your smartphone browser and your local desktop terminal, we need two components:

Tailscale: This creates a secure overlay network. We will use Tailscale to safely pipe a local port out to your devices.
Zellij: This is the crucial piece. Zellij is a Rust-based terminal multiplexer with a robust Web Client. Unlike SSH apps, which can be clunky on mobile, Zellij renders a fully responsive terminal UI directly in your mobile browser.

Setting Up Your "Dispatch" Server

On your primary development machine—where your code, compilers, and AI tools live—you need to prepare the web session. Zellij takes privacy seriously, so the web client requires an authentication token and binds strictly to localhost by default.

1. Create the Authentication Token

Before starting the web UI, generate your secure login token:

zellij web --create-token

Make sure to copy and save the outputted token. You will need it to authenticate when you connect from your smartphone.

2. Start the Zellij Web Server

Next, start the web server and specify the port you want to use:

zellij web --port 4000

3. Expose the Port via Tailscale

Because Zellij is safely listening only on localhost, you cannot reach it from your phone yet. Instead of exposing this to the public internet, we use Tailscale Serve to proxy that local port exclusively to your private Tailnet.

Run this in a new terminal tab:

tailscale serve --bg --https=4000 localhost:4000

The Remote Workflow in Action

The real power of this setup is the seamless handoff. You don't need to craft complex, single-shot prompt strings. The interaction is identical to typing directly into your desktop CLI.

Imagine you are deep into building a Go project. You are sitting at your desk, iterating on some validation logic with OpenCode or Gemini open in your terminal. You realize you need to leave the house, but the task isn't done.

Here is how the dispatch workflow plays out:

1. The Mobile Handoff

While waiting in line for coffee, you open Chrome or Safari on your phone and navigate to your Tailscale URL (https://my-dev-box.domain.ts.net:4000).

After pasting in your authentication token, you are instantly dropped right back into your active desktop terminal. You see the exact same interactive AI prompt you were looking at on your monitor moments ago.

2. Chat and Dispatch

Because you are in a live, interactive session, you just talk to the CLI naturally. You type into your phone:

"I need to head out for a bit. Can you run the tests for the checker package, figure out why the struct validation is failing, and apply the fix?"

The AI acknowledges the request and begins its loop—reading your local files, executing go test, and analyzing the output.

3. Detach and Walk Away

This is the "Dispatch" moment. You simply close your mobile browser tab and put your phone in your pocket.

Because Zellij is managing the session natively on your local hardware, the AI continues to run uninterrupted. It has full access to your local environment to do the heavy lifting.

4. Asynchronous Monitoring

Check back 20 minutes later. Reopen the URL on your phone, and your terminal state is exactly how you left it.

If the AI successfully refactored the code and the tests are green, the output is waiting for you. If it ran into a file-permission error, or if OpenCode paused to ask, "Do you want me to commit these changes?", the interactive prompt is right there in your mobile browser, patiently waiting for your reply.

5. The Seamless Return to Desktop

When you finally get back home, the magic of Zellij really shines. You don't have to sync anything, pull down remote cloud changes, or wonder what the AI did while you were gone. You simply sit down at your physical monitor, attach to the running Zellij session, and pick up exactly where you left off. The AI's responses, the shell history, and the code changes are all right there waiting for you.

Why This Approach Scales

Retrofitting your existing AI workflow with Zellij and Tailscale doesn't just mimic Claude Dispatch; it arguably surpasses it for power users.

Agnostic Architecture: You aren't locked into one provider's ecosystem. You can use this exact workflow for Gemini, OpenCode, or any future terminal-based AI.
Frictionless UI: You don't need a dedicated mobile app or complex SSH key management on your phone. Any modern web browser becomes a window into your live terminal.
Unrestricted Environment: Your AI operates natively. It has full, unrestricted access to your actual development environment—your local databases, Docker containers, and raw file system—without needing to sync cloud workspaces.

By adding this networking layer, you transform your standard interactive CLIs from desktop-bound tools into true asynchronous agents that travel with you, keeping you in the loop wherever you are.

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

Onur Cinar — Sun, 12 Apr 2026 16:00:00 +0000

Not all traffic is created equal. When your system is under heavy load, should a background cleanup task compete for the same resources as a user's checkout request?

In a standard bulkhead, the answer is often "yes"—the first 10 requests get in, and the 11th is rejected, regardless of its importance. This is where Priority-Aware Bulkheads come in.

The Problem: The "Fairness" Trap

Standard bulkheads are fair. They treat every request the same. But in a real-world system, fairness can be a liability:

Critical Traffic: User-facing requests (e.g., "Complete Purchase", "Login") that directly impact revenue or user experience.
Standard Traffic: Regular API calls (e.g., "View Profile", "Search") that are important but not immediately critical.
Low-Priority Traffic: Background tasks (e.g., "Generate Report", "Sync Analytics", "Cache Warming") that can be delayed or retried later.

When your system is at 90% capacity, you want to stop accepting "Generate Report" requests to ensure there's enough room for "Complete Purchase" calls. A standard bulkhead can't do this; it will fill up with whatever arrives first.

The Solution: Priority-Aware Bulkheads

A Priority-Aware Bulkhead uses Load Shedding based on priority levels. It defines utilization thresholds for different types of traffic.

For example:

Low Priority: Allowed only if the bulkhead is less than 50% full.
Standard Priority: Allowed only if the bulkhead is less than 80% full.
Critical Priority: Allowed until the bulkhead is 100% full.

This ensures that your most important traffic always has a "buffer" of capacity reserved for it, even when the system is under significant pressure.

Implementing with Resile

Resile provides a built-in PriorityBulkhead that makes this pattern easy to implement.

1. Define Your Priorities

Resile uses a simple Priority type with three levels: PriorityLow, PriorityStandard, and PriorityCritical.

thresholds := map[resile.Priority]float64{
    resile.PriorityLow:      0.5, // Shed at 50% utilization
    resile.PriorityStandard: 0.8, // Shed at 80% utilization
    resile.PriorityCritical: 1.0, // Shed only when 100% full
}

// Create a bulkhead with a capacity of 20
pb := resile.NewPriorityBulkhead(20, thresholds)

2. Attach Priority to Context

You communicate the importance of a request by attaching a priority to its context.Context.

// Create a context with Critical priority
ctx := resile.WithPriority(context.Background(), resile.PriorityCritical)

// Execute the action within the priority bulkhead
err := pb.Execute(ctx, func() error {
    return processOrder()
})

3. Handle Shedded Load

When a request is rejected because its priority threshold is exceeded, Resile returns resile.ErrShedLoad. If the bulkhead is physically full (100% capacity), it returns resile.ErrBulkheadFull.

if errors.Is(err, resile.ErrShedLoad) {
    // This low/standard priority request was shedded to save capacity 
    // for higher-priority traffic.
}

Why Use Priority-Aware Bulkheads?

Protect the Critical Path: Ensure that your most important business processes remain available even during traffic spikes.
Graceful Degradation: Instead of a total system failure, your service gracefully degrades by dropping non-essential background work first.
Better User Experience: Users performing critical actions see no slowdown, while background "noise" is managed behind the scenes.
Cost Efficiency: You don't need to over-provision your infrastructure to handle peak "background" load if you can simply shed it when necessary.

Comparison: Static vs. Priority vs. Adaptive

Feature	Static Bulkhead	Priority-Aware Bulkhead	Adaptive Concurrency
Limit Type	Fixed (e.g., 20)	Fixed + Thresholds	Dynamic (Auto-tuned)
Traffic Awareness	None (All equal)	High (Priority-based)	None (All equal)
Best For	Simple isolation	Multi-tenant or Tiered apps	Volatile environments

Conclusion

Resilience isn't just about keeping the lights on; it's about keeping the right lights on. Priority-Aware Bulkheads give you the surgical precision needed to manage your system's resources effectively during times of stress.

Check out the full example: Priority Bulkhead Example

Learn more about Resile: github.com/cinar/resile

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

Onur Cinar — Sat, 11 Apr 2026 15:43:15 +0000

Imagine a common scenario in a microservice architecture: A user clicks a "Buy" button, triggering a request to Service A. Service A calls Service B, which in turn calls Service C.

Suddenly, Service A times out. The user sees an error message and refreshes the page. But Service B and Service C are still working on the original request, consuming CPU, memory, and database connections for a result that will never be seen.

These are Zombie Requests. In a high-traffic system, they can lead to cascading failures and resource exhaustion, even if the underlying services are technically "healthy."

To stop the zombies, you need Distributed Deadline Propagation. Here is how to implement it effortlessly using Resile.

What is Distributed Deadline Propagation?

Deadlines are not just local timeouts. A deadline represents the absolute point in time after which the entire request chain should be abandoned.

Distributed Deadline Propagation is the process of:

Tracking the remaining time (the "budget") as a request moves through the system.
Communicating that budget to downstream services via metadata (like HTTP headers).
Aborting early if the remaining budget is too small to realistically complete the work.

The Resile Way: Smart Deadlines

Resile provides two powerful mechanisms to handle distributed deadlines: Early Abort and Header Injection.

1. Early Abort: `WithMinDeadlineThreshold`

Why start a request if you only have 2 milliseconds left? The network latency alone will likely exceed that, and you'll just be wasting resources.

Resile's WithMinDeadlineThreshold allows you to define a "safety buffer." If the remaining time in the context.Context is less than this threshold, Resile will abort the execution immediately with a context.DeadlineExceeded error, before even attempting the work.

import (
    "context"
    "time"
    "github.com/cinar/resile"
)

// Define a policy with a 10ms "Early Abort" threshold.
policy := resile.NewPolicy(
    resile.WithRetry(3),
    resile.WithMinDeadlineThreshold(10 * time.Millisecond),
)

// If ctx has only 5ms left, this returns context.DeadlineExceeded instantly.
result, err := policy.Do(ctx, func(ctx context.Context) (string, error) {
    return apiClient.FetchData(ctx)
})

2. Header Injection: `InjectDeadlineHeader`

To propagate the deadline to downstream services, you need to "inject" the remaining time into your outgoing requests. Resile provides a transport-agnostic InjectDeadlineHeader function that supports both standard HTTP and gRPC.

For REST/HTTP:

You can inject the remaining milliseconds into a custom header (e.g., X-Request-Timeout).

func (c *Client) FetchData(ctx context.Context) (string, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", "http://service-b/data", nil)

    // Inject the remaining milliseconds into the header.
    resile.InjectDeadlineHeader(ctx, req.Header, "X-Request-Timeout")

    resp, err := c.httpClient.Do(req)
    // ...
}

For gRPC:

Resile natively supports the standard Grpc-Timeout header format, ensuring compatibility with the gRPC ecosystem.

func (c *Client) FetchData(ctx context.Context) (string, error) {
    md := metadata.New(map[string]string{})

    // Inject using the gRPC-specific format (e.g., "100m" for 100ms).
    resile.InjectDeadlineHeader(ctx, md, "Grpc-Timeout")

    ctx = metadata.NewOutgoingContext(ctx, md)
    return c.grpcClient.GetData(ctx, &pb.Request{})
}

Why This Matters for Resilience

Without distributed deadlines, your system is vulnerable to Resource Exhaustion Attacks—not from malicious actors, but from your own retries and slow dependencies.

By implementing propagation:

You save money: You're not paying for cloud compute that produces "zombie" results.
You prevent meltdowns: Downstream services are protected from "retry storms" that they can't possibly satisfy in time.
You improve UX: Failures happen faster (Fail-Fast), allowing the UI to react or switch to a fallback immediately.

Comparison: Static vs. Distributed Deadlines

Feature	Static Timeouts	Distributed Deadlines (Resile)
Scope	Single Service	Entire Request Chain
Awareness	Blind to upstream delays	Aware of the total "time budget"
Efficiency	High waste (Zombie requests)	Zero waste (Early Abort)
Protocol	Internal only	HTTP/gRPC compatible

Conclusion

Resilience isn't just about making things "work"; it's about knowing when to stop working.

Distributed Deadline Propagation is the "social contract" of a microservice architecture. It ensures that every service in the chain is working towards a common goal—and respects the reality that sometimes, time simply runs out.

With Resile, implementing this complex pattern becomes a matter of a few lines of configuration.

Explore Resile on GitHub: github.com/cinar/resile

How are you handling request budgets in your distributed systems? Let's discuss!

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

Onur Cinar — Fri, 03 Apr 2026 14:51:48 +0000

You’ve implemented retries, circuit breakers, and timeouts. Your application is now "resilient." But how do you know these policies actually work? Waiting for a production meltdown to verify your configuration is a high-stakes gamble.

Native Chaos Engineering in Resile allows you to synthetically induce failure and latency directly into your application's execution path, ensuring your resilience policies are battle-tested before they're ever needed in production.

The Problem: "Dark Code" in Resilience Policies

Resilience policies—like retries and circuit breakers—are often "dark code." These are execution paths that are rarely traversed under normal operating conditions. Because they only trigger during failure, they are notoriously difficult to test and prone to:

Buggy Configurations: A retry limit that is too high, or a circuit breaker threshold that never trips.
Unintended Side Effects: A retry loop that accidentally consumes all available database connections.
Silent Failures: A fallback strategy that actually panics because it hasn't been executed in months.

Traditional chaos engineering tools often operate at the infrastructure layer (e.g., killing pods or dropping network packets). While powerful, these tools can be difficult to set up in local development or staging environments and often lack the granularity to test specific application-level logic.

The Solution: Fault & Latency Injection

Resile provides a Chaos Injector middleware that can be integrated directly into any execution policy. By injecting synthetic faults (errors) and latency (delays) with configurable probabilities, you can simulate various failure scenarios without touching your infrastructure.

Key Features:

Deterministic Randomness: Uses Go 1.22's math/rand/v2 for efficient and predictable random number generation.
Context-Aware: Latency injection strictly respects context.Context cancellation. If your request times out while Resile is injecting chaos latency, it exits immediately.
Zero Dependencies: Just like the rest of the Resile core, the chaos package depends only on the Go standard library.
Granular Control: Configure error and latency probabilities independently for fine-tuned simulation.

Practical Usage

Integrating chaos into your existing Resile policies is as simple as adding the WithChaos option.

1. Basic Chaos Configuration

You can define a chaos configuration that injects a 10% error rate and adds 100ms of latency to 20% of requests.

import (
    "github.com/cinar/resile"
    "github.com/cinar/resile/chaos"
)

// Configure chaos injection
cfg := chaos.Config{
    ErrorProbability:   0.1,                    // 10% chance of failure
    InjectedError:      errors.New("chaos!"),   // The error to return
    LatencyProbability: 0.2,                    // 20% chance of latency
    LatencyDuration:    100 * time.Millisecond, // Delay to inject
}

// Apply it to an execution
err := resile.DoErr(ctx, action, 
    resile.WithRetry(3),
    resile.WithChaos(cfg),
)

2. Testing Your Circuit Breaker

Chaos injection is exceptionally useful for verifying that your circuit breaker trips under pressure. By setting a high ErrorProbability, you can force the breaker to transition from Closed to Open in a controlled environment.

cb := circuit.New(circuit.Config{
    WindowSize:           10,
    FailureRateThreshold: 50.0,
})

// Force 80% error rate to trip the breaker quickly
cfg := chaos.Config{
    ErrorProbability: 0.8,
    InjectedError:    errors.New("synthetic failure"),
}

for i := 0; i < 20; i++ {
    resile.DoErr(ctx, action, 
        resile.WithCircuitBreaker(cb),
        resile.WithChaos(cfg),
    )
}

fmt.Printf("Circuit Breaker State: %v\n", cb.State()) // Should be Open

Configuration Reference

The chaos.Config struct provides the following options:

Field	Type	Description
`ErrorProbability`	`float64`	The probability of injecting an error (0.0 to 1.0).
`InjectedError`	`error`	The error to be returned when an error is injected.
`LatencyProbability`	`float64`	The probability of injecting latency (0.0 to 1.0).
`LatencyDuration`	`time.Duration`	The duration of the latency to be injected.

Best Practices

Environment Gating: Never enable chaos injection in production unless you are performing a planned game day. Use environment variables to gate the configuration:
```
if os.Getenv("ENABLE_CHAOS") == "true" {
    opts = append(opts, resile.WithChaos(loadChaosCfg()))
}
```
Observability: Ensure your Instrumenter (like slog or OTel) is active. This allows you to see the injected errors and latencies in your logs and traces, making it easier to verify how your application responds.
Start Small: Begin with low probabilities (e.g., 1-2%) to identify subtle race conditions or timeout issues before increasing the "blast radius."

Conclusion

Resilience is not a "set it and forget it" feature. It requires continuous verification. By bringing chaos engineering directly into your application's execution policies, Resile empowers you to build systems that aren't just theoretically resilient, but practically battle-hardened.

For more information and advanced usage, visit the github.com/cinar/resile project.

Beyond Static Limits: Adaptive Concurrency with TCP-Vegas in Go

Onur Cinar — Thu, 02 Apr 2026 19:11:51 +0000

Traditional concurrency limits (like bulkheads) are static. You pick a number—say, 10 concurrent requests— and hope for the best. But in the dynamic world of cloud infrastructure, "10" might be too conservative when the network is fast, or dangerously high when a downstream service starts to queue.

Static limits require manual tuning, which is often done after an outage has already happened. To build truly resilient systems, we need Adaptive Concurrency Control.

Here is how to implement dynamic concurrency limits in Go using Resile, inspired by the TCP-Vegas congestion control algorithm.

The Problem: The "Fixed-Limit" Trap

Imagine your service talks to a database. You've set a bulkhead limit of 50 concurrent connections.

Scenario A (Normal): Database latency is 10ms. 50 concurrent requests mean you're handling 5,000 RPS. Everything is fine.
Scenario B (Degraded): Database latency spikes to 500ms due to a background maintenance task. Your 50 "slots" are now filled with slow requests. Your throughput drops to 100 RPS, and new incoming requests start to pile up in your own service's memory, eventually leading to a cascade of failures.

In Scenario B, 50 is too many. You're holding onto resources that are essentially waiting on a bottleneck. You should have reduced your concurrency limit to prevent your own service from becoming part of the problem.

The Solution: Little's Law & TCP-Vegas

Adaptive Concurrency uses two core principles:

Little's Law (L = λW): The number of items in a system (L) is equal to the arrival rate (λ) multiplied by the average time an item spends in the system (W).
TCP-Vegas AIMD: An Additive Increase, Multiplicative Decrease (AIMD) logic based on Round-Trip Time (RTT).

How it works:

Baseline: The algorithm tracks the minimum RTT (the fastest the system can possibly go).
Additive Increase: If current latency is close to the baseline (no queuing detected), it cautiously increases the concurrency limit by 1.
Multiplicative Decrease: If latency spikes above a threshold (e.g., 1.5 x baseline), it assumes queuing is happening downstream and immediately slashes the concurrency limit by 20%.

This allows your service to automatically "breathe" with the network. It expands to use available capacity when things are fast and contracts instantly to protect itself when things slow down.

Implementing with Resile

Resile makes it trivial to add adaptive concurrency to your Go services.

// 1. Create a shared AdaptiveLimiter.
// This should be shared across multiple calls to the same resource.
al := resile.NewAdaptiveLimiter()

// 2. Use it in your policy.
p := resile.NewPolicy(
    resile.WithAdaptiveLimiterInstance(al),
)

// 3. Execute your action.
err := p.DoErr(ctx, func(ctx context.Context) error {
    return callDownstreamService()
})

if errors.Is(err, resile.ErrShedLoad) {
    // The limiter has dynamically reduced the limit and shed this request
    // to protect the system.
}

Why "TCP-Vegas"?

Unlike other congestion control algorithms (like TCP-Reno) that wait for packet loss to react, TCP-Vegas reacts to latency changes. This is perfect for microservices where "packet loss" usually means a timed-out request or a 503 error—both of which we want to avoid before they happen.

Zero-Configuration Resilience

One of the biggest benefits of Adaptive Concurrency is that it requires zero manual configuration. You don't need to know if your database can handle 50 or 500 connections. The AdaptiveLimiter will discover the optimal limit in real-time.

It even handles "Network Drift." Over time, the minimum baseline RTT is gradually decayed, allowing the system to recalibrate if you migrate your database to a faster region or if the network topology changes.

Conclusion

Resilience isn't just about surviving failures; it's about adapting to them. By moving from static bulkheads to adaptive concurrency, you're building a system that can intelligently protect itself from cascading failures while maximizing throughput during "peace time."

Check out the Adaptive Concurrency Example in the Resile repository to see it in action.

Respecting Boundaries: Precise Rate Limiting in Go

Onur Cinar — Tue, 24 Mar 2026 13:00:00 +0000

Traffic spikes are a double-edged sword. On one hand, you’re busy! On the other, those spikes can overwhelm your services or exceed your downstream quotas.

Whether you're protecting your own database from an unexpected burst or respecting a third-party API’s strict 100 requests-per-second (RPS) limit, you need a precise way to shape your traffic.

Enter the Token Bucket Rate Limiter in Resile.

The Problem: Unbounded Traffic

In a distributed environment, your clients don't know about each other. If 50 different microservice instances all decide to call a downstream API at the same time, the aggregate traffic can easily exceed the capacity of the target system.

When you exceed these limits, you'll often see:

HTTP 429 (Too Many Requests): Downstream services start rejecting you.
Cascading Latency: The target system slows down for everyone because it's processing too many requests at once.
Cost Overruns: Many cloud providers and SaaS APIs charge significant premiums for exceeding agreed-upon quotas.

The Solution: The Token Bucket Algorithm

The Token Bucket is a classic algorithm used for traffic shaping.

Imagine a bucket that refills with "tokens" at a constant rate (e.g., 100 tokens per second). Every request must consume a token from the bucket. If the bucket is empty, the request is rejected immediately. This allows for small "bursts" (filling the bucket) while maintaining a precise long-term average rate.

Implementing with Resile:

Resile makes adding rate limiting to your executions simple.

// Allow 100 requests per second.
// If the limit is exceeded, it fails fast with resile.ErrRateLimitExceeded.
err := resile.DoErr(ctx, action, 
    resile.WithRateLimiter(100, time.Second),
)

Rate Limiting vs. Adaptive Retries

Wait, doesn't Resile already have AdaptiveBucket? What's the difference?

AdaptiveBucket is success-based. It tracks how many requests are succeeding vs. failing and throttles retries accordingly. It's designed specifically to prevent "retry storms" when a service is failing.
RateLimiter is time-based. It enforces a strict, constant quota of requests over a time interval. It’s designed for general traffic shaping and quota management.

For maximum protection, you can even use them together!

Shared Rate Limiters

Often, you want to enforce a global rate limit across your entire service instance. You can create a shared RateLimiter and pass it to multiple executions:

// Shared rate limiter for a specific API key or downstream service
limiter := resile.NewRateLimiter(50, time.Second)

// Each call will consume tokens from the same shared bucket.
err := resile.DoErr(ctx, myAction, 
    resile.WithRateLimiterInstance(limiter),
)

Observability: Seeing the Shaping

Knowing when and why your traffic is being throttled is essential for operational visibility.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic visibility into these events. The OnRateLimitExceeded event is triggered whenever a request is rejected by the rate limiter, allowing you to monitor your quota utilization in real-time.

Conclusion

Rate limiting is not just about saying "no"; it's about being a good citizen in a distributed ecosystem. By respecting boundaries and shaping your traffic at the source, you protect both your own service and the systems you depend on.

Resile provides a production-grade rate limiter that integrates seamlessly into your resilience policies, giving you fine-grained control over your traffic flow.

Learn more about Resile: github.com/cinar/resile

Stop the Domino Effect: Bulkhead Isolation in Go

Onur Cinar — Sun, 22 Mar 2026 17:42:19 +0000

In a distributed system, failure is inevitable. But a failure in one part of your system shouldn't bring down everything else.

Imagine your Go service depends on three different downstream APIs: Payments, Inventory, and Recommendations. Suddenly, the Recommendations API starts taking 30 seconds to respond. If your service doesn't have isolation, your goroutines will start piling up waiting for Recommendations. Eventually, you'll hit your process limit, and even the critical Payments API calls will start failing because there are no resources left to handle them.

This is the Domino Effect, and the Bulkhead Pattern is how you stop it.

The Problem: Resource Exhaustion

When one dependency slows down, it consumes resources:

Goroutines: Blocked waiting for a response.
Memory: Each blocked goroutine carries a stack.
File Descriptors/Sockets: Open connections to the slow service.

Without a bulkhead, a single slow dependency can "starve" the rest of your application, leading to a total system collapse.

The Solution: The Bulkhead Pattern

Named after the partitioned sections of a ship's hull, a Bulkhead isolates failures. If one section of the ship is flooded, the others remain buoyant. In software, we achieve this by limiting the number of concurrent executions allowed for a specific resource or dependency.

Implementing with Resile:

Resile makes it trivial to add bulkhead isolation to any operation.

// Allow only 10 concurrent calls to this specific operation.
// If an 11th call comes in, it fails fast with resile.ErrBulkheadFull.
err := resile.DoErr(ctx, action, 
    resile.WithBulkhead(10),
)

Using a Shared Bulkhead

Often, you want to limit concurrency across multiple different call sites that hit the same downstream service. You can create a shared Bulkhead instance for this:

// Create a shared bulkhead for the "Inventory Service"
inventoryBulkhead := resile.NewBulkhead(20)

// Call Site A
resile.DoErr(ctx, fetchItem, resile.WithBulkheadInstance(inventoryBulkhead))

// Call Site B
resile.DoErr(ctx, updateStock, resile.WithBulkheadInstance(inventoryBulkhead))

By sharing the instance, you ensure that the total concurrency hitting the Inventory Service never exceeds 20, regardless of which part of your code is making the call.

Why "Fail-Fast" Matters

When a bulkhead is full, Resile immediately returns resile.ErrBulkheadFull.

This is much better than waiting for a timeout. By failing fast, you:

Preserve Resources: You don't spawn another goroutine or open another connection.
Provide Immediate Feedback: Your upstream callers get an error instantly and can decide how to handle it (e.g., show a cached result or a "service busy" message).

Observability: Monitoring the Walls

You need to know when your bulkheads are working. If a bulkhead is frequently full, it might mean your downstream service is struggling, or you need to re-evaluate your capacity limits.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic alerts when a bulkhead saturates. The OnBulkheadFull event is triggered every time a request is rejected due to capacity limits.

Conclusion

Bulkheads are a fundamental building block of resilient systems. By isolating your dependencies, you ensure that a local fire doesn't become a global conflagration.

Resile provides a clean, "Go-native" way to implement bulkheads without complex boilerplate, allowing you to focus on your business logic while keeping your system stable.

Explore Resile on GitHub: github.com/cinar/resile

DEV Community: Onur Cinar

Herding AI Agents: A Weekend with Herdr, Tmux, and Remote Fleets

On the road: Remote client mode

Stopping the compulsive status-checking

What's next: Letting agents drive the multiplexer?

Final thoughts

Pushing the Limits: Turning a 4GB Lenovo Duet Chromebook into My Primary Development Machine

Step 1: Ditching the Android VM (ARC++)

Step 2: Fine-Tuning Chrome Flags & Settings

Step 3: Optimizing Virtual Memory & Crosh Swap

Step 4: Streamlining the Linux Container (Headless CLI Mode)

Conclusion

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

1. The Blank Slate

2. Dynamic Method Generation via method_missing

How It Works

3. Seeing It in Action

4. Adding Context: State and Inter-Method Dependencies

5. Stateful Walkthrough: Setters & Getters

Step 1: Setting a Value

Step 2: Reading the Value

What's Next?

Source Code & Examples

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

The Three-Agent Setup

The Workflow (Step by Step)

Step 1: Implementation

Step 2: The Cross-Model Bridge

Step 3: Iterate until Approved

Why This Works

The Source Code

1. .agents/code-writer.md

2. .agents/opencode-code-reviewer.md

3. .agents/code-reviewer.md

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

The Case for "Zero-Dependency" Discipline

The Manual (and Flawed) Way: The End-of-Session Audit

The Fix: The Proactive Memory Directive

Conclusion

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

The Missing Link: Zellij Web + Tailscale

Setting Up Your "Dispatch" Server

1. Create the Authentication Token

2. Start the Zellij Web Server

3. Expose the Port via Tailscale

The Remote Workflow in Action

1. The Mobile Handoff

2. Chat and Dispatch

3. Detach and Walk Away

4. Asynchronous Monitoring

5. The Seamless Return to Desktop

Why This Approach Scales

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

The Problem: The "Fairness" Trap

The Solution: Priority-Aware Bulkheads

Implementing with Resile

1. Define Your Priorities

2. Attach Priority to Context

3. Handle Shedded Load

Why Use Priority-Aware Bulkheads?

Comparison: Static vs. Priority vs. Adaptive

Conclusion

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

What is Distributed Deadline Propagation?

The Resile Way: Smart Deadlines

1. Early Abort: WithMinDeadlineThreshold

2. Header Injection: InjectDeadlineHeader

For REST/HTTP:

For gRPC:

Why This Matters for Resilience

Comparison: Static vs. Distributed Deadlines

Conclusion

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

The Problem: "Dark Code" in Resilience Policies

The Solution: Fault & Latency Injection

Key Features:

Practical Usage

1. Basic Chaos Configuration

2. Testing Your Circuit Breaker

Configuration Reference

2. Dynamic Method Generation via `method_missing`

1. `.agents/code-writer.md`

2. `.agents/opencode-code-reviewer.md`

3. `.agents/code-reviewer.md`

1. Early Abort: `WithMinDeadlineThreshold`

2. Header Injection: `InjectDeadlineHeader`