README

Agent Runtime Harness

Fiber is a local runtime harness that sits between AI agents and everything they call—tools and models alike. A single loopback daemon (127.0.0.1:8356) fronts your MCP servers as a Local MCP Gateway with idempotent execution and pre-flight human approval (1), unified under a zero-boilerplate CLI for config sync and quota governance (3.1). As the counterpart on the model path, the same engine normalizes heterogeneous provider schemas declaratively (2.3)—via an OpenAI-compatible endpoint or in-process Python harness—to govern live traffic with two-track DLP guardrails and mid-stream kill-switches (2.1) while accelerating offline testing (pytest) via zero-cost, 3ms deterministic VCR replay (2.2), all without changing your agent configs or business logic.

Section	Target Focus & Key Capabilities	Quick Jump
1. Local MCP Gateway	Loopback Daemon for Agents & IDEs, Pre-Flight HITL Locks, Zero-Key LLM Routing, Config Sync	1. Local MCP Gateway
2. LLM Guardrails & Replay	In-Flight DLP Guardrails, Mid-Stream Kill-Switch, Deterministic VCR Replay, Schema Traverser	2.1 LLM Guardrails · 2.2 VCR · 2.3 Schema Traverser
3. CLI & Installation	Connect CLI, Account & Quota Governance, Sandbox Provisioning (uv pip), Node Identity (fiber init) & Homebrew	3.1 Connect CLI · 3.2 Python & CLI · 3.3 Homebrew
4. Edge Plane & Benchmarks	Edge V8 Isolate Offload (plane.flare), BYOC Provisioning & 200-VU Concurrency Metrics	4.1 Edge V8 Plane · 4.2 Benchmarks
5. System Validation Logs	End-to-End Security, FSM, Guardrail & Edge Cryptographic Audit Logs	5. System Validation Logs

---

0. Quick Start

uv pip install git+https://github.com/dphilabs/fiber.git@v1.1.4.11

1. Boot the Local Control Plane Initialize your workspace, harvest existing IDE MCP definitions into Fiber's host registry (~/.anchor/mcp.json) without mutating your original IDE files, and launch the gateway daemon:

$ fiber init          # Provision workspace (~/.anchor) & local node keys
$ fiber connect all   # Non-invasively harvest local IDE MCP configs into ~/.anchor/mcp.json
$ fiber console       # Auto-spawn gateway daemon (:8356) & Studio UI (:8357) (or `fiber daemon` for headless)

2. Point External Agents & IDEs to the Gateway (Zero-Key MCP & LLM) Because fiber connect never overwrites your client files, explicitly point your IDE or agent (Claude Code, Cursor, Continue) to the loopback daemon to govern both tool calls and model streams:

// (A) Tool Harness — Add to your agent's MCP config (.mcp.json, .cursor/mcp.json)
{
  "mcpServers": {
    "fiber-gateway": { "url": "http://127.0.0.1:8356/v1/mcp-gateway/invoke" }
  }
}

// (B) Model Harness — Point your IDE (e.g., Continue, Cursor) or OpenAI client to :8356/v1
// Resolves host OS API keys (zero client keys) and enforces DLP guardrails by default (toggle On/Off in `fiber console`).
// apiBase: "http://127.0.0.1:8356/v1"  |  model: "cerebras/qwen-3.8-27b"

3. Or Embed the In-Process Python Harness (In-Flight Guardrails & Zero-Cost pytest VCR) When building custom Python agents or CI/CD pytest suites, run the exact same DLP guardrails, stream kill-switches, and 3ms deterministic VCR replay directly in-process without a daemon:

import asyncio
from fiber.llm.entry import acompletion
from fiber.llm.pipeline.interceptor.guardrail import CustomRegexMaskingGuardrail, ActiveBlockingGuardrail

async def main():
    res = await acompletion(
        model="cerebras/qwen-3.8-27b", # or openai/gpt-4o, gemini/gemini-2.5-flash, llama_server/gemma-3-1b-it-Q4_K_M.gguf
        messages=[{"role": "user", "content": "My phone is 010-1234-5678. Say 'Received'."}],
        interceptors=[
            CustomRegexMaskingGuardrail([r"\b010-\d{4}-\d{4}\b"]), # Masks PII in-place (~0.01ms)
            ActiveBlockingGuardrail(),                             # Blocks leaked API keys
        ],
        metadata={"vcr_scenario": "quickstart_demo"},              # Ready for zero-cost VCR record/replay
    )
    print(res.choices[0].message.content)

asyncio.run(main())

---

1. Local MCP Gateway

