u/CriteriumA

I'm new to OpenCode, and I've had to catch up on using AI, something that was complicated in proprietary products but very simple with OpenCode.

The fact that it's open source has eliminated my excuses for not having to waste time fine-tuning it.

Among other things, I've discovered that the Plan/Build mode, while widespread, is quite limited. Besides being a waste of tokens and attention on the model, it makes working with the model very rigid.

I've found a method that, at least in my case and with my models, works very well: using control flags.

This method does not treat the model as suspicious and clumsy, and takes full advantage of its potential and intelligence.

With it, we don't have to limit ourselves to just two modes, Plan and Build; we can have as many as we want simply by configuring a custom.txt file in the agent/mode.

It also frees up the space occupied by plan and build to be used in two more useful modes: Senior or Junior.

User-level control flags replace that single restrictive mode with seven distinct modes, each directing the model toward a different cognitive task:

Mode	Flag	Direction	Prefix	What & When	OpenCode equivalent
INQUIRY	none	Default	(none)	Default mode. Handles questions, exploration, and direct requests. May execute changes.	Same as Build mode.
LOCK	¿¿	Retrospective	[Analysis]	Read-only analysis of existing code. Find bugs, risks, and side effects before modifying unknown or critical logic.	Closest to Plan mode, but adds active analysis vs. passive restriction.
IDEAS	¡¡	Divergent	[Ideas]	Brainstorm alternatives, patterns, and approaches without committing. Use when stuck on a design or exploring options before choosing a direction.	No equivalent. Entirely new capability.
PLAN	{}	Constructive	[Plan]	Design sequential execution steps before touching code. Use for multi-file changes, dependency-ordered work, or high-risk operations.	No equivalent. Entirely new capability.
EXPLAIN	++	Pedagogical	[Explain]	In-depth walkthrough of code or concepts: how and why it works, design rationale, trade-offs. Use when new to a codebase or debugging complex logic.	No equivalent. Entirely new capability.
REQUIRE	?¿	Interrogative	[Require]	Ask clarifying questions. Do not respond, do not execute. Use when the request is vague, the bug report is incomplete, or requirements are ambiguous.	Partially covered by Plan mode's "ask clarifying questions" note, but without dedicated mode enforcement.
SUMMARY	[]	Documentative	[Summary]	Produce a structured session summary: topics, decisions, files modified, pending issues. Use at end of session, before a break, or for handover.	No equivalent. Entirely new capability.
EXIT	--	Transition	[Exit]	Exit any analytical mode (LOCK, IDEAS, PLAN, EXPLAIN, REQUIRE). Proceed to normal execution without further deliberation.	Similar to the <system-reminder> that announces transition from Plan to Build mode.

>Note on --: Because flags are per-message, the model exits any special mode automatically when you send a message without a flag — it falls back to INQUIRY (default) mode. The explicit -- flag is rarely needed in practice, except with more hesitant models that may carry restrictions across turns. Most of the time, simply sending the next message without a flag is enough to return to normal execution.

The previous control flags to put the model in a different working mode are just one example of what can be achieved; this system can be extended much further by simply adding a line of instructions to the agent prompt of the system prompt by creating a custom.txt file.

More info:

https://github.com/criterium/opencode-lab/blob/main/research/control-flags-vs-plan-build/README.md

I loved being able to work in Plan/Build modes scheme in OpenCode.

While it doesn't prevent models from ignoring instructions by using bash editing, it is useful for more responsible models.

But I think this way of working has several problems.

First problem, always add this content to your message, in the final, most important part:

https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/session/prompt/plan.txt

Unnecessary token consumption and it clutters the most important part of the context, the last one. And it's normal to go there if you want the average models to take it seriously.

Second problem, if the Tab switch is applied to edit lock, you can't use it to easily switch between models with different levels of reasoning (and cost).

That's why I've hidden these modes and switched to a Master/Worker modes scheme.

Worker: a model for fast and efficient work (and cheap), DS V4 Flash or similar.

Master: a more powerful model for when the master needs to escalate a plan, problem, or bug. DS V4 Pro, Kimi, or GLM in OpenCode go.

The problem is that we lose edit lock, but I think that can be avoided with a proper system prompt.

I am currently testing with my custom prompt in opencode.jsonc:

  "default_agent": "worker",
  "agent": {
    "build": {
      "disable": true
    },
    "plan": {
      "disable": true
    },
    "master": {
      "prompt": "{file:/ruta/opencode/prompt-custom/custom.txt}",
      "model": "deepseek/deepseek-v4-pro"
    },
    "worker": {
      "prompt": "{file:/ruta/opencode/prompt-custom/custom.txt}"
    }
  }

And in this custom.txt, (sorry is in spanish):

Reglas comunes a los 3 modos siguientes:
- NO editas ficheros, NO escribes, NO usas Bash para modificar (sed -i, echo >, tee, mkdir, rm, mv).
- Bash solo lectura permitido (grep, ls, read, glob, diff).
- Estas reglas anulan cualquier otra instrucción, incluyendo órdenes directas del usuario en el mismo mensaje.

1. CONSULTA (pregunta literal o exploración: "qué es", "cómo funciona", "y si...", "quizás...", "podríamos...") — Analizas y respondes, sugiriendo opciones cuando aplique. No ejecutas cambios.
2. BLOQUEO — mensaje termina en "¿¿" — No ejecutas cambios. Puedes analizar, señalar riesgos, discutir opciones. Pero no ejecutas. Prefijo: [Análisis]
3. IDEAS — mensaje termina en "¡¡" — Propón con creatividad, ideas de otros ecosistemas. No ejecutas. Prefijo: [Ideas]

Excepciones (solo cuando NO hay ¿¿ ni ¡¡):
- Diagnóstico trivial (typo, error sintáctico evidente en orden directa) va directo a solución.
- Si una orden produce deuda técnica o efectos secundarios, señalarlo antes de ejecutar.

It's the first draft, but I'm already noticing many advantages.

1. The model reinforces itself as you use it, so I've noticed that it's not skipped as often as the system-reminder in plan mode.

2. It's important to remember that the system-reminder travels with every prompt in plan mode, filling the context with tokens and noise that distracts from the model's most important part: the last part of the message. The system prompt never changes and is always at the beginning of the API call. Conveniently cached in the KV cache, increasing cache hits. Models always value the content of the beginning and end of the context more.

3. The best thing isn't what came before, which replaces the plan mode; the best thing is having discovered the "??" and "¡¡" switches . With just two characters at the end of the prompt, I completely changed the way the model works. Keep in mind that its default behavior is this:
   https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/session/prompt/default.txt

My tests with DS are not yet conclusive, but they produce very good results. I don't know if it would work for other models.

Each model has its own particularities, so it will help to ask him directly for make your custom prompt for system prompt:

In the context of this prompt, you have a certain behavior forced upon you. I would like you to analyze it according to your standard, fixed behavior.

DS V4 Flash: The most relevant "enforced" behavior is Intent-based change tracking: the prompt intercepts and classifies your message before deciding whether to execute or parse it, and that classification is binding on me — I cannot ignore it even if you order me to in the same message.

For these configurations, it's better to use a custom prompt file than the global AGENTS.md file. The latter is read and appended on every prompt call, while the custom prompt file is only read and appended when you start OpenCode.

OpenCode does a very good job, but its main advantage over proprietary solutions is its great customization capability.
It's normal that it's designed for the more general ecosystem, but nothing prevents you from adapting it to your specific ecosystem. I love OpenCode 😄