Building a Cost-Optimized AI Development Team in My Homelab

Cloud coding agents are powerful, but one thing became obvious very quickly: running several autonomous agents at the same time can get expensive fast.

I wanted a setup where I could still use strong coding agents when a task genuinely needed them, without spending premium inference on routine work like moving an issue, summarizing a CI failure, checking logs, or routing a frontend task to the right worker.

The solution I’m building is a hybrid development system centered around my homelab.

The goal

I want Slack to be the primary interface.

A normal interaction should eventually be as simple as:

@PM continue the roadmap
@Frontend take the next frontend issue
@Claude review the backend approach
@Security review this release
@Obs what changed in production?

Behind that conversation, GitHub remains the durable source of truth for issues, branches, pull requests, reviews, and project state.

The stack I’m working with

I already use several commercial and self-hosted AI development tools:

  • Claude as a first-class development and reasoning agent
  • ChatGPT Codex for repo-wide implementation and project work
  • Cursor for interactive development and agent-assisted coding
  • GitHub Copilot for repository-native assistance
  • BugBot for independent PR review
  • Hermes inside my homelab stack for local/self-hosted agent workflows
  • Ollama for local model inference
  • Bifrost as a model gateway and routing layer
  • n8n for workflow orchestration
  • GitHub Projects, Issues, and PRs for durable engineering state

The objective is not to replace all of these with one tool. It is to orchestrate them so each one is used where it makes the most sense.

The architecture

The core flow looks like this:

Slack
  ↓
n8n
  ↓
Bifrost
  ↓
Hermes / agent runtime
  ↓
Isolated Git workspace
  ↓
GitHub

Alongside the self-hosted path, cloud coding agents such as Claude, Codex, Cursor, and Copilot can be assigned specific issues when their capabilities justify the cost.

n8n handles deterministic workflow logic. Bifrost acts as the model gateway. Hermes and other local runtimes handle self-hosted agent work. GitHub stores the engineering state.

The key design decision is that not every event deserves an LLM call.

Creating a PR, moving an issue to In Progress, running tests, adding a label, fetching logs, or notifying Slack can all be handled with normal automation.

A tiered model and agent strategy

Instead of assigning the most expensive agent or model to every task, I’m routing work through progressively more capable tiers.

Tier 0 — no model

Automation handles:

  • GitHub Project updates
  • issue routing and assignment
  • CI execution
  • test execution
  • PR labels
  • deployment triggers
  • Slack notifications
  • workflow transitions

This is ordinary automation, and it should stay ordinary automation.

Tier 1 — local homelab intelligence

My RTX A2000 runs lightweight models through Ollama, with Hermes available as part of the local agent stack.

This tier is useful for:

  • PM summaries
  • Slack-thread summaries
  • issue classification
  • acceptance-criteria drafts
  • documentation
  • log summarization
  • test-failure classification
  • basic code review
  • observability triage
  • deciding whether a task needs escalation

Tier 2 — inexpensive coding inference

Well-scoped implementation work can use lower-cost coding APIs or local-capable coding tools for:

  • routine frontend changes
  • routine backend fixes
  • tests
  • refactoring
  • repository exploration

Tier 3 — full development agents

This is where agents such as Claude, Codex, Cursor, and GitHub Copilot come in.

I want to use them for work where an autonomous coding environment, stronger reasoning, or deeper repository context is actually valuable:

  • complex multi-file changes
  • difficult integrations
  • architectural refactoring
  • debugging across services
  • implementation tasks that have already defeated cheaper tiers

Tier 4 — high-risk escalation

The strongest reasoning path should be reserved for genuinely difficult or risky work:

  • production-data migration review
  • authentication and authorization architecture
  • security-sensitive changes
  • race conditions across services
  • repeated failed implementation attempts
  • high-impact architectural decisions

The point is not to avoid frontier AI. It is to make escalation deliberate.

One issue, one implementation agent

One of the most important rules in the system is simple:

