OpenCode and Unleash: model-neutral feature flag governance for open source teams

OpenCode gives developers a choice that most AI coding tools do not: which model writes the code. One developer on your team might use Claude for a complex refactor. Another uses GPT for a quick fix. A third runs a local Llama model via Ollama because the code touches sensitive customer data that cannot leave the network. All three work in the same codebase, using the same terminal-first agent.

That flexibility is OpenCode’s defining characteristic. With 160,000+ GitHub stars and support for 75+ LLM providers through Models.dev, it has become one of the most popular open-source AI coding agents. But model neutrality creates a governance problem that single-vendor tools do not face.

When the model changes between sessions, or between developers, each model may produce different patterns for the same operation. Ask three different models to create a feature flag and you might get enable_stripe, stripe-payment-integration, and new_payment_flow. Ask them to wrap code behind a flag and you will get three different import patterns, three different conditional structures, three slightly different approaches.

Governance cannot live in the model when the model changes. It has to live in the tools.

The model-neutral governance gap

The DORA State of AI-Assisted Software Development report found that delivery stability tends to decrease as AI usage increases. That finding is about AI coding in general. For teams running multiple models, the risk compounds.

Single-model tools like Claude Code or Cursor have a narrower problem: one model, one set of behaviors to understand and constrain. OpenCode’s model neutrality widens the surface area. A flag created with Claude’s help might follow kebab-case naming. The same operation with GPT might produce camelCase. A local model might skip the flag entirely because it was not trained on your team’s conventions.

Feature flags are supposed to reduce risk. Inconsistent flags, created by different models, across different repos, by different developers, create their own problems: duplicate toggles, naming drift, flags that nobody remembers to clean up.

In June 2025, a missing feature flag caused a global Google Cloud outage lasting over three hours. Google’s postmortem was blunt: if the configuration change had been flag-protected, recovery would have taken seconds. Google has world-class infrastructure engineering. They still got burned by a change that shipped without a flag.

When AI agents are making changes at machine speed, and the model behind the agent might be different from one session to the next, the margin for error shrinks further.

Governance through MCP: a model-independent layer

We built the Unleash MCP server to solve this problem. MCP (Model Context Protocol) is an open standard that lets AI assistants interact with external tools. The Unleash MCP server exposes feature flag management capabilities directly to the agent. The model generates the prompt. The MCP server enforces the behavior.

This distinction matters for OpenCode specifically. Because the MCP server sits below the model layer, it works identically whether the developer selected Claude, GPT, Gemini, Grok, or a self-hosted model. The governance layer is model-independent by design.

When the server is configured, the agent gains access to tools that enforce your FeatureOps practices:

evaluate_change analyzes a code change and determines whether it needs a feature flag. The tool considers the type of modification, the files involved, and the risk level. A documentation update probably does not need a flag. A payment integration almost certainly does.

detect_flag checks whether a suitable flag already exists in Unleash. This prevents duplication. If your team already has a flag for payment processing, the agent will suggest reusing it rather than creating a new one.

create_flag generates a new feature flag with proper naming, typing, and documentation. The MCP server enforces your team’s conventions regardless of which model is doing the reasoning.

wrap_change produces framework-specific code that guards the new feature behind the flag. Whether you work in React, Django, Go, Spring Boot, or any of the languages Unleash supports, the wrapping code follows patterns already in your codebase.

list_projects and list_flags provide inventory capabilities. The agent can enumerate available projects and retrieve active or archived flags, making audits and duplicate detection possible before creating anything new. This is especially valuable in model-neutral environments where developers switching models between sessions may lose context about which flags already exist.

Supporting tools handle the rest of the lifecycle: set_flag_rollout configures rollout strategies, get_flag_state retrieves flag metadata, toggle_flag_environment controls per-environment activation, remove_flag_strategy cleans up strategies, and cleanup_flag guides safe removal of stale flags. Feature flags are temporary by design. The Unleash MCP server treats the full lifecycle, from creation to cleanup, as part of the workflow.

Custom agents: governance encoded in the tool, not the model

OpenCode’s governance story goes deeper than MCP tools. Custom agents with fine-grained permission controls are the primary mechanism for encoding policies.

An agent in OpenCode is more than a prompt template. Each agent has a mode (primary or subagent), an optional model override, a system prompt, and a permission model that supports three levels per tool: ask (prompt for approval), allow (execute without prompting), and deny (block entirely). Permissions cover read, edit, bash, and more, with pattern matching for fine-grained bash control.

A FeatureOps agent might look like this: the system prompt instructs the agent to always call evaluate_change before implementing risky changes. The permission model sets “edit”: “ask” so every file change requires approval, and “bash”: { “*”: “deny”, “npm test*”: “allow” } to block destructive commands while allowing tests.

This agent works the same whether the developer selects Claude, GPT, or a local model. The model provides the reasoning. The agent definition provides the guardrails. The MCP server provides the tools. Three independent layers, none of which depends on a specific model’s behavior.

Five built-in agents ship with OpenCode. Build (default, full access), Plan (restricted to analysis), General (multi-step research), Explore (read-only codebase exploration), and Scout (read-only external research). Teams can define custom agents in opencode.json or as markdown files in .opencode/agents/, committed to version control so the entire team shares the same governance definitions.

Skills, commands, and AGENTS.md

