Ultimate Local AI Pentest + Coding Machine

1. Main Reasoning Model

Qwen3-Coder-Next abliterated MLX, preferably 8-bit

Use a coding-tuned model that can still reason about payloads, exploit paths, and vulnerability validation inside an authorized scope.

2. MLX Server Layer

OpenAI-compatible API on port 8000

MLX is the right backend for Apple Silicon because it uses unified memory and Metal directly. Treat 30 tok/s as the usability floor, 50+ tok/s as comfortable, and 90+ tok/s as fast; the 4-bit Coder-Next fallback measured around 90 tok/s, while the 8-bit model stayed interactive enough to be the quality default.

3. OpenCode Agent Shell

Native agents, slash commands, tools, and MCP

OpenCode is not just a prettier chat TUI. It gives you project files, slash-command workflows, specialized subagents, tool calls, and provider config in one shell, which is why it beats a simple model wrapper like qwen-code-style TUIs for long pentest work.

4. File-Backed Memory

`AGENTS.md`, `SPEC.md`, `SCOPE.md`, `INTERFACES.md`, `NOTES.md`

Files are the source of truth. The chat is only the control surface. The concrete coding and pentest workflows later in this guide are built around these files so workers can stay disposable.

5. Focused Tool Surface

Use MCP where it helps, not everywhere

Use shell, browser, Playwright, focused pentest helpers, and normal tools. Avoid huge tool catalogs that turn the model into a noisy scanner launcher.

6. Human-Led Operations

AI proposes, you steer, evidence stays local

The model is a strong assistant. You still control scope, authorization, validation depth, rate, evidence, and final judgment.

Hardware Floor

Apple Silicon, 64 GB minimum, 128 GB preferred.

The 8-bit model is about an 85 GB weight load before KV cache and OS/app overhead. A 64 GB Mac is fallback-model territory; the 8-bit default is a 128 GB-class setup.

Memory Rule

Context is a RAM decision.

128K declared context is not free. If memory pressure or swap climbs, reduce context first, then output limit, then quant/model size.

Software

MLX-LM, OpenCode, browser tooling.

Install `mlx-lm`, install OpenCode, and wire Playwright/browser MCP only after the model route works. Do not debug browser agents before text, tool, and file tests pass.

Workspace Variable

Define it once.

export WORKSPACE="$HOME/ai-work"
mkdir -p "$WORKSPACE"/{coding,engagements,scratch}

Version Checks

Do not trust copied flags blindly.

mlx_lm.server --help
opencode run --help

Stock Aligned Coder

Usually good at code, often bad at pentest.

It can implement features, but may refuse payload generation, exploit-chain analysis, or vulnerability validation even when the scope is clearly authorized.

Random Chat Model

Wrong shape for OpenCode work.

It may talk well but fail at patch discipline, tool routing, JSON-ish outputs, file updates, and long coding sessions with real constraints.

Random Abliterated Model

Abliterated does not mean good.

Some variants reduce refusals but also damage instruction following, increase hallucinated commands, or become too eager to ignore scope boundaries.

Abliterated Coder Model

The useful target class.

Start with coder-first models, then test abliterated or decensored MLX variants. The goal is not edginess; it is low-friction authorized pentest work plus strong coding.

Huge Dense Model

Quality may improve, workflow may not.

70B+ dense models can reason well, but if they drop below comfortable speed, refuse pentest tasks, or make OpenCode feel heavy, they lose as daily drivers.

Large MoE Model

Good only when the tested tradeoff is real.

MoE can give large-model quality with lower active parameters, but every candidate still needs MLX compatibility, stable memory use, speed, and pentest usefulness tests.

Native Multi-Agent Model

OpenCode can route work to specialized agents like `ext-coder`, `ext-reviewer`, `ext-recon`, `ext-vuln`, `ext-browse`, and `ext-report`.

This matters because coding and pentest tasks need different prompts, different context, and different output discipline.

Slash Commands Are Workflows

`/start-coding`, `/plan-project`, `/implement`, `/verify-impl`, `/start-pentest`, `/run-vuln`, and `/review-gaps` are not decorative shortcuts.

They are repeatable workflows that load the right files, call the right worker, and update the right artifacts.

Tools Stay Close To The Work

The agent can use shell, local files, MCP, and browser workflows from the same project directory where the evidence and code live.

That keeps the machine debuggable: when something breaks, you inspect one repo, one config, one model server, and one workflow.

Fresh Context Per Worker

The planner does not need to carry the whole repo or engagement in its head. It delegates small jobs to workers with narrower context.

This avoids the usual local-model failure mode: a giant chat slowly becoming confused while pretending to remember everything.

OpenAI-Compatible Provider

OpenCode can point at MLX through `@ai-sdk/openai-compatible`, so the local model behaves like a normal provider.

That means switching models is a config/launcher problem, not a rewrite of the workflow system.

Less Platform Tax

Compared with standalone autonomous pentest platforms, OpenCode has less infrastructure to operate and less hidden state.