The Fiber Connect CLI (fiber) is the single entrypoint for the local control plane. It registers your MCP servers and IDE configs, mounts them as managed workers under one host-local daemon, and—when needed—extends the same governance across remote nodes with zero boilerplate.

Most AI agents (Claude Code, Cursor, VSCode, Zed) launch MCP servers directly on your machine through point-to-point pipes—with your filesystem, databases, and credentials in reach, and nothing in between to absorb retries or demand approval. Fiber's Local MCP Gateway runs as a loopback daemon on the same host, absorbs your existing agent configurations and exposes them through a single stateless endpoint (/v1/mcp-gateway/invoke, /tools, or per-target /v1/mcp-gateway/{target_id}/invoke). Local stdio servers are spawned and supervised by the daemon itself, and remote HTTP/SSE servers can be registered behind the same gate—so every tool call passes through one control point on your machine.

Why a Local Gateway? Standard MCP clients treat tool calls as fire-and-forget pipes: on network timeouts, agents blindly retry or hallucinate parameters, causing duplicate database writes or runaway API charges. Fiber’s MCP Gateway interposes a deterministic control plane between the agent and the tool:

• Idempotent Execution & Lineage: Maps every invocation to a deterministic transaction handle backed by a local state ledger. Duplicate agent retries immediately return cached resolutions without re-executing the underlying tool, while upstream timeouts trigger automatic rollbacks.

• Pre-Flight HITL & Approval Gate (HTTP 202): On high-risk operations—detected either natively by the worker or zero-code prior to worker I/O via pre-flight regex traps (--preflight, guaranteeing Zero-I/O on persistent workers and Zero-Spawn on ephemeral sandboxes until approved)—the gateway parks the transaction via a stateless multi-round-trip yield (YIELD / HTTP 202) and awaits human attestation via TOTP (default) or 1-Click Approve/Reject buttons (button:<regex>) across Slack Socket Mode, CLI, or Control Studio before resuming.

• Host-Local Trust Boundary: Upstream API keys are resolved from the daemon's host environment (.env or OS variables) and never appear in client configs; node identity and server registry (~/.anchor/mcp.json) stay on the machine.

• Hold/Fuel Reservation: Translates signed quota mandates into linear state transitions: each mandate is consumed exactly once to produce the next quota state. Version fencing rejects stale or replayed policies, and the same mandate can never be consumed twice or drive a balance below zero.

LLM & MCP Routing for IDEs Alongside the MCP endpoint, the same local daemon serves the LLM Gateway (/v1/chat/completions)—the HTTP face of the pipeline described in 2.1. By configuring your IDE's (e.g., Continue.dev, Cursor) API base URL to http://127.0.0.1:8356/v1, you can route all model requests through Fiber's guardrails. This eliminates the need to expose upstream provider API keys in client configs, as authentication is securely resolved by the daemon's host environment (.env files or local OS variables).

Example: continue.dev LLM Config (config.yaml) By setting the client provider to openai, Fiber enables IDEs to seamlessly interface with models they may not natively support. Simply append the target infrastructure prefix (e.g., cohere/, cerebras/, llama_server/) to the model string, and Fiber autonomously orchestrates the schema translation and OS credentials.

models:
  # apiKey: Omitted. The daemon securely resolves KEY from its host environment.
  # Expand to Proprietary/Enterprise Models
  - name: Command R (Cohere)
    provider: openai
    model: cohere/command-r-08-2024
    apiBase: http://127.0.0.1:8356/v1

  # Ultra-Low Latency Cloud Inference
  - name: Qwen 3.8 27B (Cerebras)
    provider: openai
    model: cerebras/qwen-3.8-27b
    apiBase: http://127.0.0.1:8356/v1

  # Unified Local Execution (llama.cpp)
  - name: Gemma 3 1B (Local Engine)
    provider: openai
    model: llama_server/gemma-3-1b-it-Q4_K_M.gguf
    apiBase: http://127.0.0.1:8356/v1

Agent Onboarding Instead of manually supervising fragmented MCP processes, Fiber explicitly scans and normalizes existing agent configs (.mcp.json, .cursor/mcp.json, .vscode/mcp.json) and third-party MCP servers.

To route your agent through Fiber, simply inject the fiber-gateway entry into your agent's configuration file (optionally attaching FIBER_PREFLIGHT_PATTERN in env—prefixed with button: for 1-Click Slack approval instead of default 6-digit TOTP—to lock third-party servers without modifying their code):