Custom agents are the governance mechanism. Skills, commands, and AGENTS.md are the distribution mechanism.

Skills are reusable workflows defined as SKILL.md files in .opencode/skills/. An evaluate-and-flag skill walks the agent through the complete workflow: evaluate the change, check for duplicates, create the flag if needed, wrap the code, suggest a rollout strategy. The agent can invoke skills automatically when the context is relevant. Skills ensure that every developer on the team follows the same workflow, regardless of their experience with FeatureOps.

Custom commands are prompt templates invoked via /command-name in the TUI. /evaluate-flag Stripe payment integration expands into a structured prompt that guides the agent through evaluation and flag creation. Commands lower the barrier to following best practices.

AGENTS.md is the project instructions file, loaded into every session automatically. It encodes your team’s naming conventions, flag types, domain-specific policies, and references to the MCP server. OpenCode also reads from CLAUDE.md for teams migrating from Claude Code. Additional instruction files can be loaded via glob patterns or remote URLs through the instructions field in opencode.json.

All of these live in the .opencode/ directory at the project root. Commit it to version control and every developer gets the same agents, skills, commands, and policies. No marketplace required. No vendor lock-in. Just files in a repository.

What this looks like in practice

A developer opens OpenCode’s TUI and switches to the FeatureOps agent. They describe their change: “I’m adding Stripe payment processing.”

The agent’s system prompt instructs it to evaluate risk first. It calls evaluate_change. The Unleash MCP server confirms the change is high-risk and suggests the name payments-stripe-integration. The agent calls detect_flag to check for duplicates. None found. It calls create_flag. Because the agent’s permission for edit operations is set to “ask“, the developer approves the flag creation.

The agent implements the integration and wraps the code:

if (unleash.isEnabled('payments-stripe-integration', context)) {
  return stripeService.processPayment(request);
} else {
  return legacyPaymentService.process(request);
}

The flag exists in Unleash, disabled by default. The team tests in staging, rolls out gradually, and disables instantly if issues arise.

Two weeks later, a different developer runs /flag-audit from the TUI. The command invokes list_projects and list_flags to inventory all flags, cross-references them against the codebase, and identifies payments-stripe-integration as a cleanup candidate: 100% rollout, stable for 14 days, no incidents. They run the cleanup-flag skill to remove the conditional code safely.

The entire workflow was consistent. The first developer used Claude. The second used GPT. The model did not matter. The governance did.

The full release picture

Creating flags is the beginning. Unleash provides the infrastructure for the entire release lifecycle.

Rollout strategies let you target specific users, regions, or percentages of traffic. Start with internal users, expand to beta testers, then gradually increase to 100%. Release templates define reusable rollout patterns with automatic pauses if error rates spike.

Impact Metrics collect production signals directly from your application. Request rates, error counts, latency percentiles. These metrics tie directly to feature flags, so you can see exactly how a new feature affects your system. Automated progression advances the rollout when metrics are healthy and pauses when they are not.

Two open source projects, one governance stack

There is something fitting about combining OpenCode and Unleash. Both are open-source projects with strong communities and commercial offerings built on top.

OpenCode is free to use with any provider’s API key. Unleash’s open-source tier provides feature flag infrastructure at no cost. Together, they create a governance stack for AI-assisted development that is entirely vendor-neutral: choose your model, choose your feature flag platform, commit your governance definitions to version control.

For organizations that need more, both projects offer commercial tiers. OpenCode Enterprise adds SSO, private AI gateways, and managed configuration. Unleash provides advanced rollout strategies, impact metrics, change requests, and enterprise-grade infrastructure. The open-source foundation means you are never locked in.

Getting started

Adding the Unleash MCP server to OpenCode takes one configuration file. Create opencode.json at your project root:

{
  "mcp": {
    "unleash": {
      "type": "local",
      "command": ["npx", "-y", "@unleash/mcp@latest", "--log-level", "error"],
      "environment": {
        "UNLEASH_BASE_URL": "{env:UNLEASH_BASE_URL}",
        "UNLEASH_PAT": "{env:UNLEASH_PAT}",
        "UNLEASH_DEFAULT_PROJECT": "{env:UNLEASH_DEFAULT_PROJECT}"
      }
    }
  }
}

Commit this file to version control. Credentials come from environment variables via {env:VAR} substitution, keeping secrets out of the repository. The same configuration works across OpenCode’s TUI, CLI (opencode run), and desktop app.

The Unleash MCP server also works with Claude Code, Cursor, GitHub Copilot, and Kiro. The OpenCode integration adds custom agents, skills, and commands on top, but the underlying MCP server is shared across all platforms.

For the full setup guide, including agent definitions, skill templates, and CLI workflows, see our OpenCode integration documentation.

Governance that works across any model

The pattern across the industry is clear: AI-assisted development is accelerating code production but not the governance practices that keep software stable. Feature flags are the control layer. But the governance cannot live in the model when the model changes between sessions.

OpenCode’s custom agents encode policies at the tool level. The Unleash MCP server enforces FeatureOps practices below the model layer. Together, they create a governance stack that is model-neutral, open-source, and distributed through version control.

The result is a workflow where AI writes the code, governance is enforced by the tools, and releases are safe by default. Not because developers remember to follow the rules, but because the rules are built into the agent they already use. Regardless of which model powers it.