JSON Config: Visual Control Plane for AI Terminals

You edit a nested json config file. You omit a single trailing comma. You launch your agentic CLI. There is no parse error. There is no terminal warning. The tool simply vanishes from your session.

You review the file again. Brackets match. Quotation marks are closed. File paths look accurate. Yet your coding agent fails to register the server, and the runtime provides zero diagnostic feedback.

By 2 AM, you are troubleshooting everything except the configuration file you touched five minutes ago.

Why Manual json config Editing Inevitably Breaks

The issue is not JSON syntax itself. The breakdown occurs because agent configurations are scattered across multiple surfaces, none of which provide immediate feedback.

Four recurring failure modes plague AI development environments:

• Multiple files, zero single source of truth. Model tiers live in one file, API credentials in another, enforcement hooks in a third, and MCP server declarations in a fourth. Modifying one parameter requires remembering every dependent location.
• Silent failure modes. Invalid JSON often fails without visible errors. Parsers abort early, tools fail to load, and the CLI proceeds as if nothing is wrong. You only discover the failure when a core feature is missing.
• Zero cross-validation. Nothing verifies whether referenced binary paths exist, whether target ports are available, or whether executable permissions are set. Failures occur only at runtime.
• Cross-machine drift. A configuration working on your laptop breaks on a colleague's machine. Absolute paths, binary versions, and home directory structures diverge without automated validation.

Configuration versus real-time control

Consider an electrical breaker box. Manual configuration is like rewiring individual connections behind drywall and hoping the lights turn on. Visual control is like an accessible breaker panel: you inspect live status, know which circuits are energized, and toggle switches without cutting open walls.

You do not need prettier JSON files. You need a unified control plane to inspect and adjust system state without touching raw text.

The Advantage: ACS Cockpit Dashboard at Port 20130

ACS Core consolidates configuration management into a local dashboard. This is not an arbitrary JSON editor. It is an operational cockpit that reads and writes unified configuration state from a single binary.

Key capabilities managed through the dashboard:

• Four official model tiers. Opus and Fable for deep architectural reasoning, Sonnet and Haiku for high-speed execution. Tiers can be configured globally or per-workspace, with live visibility into active session assignments.
• Credential isolation. API tokens and secrets are stored in a dedicated vault outside project repositories, preventing accidental git commits.
• Hook and tool profiles. Enable, disable, or swap enforcement hooks without manually editing settings.json.
• MCP server telemetry. Monitor active servers, port bindings, and transport types. If a stdio connection drops, you detect it before your agent loses tool access.
• Session and memory state. Inspect active memory nodes, running CLI sessions, and package-level resource locks.

The dashboard runs locally at http://127.0.0.1:20130 and is served directly by the standalone Go binary. There are no separate Node processes to manage and no external dependencies to keep alive.

# Launch the local visual dashboard
acs dashboard

# Inspect system health directly from the terminal
acs doctor

The dashboard and CLI work interchangeably. Both interact with the same underlying state. You can toggle options in the browser or use terminal commands with identical results.

Why port 20130 serves as the fallback

Port 20130 is not an arbitrary assignment. It functions as the final REST fallback within the four-tier ACS runtime hierarchy:

1. Tier 1, in-process stdio RPC. The primary runtime for agent tool calls, executing in under 2 milliseconds without network overhead.
2. Tier 2, CLI fastpath. Fast binary subcommands for routine terminal tasks.
3. Tier 3, direct database queries. In-process SQLite WAL reads that do not require an active server daemon.
4. Tier 4, local REST fallback at :20130. Reserved strictly for environments where stdio transport is unsupported.

This hierarchy is strictly maintained. The REST interface serves as an emergency circuit breaker. While stdio is healthy, routing requests over HTTP is treated as an architectural violation.

The port is never hardcoded in application logic. It reads from runtime environment variables to prevent collisions across dev, staging, and production tiers.

Configuration Governance and Migration Blueprint

Here are the tier-mapping guidelines, drift-detection mechanisms, and migration steps we employ when transitioning projects to dashboard governance.

Tier Allocation and Validation Blueprint for json config

When the Dashboard Is Unnecessary

If your workflow involves a single editor, a single repository, and static configurations that rarely change, a local dashboard adds unnecessary overhead. A basic local configuration file is entirely adequate.

However, if you operate multiple CLI agents across several concurrent projects, manual JSON editing quickly creates technical debt. In multi-agent environments, a visual dashboard is the most reliable way to monitor system health without digging through configuration files.

To explore how visual controls integrate with our broader architecture, review the ACS features overview. To review license tiers and activation options, visit the pricing page. Review the official JSON data interchange standard in RFC 8259 JSON Specification ↗.