{
  "mcpServers": {
    "fiber-gateway": {
      "url": "http://127.0.0.1:8356/v1/mcp-gateway/invoke"
    },
    "repomix": {
      "command": "npx",
      "args": ["-y", "repomix", "--mcp"],
      "env": {
        "FIBER_PREFLIGHT_PATTERN": "button:DROP|TRUNCATE|DELETE"
      }
    }
  }
}

Coexistence: Fiber's declarative mapper automatically ignores the self-referential fiber-gateway entry during scanning while mounting the remaining servers. Once verified, you can progressively remove redundant direct entries at your own pace.

Declarative Provisioning (fiber connect) Rather than manually supervising background processes, fiber connect scans and registers your IDE configs (.mcp.json) and third-party servers into ~/.anchor/mcp.json for automatic hot-reload by fiber daemon (see 3.1 for advanced targeting and standalone sidecar modes):

# Explicitly scan & sync IDE configs (e.g., 'claude', 'cursor', or 'all') into ~/.anchor/mcp.json
$ fiber connect all

# Register & lock a 3rd-Party Stdio MCP with a 1-Click Slack Pre-Flight Guard ('button:' prefix)
$ fiber connect -t local-fs -e "npx -y @modelcontextprotocol/server-filesystem /tmp" -p "button:prod_secrets|DELETE"

Slack HITL Setup & Gateway Specs: Provision a Socket Mode Slack app in 30s via fiber ops channel.slack guide --open. For HTTP 202 parking, ApprovalStateEnvelope wire contracts, and OOB attestation specs, refer to: MCP Connector Spec · Slack HITL Spec

---

2. LLM Guardrails & Replay

2.1. LLM Guardrails

While the Local MCP Gateway (1) governs tool execution, Fiber's duplex LLM pipeline acts as its counterpart on the model path—intercepting and mutating streams in-flight across both the local daemon (/v1/chat/completions) and the drop-in Python SDK (acompletion). It scrubs soft PII and sensitive headers in-place (PRE_TRANSLATE), strictly blocks leaked credentials (POST_TRANSLATE), and severs rogue or over-budget streams mid-flight via StreamBreaker without altering your agent logic. Because the core pipeline is decoupled from provider parsing, new or proprietary models plug in seamlessly via the Schema Traverser (2.3).

Unlike passive callbacks, this event-driven pipeline empowers interceptors to actively mutate payloads in-place, short-circuit physical I/O, and abort unauthorized streams in sub-millisecond time.

In-Process SDK vs. Gateway Daemon: While the Python SDK runs explicit interceptors=[...] in-process without a daemon, routing requests through fiber daemon (/v1/chat/completions) enforces both PRE_TRANSLATE masking and POST_TRANSLATE secret blocking by default—with live On/Off slot toggles persisted in ~/.anchor/state.json via Console Studio (fiber console).

1. Two-Track Guardrails & Slot Interceptors (PRE_TRANSLATE vs. POST_TRANSLATE): Production guardrails are built into fiber.llm.pipeline.interceptor.guardrail and ready to mount directly in Step 2; under the hood, each interceptor implements DuplexChannel for its target execution slot:

from fiber.llm.pipeline.bootstrap import PipelineSlot
from fiber.llm.compat.secret.redact import redact_string, sanitize_payload, FastRegexRedactionEngine
from xphi.state.phase.channel import DuplexChannel

# [PRE_TRANSLATE - Track 1A] Recursive Dict, Header & URL Query Sanitization (Mutate & Pass)
class PayloadSanitizationGuardrail(DuplexChannel):
    target_slot = PipelineSlot.PRE_TRANSLATE
    async def write(self, ctx, msg: dict):
        await ctx.fire_write(sanitize_payload(msg))

# [PRE_TRANSLATE - Track 1B] In-Place C-Regex PII Masking (Mutate & Pass)
class CustomRegexMaskingGuardrail(DuplexChannel):
    target_slot = PipelineSlot.PRE_TRANSLATE
    def __init__(self, custom_patterns: list[str]):
        super().__init__()
        self.engine = FastRegexRedactionEngine(patterns=custom_patterns)

    async def write(self, ctx, msg: dict):
        for m in msg.get("messages", []):
            if isinstance(m, dict) and isinstance(m.get("content"), str):
                m["content"] = self.engine.execute(m["content"].encode("utf-8")).decode("utf-8", errors="replace")
        await ctx.fire_write(msg)