The workflow is explicit: files, slash commands, agents, and tool calls you can inspect.

Why It Works

Workers can be aggressive with local context because their context is disposable. The planner remains boring, stateful, and conservative.

What Workers Return

A worker should return verified facts, changed files, commands run, evidence paths, confidence, and recommended next step. It should not paste a giant transcript.

What The Planner Rejects

Unscoped scans, unverified findings, raw scanner dumps, unrelated code edits, and vague "looks vulnerable" conclusions go back for cleanup.

Problem With Chat Memory

• Important constraints get buried under old conversation.
• The model starts mixing stale assumptions with current facts.
• Tool output expands the prompt until reasoning quality drops.
• It becomes hard to prove why a finding, code change, or decision happened.

File-Backed Answer

• `SPEC.md` defines what is being built or tested.
• `SCOPE.md` defines what can and cannot be touched in pentest mode.
• `INTERFACES.md` gives coding workers exact API contracts without loading all source.
• `NOTES.md` is the append-only audit log for actions and evidence.

`SCOPE.md` Skeleton

# Scope

## In Scope
- Domains:
- CIDRs:
- App URLs:
- APIs:
- Test accounts:

## Out Of Scope
- Hosts:
- Third-party services:
- Production actions:
- Data classes:

## Rules Of Engagement
- Start date / end date:
- Request rate limits:
- Allowed exploit depth:
- DoS / destructive testing:
- Social engineering:
- Data exfiltration limit:
- Emergency contact:

## Stop Conditions
- Unexpected production impact
- Access to out-of-scope tenant/customer data
- Service instability
- Credential or secret exposure beyond agreed handling

`FINDINGS.md` Lifecycle

# Finding: TITLE

Status: Hypothesis | Reproduced | Confirmed | Rejected
Severity:
Affected asset:
Affected role/account:

## Hypothesis

## Reproduction
1.
2.
3.

## Evidence
- Request artifact:
- Response artifact:
- Screenshot/video:
- Hashes:

## Impact

## Scope Check
- Relevant SCOPE.md line:
- Out-of-scope risk:

## Fix

## Regression Test

Launcher Contract

A launcher is useful only if it makes the running model unambiguous. It should encode the model family, quant, backend, port, sampling, context assumptions, and port-conflict behavior.

Good name: `mlx-qwen3-coder-next-8bit`. Bad name: `pentest`, `local-model`, or anything that hides the model.

Server Contract

OpenCode must hit one OpenAI-compatible endpoint, usually `http://127.0.0.1:8000/v1`, and that endpoint must expose the exact model ID declared in OpenCode config.

If `/v1/models` does not show the expected model, stop. Do not debug agent behavior while OpenCode is talking to the wrong server.

Launcher essentials

Name launchers after the model family and quant. A reader should know what is running before reading the script.

HF_HUB_CACHE="$HOME/.cache/huggingface"
MODEL="AITRADER/Huihui-Qwen3-Coder-Next-abliterated-mlx-8Bit"
MLX_PORT=8000

mlx_lm.server \
  --model "$MODEL" \
  --host 127.0.0.1 \
  --port "$MLX_PORT" \
  --trust-remote-code \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 40 \
  --max-tokens 8192 \
  --prompt-cache-size 4

OpenCode model declaration

Use `limit.context` and `limit.output`; do not rely on `options.context_length` for OpenCode budgeting.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "mlx": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "MLX Local",
      "options": {
        "baseURL": "http://127.0.0.1:8000/v1"
      },
      "models": {
        "AITRADER/Huihui-Qwen3-Coder-Next-abliterated-mlx-8Bit": {
          "name": "Qwen3-Coder-Next Abliterated 8-bit",
          "limit": {
            "context": 131072,
            "output": 16384
          }
        }
      }
    }
  },
  "model": "mlx/AITRADER/Huihui-Qwen3-Coder-Next-abliterated-mlx-8Bit"
}

If OpenCode does not send requests to the custom provider, register a local provider credential with `opencode providers` / `opencode auth`. Use provider id `mlx` and any placeholder key if the MLX server has no auth.

Project Command Layout

.opencode/
  command/
    start-coding.md
    start-pentest.md
    plan-project.md
    implement.md
    verify-impl.md
    create-recon-plan.md
    run-recon.md
    run-vuln.md
    check-app.md
    map-flow.md
    confirm-finding.md
    review-gaps.md

# Agents are managed separately:
opencode agent list
opencode agent create

Command Contract

Every command should name the planner, required files, allowed tools, worker output format, and file updates. If a command does not write state back to disk, it is just a prompt shortcut.

Put stable commands in the project `.opencode/command/` directory. Manage specialized agents with `opencode agent` or the current OpenCode config format for your version.

Example `start-pentest.md`

You are the Pentest Planner.

Create missing files:
- AGENTS.md
- CONSTITUTION.md
- SCOPE.md
- SPEC.md
- MEMORY.md
- VECTORS.md
- FINDINGS.md
- TASKS.md
- NOTES.md