One coding agent owns an issue at a time.

Claude, Codex, Cursor, Copilot, or a self-hosted worker can each own separate tickets, but I do not want multiple agents independently editing the same feature at the same time.

Other agents can review the work, but implementation ownership stays clear and branch-isolated.

That gives me a workflow more like a real engineering team:

Issue #21 → Claude
Issue #22 → Codex
Issue #23 → Cursor
Issue #24 → Copilot

Each works on its own branch or worktree.

Review should be independent

The agent that wrote a change should not be the only thing deciding whether the change is good.

My intended pipeline is:

Implementation agent
  ↓
Local/static checks
  ↓
Tests
  ↓
Security scanners
  ↓
Independent reviewer
  ↓
BugBot / premium review when justified
  ↓
QA
  ↓
Release

Tools such as CodeQL, Semgrep, Trivy, Gitleaks, dependency scanning, and test suites can find concrete problems before an expensive reasoning agent ever sees the PR.

That also lets Claude, Codex, Copilot, or another agent act as an independent reviewer instead of having the author simply review its own work.

Security does not start with an LLM

My security agent should first run deterministic tools:

CodeQL
Semgrep
Trivy
Gitleaks
npm audit
Dependabot
secret scanning
SAST

Then a local model can summarize the findings.

Only ambiguous or high-risk issues should be escalated to a stronger reasoning agent.

That is cheaper and, for many classes of vulnerability, more reliable than asking a large model to reread the entire repository on every change.

Observability follows the same philosophy

I do not want an AI agent continuously asking whether production is healthy.

Metrics and alert thresholds should do that work first.

Prometheus / Grafana
Logs / Loki
OpenTelemetry
Vercel
Supabase
GitHub Actions
Uptime checks
        │
        ▼
Deterministic anomaly detection
        │
        ▼
Local summary
        │
        ▼
Escalate only when severe or unclear

A production anomaly can automatically open a GitHub issue, notify the PM agent, assign the appropriate worker, and update the originating Slack thread.

Why the homelab matters

I already run much of the infrastructure required for this approach:

  • Proxmox
  • NVIDIA RTX A2000 12 GB
  • Ollama
  • Hermes
  • Bifrost
  • n8n
  • OpenWebUI
  • SearXNG
  • GitHub-connected development workflows

That means the homelab does not need to replace every commercial AI service.

It handles the pieces that are inexpensive to own and useful to keep under my control:

  • orchestration
  • sandboxes
  • routing
  • testing
  • local inference
  • observability
  • reusable project context
  • agent state

Cloud agents become an elastic capability above that infrastructure rather than the infrastructure itself.

Slack as the command bus

The end-state I’m working toward looks more like a small engineering organization than a collection of chat windows.

                         Slack
                           │
                           ▼
                     PM / Router
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
      Frontend          Backend         Security
          │                │                │
          └────────────┬───┴───────┬────────┘
                       ▼           ▼
                  GitHub Issues   Pull Requests
                       │           │
                       ▼           ▼
                    Reviews      CI / QA
                       │           │
                       └─────┬─────┘
                             ▼
                           Release
                             │
                             ▼
                        Observability

I want to be able to stay in one Slack channel while the underlying system keeps GitHub synchronized and dispatches work to the right agent.

What I’m building next

The next step is a reusable orchestration service I’m calling `dev-orchestra`.

Its first version will connect:

Slack → n8n → Bifrost → Hermes/local worker or cloud coding agent → GitHub

I’ll start with a PM/router and one coding worker, then add independent review, security, QA, release, and observability roles once the core workflow is stable.

The end goal is not a collection of AI tools.

It is a development system where each tool has a clearly defined responsibility, costs are predictable, project state lives in GitHub, and the entire workflow can be operated conversationally from Slack.

This is an architecture I’m actively building, not a claim that every component is already fully autonomous. I’ll update this article with real screenshots, workflow diagrams, and implementation results as the system comes online.

Related Articles