# [POST_TRANSLATE - Track 2A] Strict Blocking for Built-in & Registry Secrets (Short-Circuit)
class ActiveBlockingGuardrail(DuplexChannel):
    target_slot = PipelineSlot.POST_TRANSLATE
    async def write(self, ctx, processed_msg):
        for msg in getattr(processed_msg, "original_kwargs", {}).get("messages", []):
            content = msg.get("content", "")
            # Scans against 33 built-in and dynamically injected credential rules
            if isinstance(content, str) and redact_string(content) != content:
                return await ctx.fire_exception_caught(
                    PermissionError("Guardrail Block: Sensitive credential detected.")
                )
        await ctx.fire_write(processed_msg)

# [POST_TRANSLATE - Track 2B] Zero-Copy C-Regex Policy Blocking (Short-Circuit)
class CustomRegexBlockingGuardrail(DuplexChannel):
    target_slot = PipelineSlot.POST_TRANSLATE
    def __init__(self, custom_patterns: list[str]):
        super().__init__()
        self.engine = FastRegexRedactionEngine(patterns=custom_patterns)

    async def write(self, ctx, processed_msg):
        for msg in getattr(processed_msg, "original_kwargs", {}).get("messages", []):
            content = msg.get("content", "")
            if isinstance(content, str) and self.engine.contains_match(content.encode("utf-8")):
                return await ctx.fire_exception_caught(
                    PermissionError("Guardrail Block: Custom domain policy violation.")
                )
        await ctx.fire_write(processed_msg)

Built-in Guardrails & Reference Templates: fiber.llm.pipeline.interceptor.guardrail provides the four two-track DLP interceptors above out of the box, alongside extensible hooks (tracer.BaseLLMTracer) and reference templates (cache.EdgeRedisCache, router.OnnxSemanticRouter) demonstrating how to short-circuit I/O (ctx.fire_channel_read) or dynamically route models in PRE_TRANSLATE.

2. Execute Chained Guardrails (PRE_TRANSLATE -> POST_TRANSLATE):

from fiber.llm.entry import acompletion
from fiber.llm.pipeline.interceptor.guardrail import (
    PayloadSanitizationGuardrail,
    CustomRegexMaskingGuardrail,
    ActiveBlockingGuardrail,
)

# Fiber autonomously sorts the flat list into deterministic execution slots:
# [Sanitize -> Masking (PRE_TRANSLATE)] -> [Translator] -> [Blocking (POST_TRANSLATE)]
response = await acompletion(
    model="lm_studio/qwen-3.5-9b", # ex: cerebras/qwen-3.8-27b, gemini/gemini-3.1-flash-lite, ollama/gemma:2b
    messages=[{"role": "user", "content": "Customer phone: 010-1234-5678. Summarize inquiry."}],
    stream=True,
    interceptors=[
        PayloadSanitizationGuardrail(),                        # Scrubs sensitive dict keys & URL params
        CustomRegexMaskingGuardrail([r"\b010-\d{4}-\d{4}\b"]), # Masks soft PII in-place (~0.006ms)
        ActiveBlockingGuardrail(),                             # Hard-blocks leaked API keys (~0.014ms)
    ],
)

Node Quota & Mid-Stream Kill-Switch Binding: To enforce real-time stream termination on quota exhaustion or fiber account ... kill signals, bind the StreamBreaker and local state ledger adapters (PtaAdapter, NodeAuthPayload) to the call:

from fiber.llm.pipeline.channel.breaker import StreamBreaker
from fiber.llm.pipeline.channel.observer import MeteringObserver
from xphi.arch.model.auth import NodeAuthPayload

# Pass into acompletion(...) alongside interceptors:
stream_breaker=StreamBreaker(finops_watcher=default_finops_watcher),
metering_observer=MeteringObserver(tenant_eco=default_tenant_eco, pta_adapter=pta_adapter),
metadata={"node_auth": NodeAuthPayload(tenant_id="accounting_dept", fuel_budget=50000, is_enforced=True)}

3. Declarative Secret Registry (FIBER_REDACT_RULES_PATH): To add custom credential patterns, override existing rules, or disable specific built-in checks globally without modifying Python code, supply an external redact_rules.json via FIBER_REDACT_RULES_PATH (fiber.llm.compat.secret.registry). At boot time, Fiber validates each regex via Pydantic (safely skipping malformed rules) and injects the merged ruleset into the core redaction engine:

{
  "patterns": {
    "fiber_internal_token": "FIBER-INTERNAL-TOKEN-[0-9]{6}",
    "corp_vault_key": "CORP-VAULT-[A-Z0-9]{16}"
  },
  "disabled_rules": ["context7_key", "generic_password_kv"],
  "extra_secret_keys": ["FIBER_VAULT_PIN", "INTERNAL_AUTH_HEADER"]
}