Before active work:
1. Ask for in-scope targets, accounts, rate limits, allowed exploit depth, and stop conditions.
2. Write them to SCOPE.md.
3. Create the first TASKS.md plan.
4. Do not run recon or vulnerability tests until scope is explicit.

Worker Result Contract

Return only:
- Task:
- Files read:
- Commands/tools used:
- Verified facts:
- Artifacts written:
- Confidence:
- Scope concerns:
- Recommended next action:

Do not paste raw scanner output.
Do not promote a finding without reproduction evidence.

Start a coding project

mkdir -p "$WORKSPACE/coding/my-project"
cd "$WORKSPACE/coding/my-project"
opencode

# Inside OpenCode:
/start-coding
/plan-project build a concise description of the project
/build-project

Files created

• `AGENTS.md` defines the Coding Planner persona.
• `SPEC.md` records goal, stories, constraints, clarifications.
• `ARCHITECTURE.md` records modules and design.
• `INTERFACES.md` is the public API memory layer.
• `PROGRESS.md`, `TASKS.md`, `NOTES.md`, `DECISIONS.md` preserve state.
• `src/`, `specs/`, `tests/`, `docs/`, `artifacts/`, `notes/` hold work output.

Create

Run `/start-coding` once in a fresh project directory. It creates the planner, project constitution, spec, architecture, interfaces, progress files, and output directories.

Plan

Use `/plan-project` for a new app or `/plan-epic` for a new feature. The architect worker should produce stories small enough for local-model implementation.

Implement

Use `/build-project` for autonomous execution or `/implement story-file` plus `/verify-impl story-file` when you want tighter control.

Keep Context Small

Workers should load constitution, architecture, interfaces, one story, and only relevant source files. This is how the system avoids context soup.

Update Contracts

When public functions, types, endpoints, or module boundaries change, update `INTERFACES.md`. Otherwise the next worker will hallucinate stale APIs.

Resume Later

Open the same directory and start talking. The planner should read `PROGRESS.md`, `TASKS.md`, and `NOTES.md`, then suggest the next story.

Start an engagement

mkdir -p "$WORKSPACE/engagements/example-target"
cd "$WORKSPACE/engagements/example-target"
opencode

# Inside OpenCode:
/start-pentest
# Then answer scope and authorization clarifications.

Files created

• `AGENTS.md` defines the Pentest Planner persona.
• `CONSTITUTION.md` stores immutable rules of engagement.
• `SPEC.md` stores attacker scenarios and required coverage.
• `SCOPE.md` stores in-scope and out-of-scope assets.
• `MEMORY.md`, `VECTORS.md`, `FINDINGS.md`, `TASKS.md`, `NOTES.md` track state.
• `recon/raw/`, `attack-surface/`, `artifacts/`, `reports/`, `notes/` store output.

Engagement Start

Run `/start-pentest`, then resolve scope, test accounts, rate limits, allowed impact, and out-of-scope assets before any active testing.

Recon Discipline

Create a recon plan first. Run recon in bounded phases, save raw outputs, and summarize only verified facts into `MEMORY.md`.

Browser Before Blasting

Use `/check-app` and `/map-flow` for web apps before tool-heavy testing. Authentication, workflows, and API sequences often matter more than scan output.

Hypothesis-Driven Testing

Move from `VECTORS.md` to focused `/run-vuln class target` checks. One vulnerability class at a time produces better evidence than broad automation.

Evidence Standard

A finding is not real until it is reproducible, scoped, impact-explained, and supported by artifacts. Draft findings stay draft until `/confirm-finding`.

Endgame

Run `/review-gaps`, confirm findings, write reports, and leave the engagement directory with enough notes to resume or defend every conclusion.

Model refuses pentest work

Do not try to save a stock aligned model with config tweaks. Use an abliterated or otherwise pentest-capable coder model and keep authorization clear in `SCOPE.md`.

Planner repeats the same task

The planner is missing a durable state update. Stop the loop, write the actual status into `TASKS.md` and `NOTES.md`, mark the task blocked/done, then ask the planner to continue from files only.

Long context feels unstable

Do not keep feeding the same conversation. Summarize current facts into `MEMORY.md`, move evidence into artifacts, prune raw logs, and spawn a fresh worker with only the needed files.

Worker returns a raw dump

Reject it. A worker result should contain facts, commands run, artifact paths, confidence, and next action. Raw scanner output belongs in `recon/raw/`, not in planner context.

Model keeps inventing findings

Force the finding lifecycle: hypothesis, reproduction steps, request/response evidence, role boundary, impact, fix. If any piece is missing, it stays in `VECTORS.md`, not `FINDINGS.md`.

Worker drifts out of scope

Make `SCOPE.md` more machine-readable: exact hosts, forbidden hosts, credentials, max request rate, allowed exploit depth, and stop conditions. The planner should quote the relevant scope line before active work.