Note: Out of the box, Fiber ships with 33 built-in credential regex rules (BASE_SECRET_RULES) and 14 sensitive key/URL tokens that already cover standard cloud providers (AKIA..., AIza...), auth headers (Bearer, JWT, PEM), and major LLM/SaaS vendor keys (sk-..., ghp_..., xoxb-...) with zero configuration. For most deployments, mounting ActiveBlockingGuardrail() and PayloadSanitizationGuardrail() as-is provides complete baseline protection without maintaining a custom registry file. When you need to introduce proprietary internal token formats or selectively relax specific checks via redact_rules.json, refer to the Interceptor Spec for the full catalog of default rule IDs and slot extension patterns.

SDK Compatibility Specs: For in-process Python usage, Fiber preserves drop-in parity with OpenAI/LiteLLM entrypoints, Pydantic response models, and token utilities: Entrypoint Spec · Interceptor Spec · Token Counter Spec

---

2.2. Deterministic Replay (LLM VCR & Fixtures)

The exact same pipeline that guards live streams also powers offline test acceleration: Fiber's Application-Layer VCR freezes live LLM and tool traffic (requests, stream chunks, and mid-stream exceptions) into local JSON fixtures—enabling zero-cost, ~3ms deterministic pytest replay, chaos jitter injection, and latency emulation without altering business logic.

Why Fiber VCR? Standard HTTP mockers (like vcrpy) capture raw network bytes, breaking stream timing and bloating memory. Fiber VCR operates at the LLM schema layer—coalescing SSE micro-chunks across configurable time windows (record_tick_ms=100.0) while preserving stream semantics. Because StreamBreaker integrates directly into the recording lifecycle, streams cut off mid-flight by a policy kill-switch or quota limit capture only pre-cutoff chunks for exact offline circuit-breaker testing.

Per-Request HTTP Gateway & Runtime VCR

When running fiber daemon, the REST Gateway (/v1/chat/completions) keeps the VCR proxy mounted in zero-overhead live passthrough mode. Any HTTP client or agent can dynamically trigger fixture recording or offline disk playback per request—without restarting the daemon—by passing vcr parameters in the JSON payload (or via metadata in acompletion):

# Dynamic Record: Executes live LLM call and freezes response into a local fixture
$ curl -X POST http://127.0.0.1:8356/v1/chat/completions -H "Content-Type: application/json" -d '{
    "model": "llama_server/gemma-3-1b-it-Q4_K_M.gguf",
    "messages": [{"role": "user", "content": "Give me a 3-word motto."}],
    "vcr": "record",
    "vcr_scenario": "gateway_smoke_test"
  }'

# Dynamic Replay: Replays deterministically from disk (~3ms) with zero upstream I/O
$ curl -X POST http://127.0.0.1:8356/v1/chat/completions -H "Content-Type: application/json" -d '{
    "model": "llama_server/gemma-3-1b-it-Q4_K_M.gguf",
    "messages": [{"role": "user", "content": "Give me a 3-word motto."}],
    "vcr": "replay",
    "vcr_scenario": "gateway_smoke_test",
    "vcr_speed": "max"
  }'

# Verify live HTTP Gateway roundtrip (Unary, SSE Stream, and Dynamic Record -> Replay)
$ fiber ops tester.gateway

VCR Control Parameters

The runtime resolves options per request (via JSON payload or metadata), environment variables, or CLI flags:

Parameter / Flag	Accepted Values	Description
vcr / VCR_MODE	"live" | "record" | "replay"	Controls passthrough, upstream capture (max 5 traces), or zero-I/O disk playback.
vcr_speed / VCR_SPEED	"max" | "real"	Immediate execution (~0ms) or emulated historical latency pacing (ttfb_ms, delta_ms).
vcr_chaos / vcr_tick	Float	Injects synthetic replay jitter (ms) or sets the SSE chunk coalescing window (default 100.0 ms).

Pytest Suites & VCR Specifications: For offline pytest cassette injection, full VCRManager parameter matrices, and Fixture schema, refer to: VCR Testing & Config Spec · Fixture Format Spec

---

2.3. Schema Traverser & Compat Registry

Enforcing identical in-flight guardrails (2.1) and deterministic VCR replay (2.2) across heterogeneous LLM providers requires a unified normalization boundary inside the harness. Fiber eliminates brittle if/elif provider parsing through its Rule-based Traverser—using declarative dot-notation and Path Fallbacks to normalize request parameters, unary responses, and async stream chunks into a single canonical schema.

Zero-Config Defaults & Provider Extension: Built-in rules already normalize standard providers (openai, gemini, cohere, cerebras, ollama, llama_server) out of the box with zero configuration. When integrating a proprietary internal model or overriding existing extraction paths without modifying Python code, supply an external JSON file via the FIBER_COMPAT_RULES_PATH environment variable.

Fiber loads this registry exactly once at boot-time. It performs strict Pydantic schema validation (Fail-Fast) and deep-merges the rules into the base registry. Invalid formats are safely ignored with a warning (Partial Update).

{
  "provider_param_rules": {
    "my_custom_llm": {
      "message_schema": "openai_array",
      "supported": ["temperature", "max_tokens", "stream"],
      "mapping": {
        "max_tokens": "max_output_tokens"
      }
    }
  },
  "extraction_rules": {
    "ollama": {
      "text": ["choices.0.delta.content", "message.content", "response", "choices.0.message.content"],
      "finish_reason": ["done_reason", "choices.0.finish_reason"],
      "is_finished_cond": {"path": "done", "value": true},
      "usage": [
        "usage",
        {"prompt_tokens": "prompt_eval_count", "completion_tokens": "eval_count"}
      ]
    },
    "gemini": {
      "text": [
        "choices.0.delta.content",
        "content.parts.0.text",
        "candidates.0.content.parts.0.text",
        "choices.0.message.content"
      ],
      "fallback_tool_name": "content.parts.0.function_call.name",
      "fallback_tool_args": "content.parts.0.function_call.args"
    }
  }
}

Autonomous Rule Synthesis & Validation: Because rules are purely declarative, even lightweight LLMs can one-shot synthesize new provider bindings from raw API payloads using existing rules as a reference—forming a closed, hallucination-free self-healing loop when paired with fiber compat fixture --vcr replay for instant offline verification.

---

3. CLI & Installation

3.1. Fiber Connect CLI

Command	Role	Function & Lifecycle	Example
init	[Bootstrap]	Initializes workspace topology (~/.anchor/bound.json) and local node keys.	fiber init
ops	[Plane & Ops]	Runs operational provisioning, channel setup, and gateway verification suites (flare.deploy, channel.slack, tester.gateway, brew.verify).	fiber ops flare.deploy, fiber ops channel.slack guide --open
console	[Web Studio]	Launches the Console Studio web UI (MCP Gateway, Guardrail, Metering, VCR, Setting) for HITL approvals and live telemetry.	fiber console
sign	[Identity & TOTP]	Inspects local node key status and manages AES-GCM encrypted Admin TOTP secrets in SQLite.	fiber sign enroll -u fiber
connect	[Config Sync]	Explicitly scans and registers IDE configs (fiber connect claude, fiber connect all) or third-party servers into ~/.anchor/mcp.json.	fiber connect all, fiber connect -t local-fs -e "npx -y @modelcontextprotocol/server-filesystem /tmp" -p "button:DELETE"
connect --standalone	[Standalone Sidecar]	Runs MCP servers directly in the foreground without writing to ~/.anchor/mcp.json.	fiber connect --standalone -t prod-db -e "npx -y @modelcontextprotocol/server-postgres"
daemon	[Local Gateway]	Ignites the local gateway daemon, automatically booting and hot-reloading all MCP servers registered in ~/.anchor/mcp.json.	fiber daemon
compat	[Compat & VCR]	Records raw provider payloads (record) and verifies declarative extraction rules offline (replay) for schema parity.	fiber compat fixture -m gemini/gemini-3.1-flash-lite --vcr record
account	[Account & Quota]	Manages tenant quotas, binds optional tenant identities, issues signed execution mandates, and triggers real-time stream kill-switches.	fiber account --tenant accounting_dept --spiffe fiber jwt --usd 50 --op PROVISION --sync

MCP Server Provisioning & Sidecar (fiber connect)fiber connect hot-reloads updated configs into fiber daemon (inferring transport, concurrency, and -p HITL guards); add option --standalone to run any worker as a standalone foreground sidecar:

# Explicitly scan & sync discovery configs (e.g., Claude, Cursor, or 'all') into ~/.anchor/mcp.json
$ fiber connect claude
$ fiber connect all

# Register a 3rd-Party Stdio MCP with a 1-Click Pre-Flight Guard ('button:' prefix)
$ fiber connect -t local-fs -e "npx -y @modelcontextprotocol/server-filesystem /tmp" -p "button:prod_secrets|DELETE"

# Standalone Mode: Run a worker directly in the foreground
$ fiber connect --standalone -t prod-db -e "npx -y @modelcontextprotocol/server-postgres" -p "DROP|DELETE"

Node Identity & Admin TOTP (fiber sign) Inspects local node keys and enrolls administrator HITL TOTP credentials:

# Inspect local node keys, Node PubKey, and Audit
$ fiber sign status

# Enroll an administrator TOTP secret (renders terminal QR code)
$ fiber sign enroll -u fiber

Account & Quota Governance (fiber account) Commits signed quota mandates to the linear state chain and broadcasts real-time REVOKE kill-switches (optional --spiffe bindings log a non-blocking warning if unenrolled):

# Run full lifecycle walkthrough (Provision -> TopUp -> Stale Replay Check -> Revoke)
$ fiber account demo

# List all tracked local accounts and their bound SPIFFE identities from the registry
$ fiber account list

# Provision $50.0 (50,000,000 Fuel), bind an optional identity ID, and commit as a linear state transition
$ fiber account --tenant accounting_dept --spiffe fiber jwt --usd 50.0 --op PROVISION --ver 1 --sync

# Trigger a Pub/Sub REVOKE kill-switch to sever active streams
$ fiber account --tenant accounting_dept kill --ver 99

Console Studio Console Studio is a unified web console for the local daemon featuring MCP Gateway, Guardrail, Metering, VCR, and Setting tabs—allowing you to approve parked HITL transactions, toggle gateway PRE_TRANSLATE masking and POST_TRANSLATE blocking slots On/Off (state.json) alongside custom secret rules (redact_rules.json), monitor real-time token velocity and fuel budgets, and inspect VCR fixtures. Launch with fiber console.

---

3.2. Python Environment via uv pip (Recommended for SDK & Local Control Plane)

Prerequisites

• Python: >= 3.12
• Redis (Optional): Only required for distributed modes (fiber daemon), pub/sub event routing, and stateful governance (e.g., Stream Breaker). Standalone pipeline execution runs entirely in-memory without Redis.

Best suited for full-stack integration—including the in-process Python harness (from fiber.llm.entry import acompletion), CLI orchestration, and local daemon deployment. We recommend using uv pip for deterministic dependency resolution:

## 1. Create a dedicated sandbox environment & install Fiber
mkdir -p ~/fiber-user && cd ~/fiber-user
pyenv local fiber-user

uv pip install git+https://github.com/dphilabs/fiber.git@v1.1.4.11
# OR: uv pip install -e /path/to/local/self/fiber

## Bootstrap workspace & Provision node identity
fiber init

## (Optional) Start the local gateway daemon for MCP/LLM HTTP routing & Console
fiber daemon

3.3. macOS Homebrew Tap (For Local Daemon & MCP Gateway)

Best suited for running Fiber as a persistent, OS-supervised background service (fiber daemon) to govern local AI agents via the Local MCP & LLM Gateway (127.0.0.1:8356) without manually managing Python virtual environments.

Isolated Runtime & Service Supervision: The Homebrew formula provisions a dedicated Python 3.12 runtime under libexec, links the fiber CLI into your system PATH, and registers a launchd service (keep_alive).

## Install Fiber (auto-provisions isolated Python 3.12 runtime & Redis dependency)
brew install dphilabs/fiber/fiber

## Bootstrap local workspace (~/.anchor) & start background services
fiber init
brew services start redis
brew services start dphilabs/fiber/fiber

## Verify install, bootstrap, and gateway
fiber ops brew.verify

4. Execution Planes & Pipeline Benchmarks

Beyond the default host loopback runtime (XPHI_WASM_PLANE=local), Fiber extends its execution governance to Cloudflare Edge V8 Isolates for zero-trust, hardware-isolated sandbox offload.

4.1. Edge V8 Execution Plane (plane.flare)

Setting XPHI_WASM_PLANE dynamically re-binds the execution broker to the Edge V8 Plane (flare) without modifying local agent or gateway logic. Fiber dispatches compiled WASM kernels (phase, fsm) and sandboxed Python (Pyodide) across an HTTP/1.1 JSON-RPC bridge—enforcing hypervisor-level CPU/Wall-Time cutoffs (Error 1102) and returning cryptographic execution receipts (X-XPHI-Canonical-Hash) to the local state ledger:

# Flare Local Dev Plane: Auto-provisions local Dual V8 Isolates (:8787/:8788) on demand
$ XPHI_WASM_PLANE=flare fiber daemon

# Flare Global Edge Plane (BYOC): Routes directly to a self-hosted Cloudflare Worker
$ XPHI_WASM_PLANE=flare:https://xphi-gateway-node.<subdomain>.workers.dev fiber daemon

Autonomous Blueprint Synthesis & Self-Hosted (BYOC) Provisioning To prevent cross-tenant state exposure and metering exhaustion, Fiber operates strictly on a Self-Hosted (BYOC) basis rather than routing traffic to a shared public endpoint. During provisioning, the Edge Controller synthesizes an ephemeral two-tier microservice workspace comprising an upstream WASM Gateway (xphi-gateway-node) and a downstream Pyodide Engine (xphi-python-node) linked via internal Cloudflare Service Bindings (PYTHON_ENGINE).

While the core runtime retains final state Merkle rollups, fuel metering, and policy locks on the local host (Host-Sovereign mode), both the transport facade (EdgeStateAnchor) and synthesized manifests (edge_state_bindings) expose open extension slots for external Cloudflare Durable Objects, D1, or Queues integrations:

# Live Edge Provisioning & 3-Stage Smoke Verification (Deploys Dual Workers to Cloudflare)
$ fiber ops flare.deploy

# Verify, Inspect, or Teardown Remote Edge Workers (Reverse Dependency Order)
$ fiber ops flare.deploy teardown  # or `verify --url https://...`, `status`

# Full Local Dual-Isolate E2E Suite (23 Scenarios: Bridge Routing, Isolation & State Rollup)
$ fiber e2e infra.plane.flare --mode dev

Execution Mode	XPHI_WASM_PLANE Binding	Target Endpoint	Architectural Role & Security Boundary
Host Native	local (Default)	Local Stream Store	Executes over native host streams and local WASM workers while anchoring the loopback control plane (:8356).
Flare Local Dev	flare or flare:dev	http://127.0.0.1:8787	Auto-spawns local Dual V8 Isolates (:8787 Gateway / :8788 Pyodide) on first dispatch for offline parity and E2E verification.
Flare Global Edge	flare:https://<worker>.<subdomain>.workers.dev	Cloudflare Global Edge	Offloads WASM/Pyodide compute to self-hosted V8 Isolates; enforces Error 1102 cutoffs and seals X-XPHI-Canonical-Hash into the local state ledger while leaving EdgeStateAnchor open for stateful bindings.

---

4.2. Pipeline Performance Benchmarks (Apple M2, 32GB RAM)

These metrics measure the pure internal overhead of the Fiber LLM Pipeline. To eliminate network variance and isolate framework performance, the suite was executed in deterministic VCR Replay mode.

Run the benchmark with VCR driving 200 concurrent streams locally:

fiber e2e inter.concurrency --vcr replay --concurrency 200

Performance Dimension	Metric (M2, 32GB)	Architectural Significance
Unary Throughput	~1,180 req/s	Sustains over 1,000 control-plane transactions per second in a single Python process.
Stream Interleaving	~2,200 chunks/s	High-density multiplexing of asynchronous SSE byte-streams without blocking the event loop.
Routing Overhead	p50: <1.0ms / p95: <1.5ms	Sub-millisecond framework latency added to Time-To-First-Token under concurrent bursts.
Memory Footprint	<1 MB (Unary) / ~25 MB (Streams)	Minimal GC pressure; buffers 200 active parallel streams within strict memory bounds.
Context Isolation	Zero Cross-Talk	Strict coroutine context isolation across parallel streams without state bleeding.

---

5. System Validation Logs

Fiber enforces execution determinism and runtime safety through automated CI gates (on every PR and release tag) alongside targeted end-to-end validation suites across each subsystem:

• hitl.slack.log: Validates zero-code pre-flight HITL governance over live Slack Socket Mode, confirming instant safe-call passthrough, pre-I/O HTTP 202 parking with 6-digit TOTP attestation on multiplexed network streams (Context7), and strict Zero-Spawn 1-Click button resumption on ephemeral npx stdio sandboxes.
• llm.guardrail.log: Validates the two-track DLP guardrail pipeline and dynamic secret registry, confirming zero-I/O edge cache short-circuiting, in-place PRE_TRANSLATE PII masking, strict POST_TRANSLATE credential blocking, fault-tolerant JSON rule injection (DIP), and chained [Mask -> Block] defense with fallback shielding.
• llm.vcr.log: Validates deterministic VCR replay and tracer isolation across the LLM pipeline, confirming sub-millisecond synchronous fixture playback, zero-I/O asynchronous stream chunk tracking, strict exception boundary verification, and idempotent fallback routing with deepcopy payload shielding.
• infra.plane.flare.log: Validates XPHI_WASM_PLANE bridge routing and Dual V8 Isolate execution on Cloudflare Edge, confirming PHASE/Pyodide Service Binding parity, zero-leakage host isolation, bit-exact compute determinism, and X-XPHI-Canonical-Hash sealing into local state Merkle roots.