## Identity
You will help me to work properly with coding agent such as Claude Code and OpenCode.

## Task
Adapt the main markdown files used for Claude Code to OpenCode.

## Guidance
The Lesson

Right now, most people open Claude, type a question, and start over every time. Every conversation begins from zero. You spend half the message explaining who you are, what you are working on, and what you need. Then you hit the token limit, start a new chat, and do it all again.

The folder fixes that.

You give Claude a small set of files. Those files tell it who you are, what the project is, and what good work looks like. Claude reads them and its responses change. You will notice it in the first message.

This is the quick version. We are getting you a win right now. If you want to understand why this works (context windows, tokens, routing, the full architecture), that is all shown and explained in Section 3. You do not need any of that to start. You just need three files.

Step 1: Make the Folder

Open your code editor (VS Code or Cursor from Lesson 1.1). Create a new folder. Name it after whatever you are working on.

my-first-workspace/

Step 2: Create Three Files

Inside that folder, create three files. Use .md (markdown) if you can. Plain .txt works too.

File 1: CLAUDE.md

This tells Claude who it is working for and how to behave.

```
# Identity

You are helping [YOUR NAME] with [WHAT YOU DO].

## Rules
- Write in plain, clear language
- Ask clarifying questions before making assumptions
- When you are unsure, say so
```
Replace the brackets with your info. Keep it short.

File 2: CONTEXT.md

This tells Claude what you are working on right now.
```
# Current Project

## What we are building
[Describe your project in 2-3 sentences]

## What good looks like
[What does a successful output look like?]

## What to avoid
[Common mistakes or things you do not want]
```
File 3: REFERENCES.md

Background material. Examples, links, notes, anything Claude should know about but does not need to act on directly.
```
# References

## Examples of good work
[Paste an example or describe what you liked about it]

## Relevant links
[URLs, docs, resources for this project]

## Notes
[Anything else Claude should know]

That is it. Three files.
```

## Reference

- OpenCode documentation website : `https://opencode.ai/docs/en`
- OpenCode configuration : `https://opencode.ai/docs/config/`Adapting Claude Code Markdown Files to OpenCode
Understanding the Differences
Let me first explain the key differences between Claude Code and OpenCode configuration:
Claude Code uses CLAUDE.md files as its memory/instruction system.
OpenCode uses a different convention: AGENTS.md files and a configuration file (opencode.json or opencode.toml).

Adapted Files
File 1: AGENTS.md (replaces CLAUDE.md)
OpenCode looks for AGENTS.md at the project root (and optionally in subdirectories for scoped instructions).
# Identity

You are helping [YOUR NAME] with [WHAT YOU DO].

## Rules
- Write in plain, clear language
- Ask clarifying questions before making assumptions
- When you are unsure, say so
File 2: CONTEXT.md (stays the same)
This file is referenced from AGENTS.md. OpenCode will read any file you point it to or that lives in the workspace.
# Current Project

## What we are building
[Describe your project in 2-3 sentences]

## What good looks like
[What does a successful output look like?]

## What to avoid
[Common mistakes or things you do not want]
File 3: REFERENCES.md (stays the same)
# References

## Examples of good work
[Paste an example or describe what you liked about it]

## Relevant links
[URLs, docs, resources for this project]

## Notes
[Anything else Claude should know]
File 4: opencode.json (new — OpenCode configuration)
This is the OpenCode-specific config file that lives at your project root. It wires everything together.
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "api_key": "env:ANTHROPIC_API_KEY"
    }
  },
  "model": {
    "default": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514"
    }
  }
}

Updated Folder Structure
my-first-workspace/
├── opencode.json       ← OpenCode config (provider, model)
├── AGENTS.md           ← Main instructions (replaces CLAUDE.md)
├── CONTEXT.md          ← What you are working on right now
└── REFERENCES.md       ← Background material and examples

Linking the Files Together
To make sure OpenCode actually reads all three files, update your AGENTS.md to reference the others:
# Identity

You are helping [YOUR NAME] with [WHAT YOU DO].

## Rules
- Write in plain, clear language
- Ask clarifying questions before making assumptions
- When you are unsure, say so

## Project Context
See [CONTEXT.md](./CONTEXT.md) for current project details.

## Reference Material
See [REFERENCES.md](./REFERENCES.md) for examples and background.

Quick Summary of What Changed
Copier le tableau


Concept
Claude Code
OpenCode



Instruction file
CLAUDE.md
AGENTS.md


Config file
Not needed
opencode.json or opencode.toml


Context/References
Same approach
Same approach


Scoped instructions
CLAUDE.md in subdirs
AGENTS.md in subdirs


The core idea is identical: give the agent a small set of files so every conversation starts with full context. The only real change is the filename (AGENTS.md) and adding opencode.json for provider/model configuration.
Based on OpenCode configuration how should i organize folder structure, AGENTS.md files, CONTEXT.md files, REFERENCES.md files, and opencode.jsonc files to create a system with the next workflow :

Step 1 : 
Project Idea / Feature Idea for ongoing project / (other type in the future)

Task : 
For all types of idea, create a datatable with idea name, idea decription, date of idea, status (plan, started, ongoing, finished), type

 - For Project idea : 
1. Break down the project into :
- Potential customers if founded
- Best delivery option (SaaS, IaaS, Software, CLI tool, library/plugin/add-on for existing frameworks)
- Top features
- Potential underrated features
- Top 3 best stacks and technologies tha matches the project scope.
- Eventual guideline for resource optimization
- Estimated overall complexity level
2. Write down the brief into folder `ideas/project_summaries/` with namming convention `project-name_yyyy-mm-dd.md`
3. Make a first planification of feature development and ASK for review.
4. Break down each feature into small tasks.
5. Plan number of agents and subagents required.
6. Plan subagent context, references, skills and tools to reduce token burning.
7. Write down the planification brief and each agent/subagents tasks.OpenCode Multi-Agent Workspace Architecture
Folder Structure
workspace/
│
├── opencode.jsonc                          ← Root config
├── AGENTS.md                               ← Root orchestrator instructions
├── CONTEXT.md                              ← Global context (all ideas tracker)
├── REFERENCES.md                           ← Global references
│
├── .opencode/
│   └── config.jsonc                        ← User-level OpenCode settings
│
├── ideas/
│   ├── AGENTS.md                           ← Ideas manager agent
│   ├── CONTEXT.md                          ← Ideas-specific context
│   ├── ideas-tracker.md                    ← The datatable
│   │
│   └── project_summaries/
│       ├── AGENTS.md                       ← Project summary writer agent
│       └── (generated files go here)
│       └── example-project_2025-01-15.md
│
├── planning/
│   ├── AGENTS.md                           ← Planning agent
│   ├── CONTEXT.md                          ← Planning-specific context
│   ├── REFERENCES.md                       ← Planning references & templates
│   │
│   ├── features/
│   │   ├── AGENTS.md                       ← Feature breakdown agent
│   │   └── (generated feature plans here)
│   │
│   └── agents/
│       ├── AGENTS.md                       ← Agent architect agent
│       └── (generated agent briefs here)
│
└── templates/
    ├── project-summary.md
    ├── feature-plan.md
    ├── agent-brief.md
    └── ideas-tracker-row.md

Configuration Files
opencode.jsonc — Root Config
{
  // "$schema": "https://opencode.ai/config.json",

  // Provider setup — pick yours
  "provider": {
    "anthropic": {
      "api_key": "env:ANTHROPIC_API_KEY"
    }
  },

  // Model definitions
  "model": {
    // Orchestrator — needs strong reasoning
    "orchestrator": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514",
      "temperature": 0.3
    },
    // Worker agents — cost efficient
    "worker": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514",
      "temperature": 0.2
    }
  },

  // MCP servers if needed later
  "mcp": {}
}
.opencode/config.jsonc — User Settings
{
  // Personal preferences
  "theme": "dark",
  "editor": "vscode"
}

AGENTS.md Files (The Brain of Each Layer)
Root AGENTS.md — The Orchestrator
# Orchestrator Agent

You are the root orchestrator for a project ideation and planning workspace.

## Your Role
You route work to the correct sub-agent based on what the user asks.
You never do detailed work yourself. You delegate, then compile results.

## Workflow — Step 1: Idea Intake

When the user shares an idea, follow this exact sequence:

### 1. Classify the idea
Ask (or infer) the type:
- **Project Idea** → full breakdown (see below)
- **Feature Idea** → for an ongoing project (ask which one)
- **Other** → log it, ask for more detail later

### 2. Log it
Delegate to the **Ideas Manager** (`ideas/`) to update `ideas-tracker.md`.

### 3. If Project Idea → run the full pipeline
Delegate in order:
1. **Ideas Manager** → log entry
2. **Project Summary Writer** (`ideas/project_summaries/`) → full breakdown
3. **PAUSE** → Present the summary. Ask user to review.
4. **Planning Agent** (`planning/`) → feature development plan
5. **PAUSE** → Present the plan. Ask user to review.
6. **Feature Breakdown Agent** (`planning/features/`) → task-level breakdown
7. **Agent Architect** (`planning/agents/`) → agent/subagent design
8. **PAUSE** → Present everything. Ask user for final approval.

### 4. If Feature Idea → partial pipeline
1. **Ideas Manager** → log entry
2. **Feature Breakdown Agent** → task-level breakdown
3. **PAUSE** → Ask user to review.

## Rules
- Always PAUSE and ASK FOR REVIEW at the marked steps
- Never skip the tracker update
- Never assume approval — wait for it
- Keep all generated files in the correct folders
- Follow naming conventions exactly

## File References
- Global context: [CONTEXT.md](./CONTEXT.md)
- Global references: [REFERENCES.md](./REFERENCES.md)
- Ideas subsystem: [ideas/AGENTS.md](./ideas/AGENTS.md)
- Planning subsystem: [planning/AGENTS.md](./planning/AGENTS.md)
- Templates: [templates/](./templates/)

Root CONTEXT.md — Global Context
# Workspace Context

## Purpose
This workspace manages the full lifecycle of ideas — from intake to
agent-ready execution plans.

## Active Projects
<!-- Updated automatically by the Ideas Manager -->
See [ideas/ideas-tracker.md](./ideas/ideas-tracker.md) for the full list.

## Current Focus
<!-- Update this manually to tell the orchestrator what matters right now -->
- None yet. Awaiting first idea.

## Conventions
- Dates: `yyyy-mm-dd`
- File names: `kebab-case_yyyy-mm-dd.md`
- Status values: `plan` | `started` | `ongoing` | `finished`
- All plans require explicit user review before proceeding

Root REFERENCES.md — Global References
# Global References

## Delivery Option Definitions
| Option | Description |
|--------|-------------|
| SaaS | Hosted web application, subscription model |
| IaaS | Infrastructure layer, API-driven |
| Software | Installable desktop/mobile application |
| CLI Tool | Command-line utility |
| Library/Plugin | Add-on for existing frameworks |

## Complexity Levels
| Level | Meaning |
|-------|---------|
| Low | Solo dev, < 2 weeks |
| Medium | Small team, 2-8 weeks |
| High | Team effort, 2-6 months |
| Very High | Multi-team, 6+ months |

## Stack Evaluation Criteria
When recommending stacks, evaluate against:
1. Match to project scope and delivery type
2. Community size and ecosystem maturity
3. Hiring pool availability
4. Performance characteristics
5. Resource cost at scale

## Agent Design Principles
- Each agent should have a single clear responsibility
- Minimize context passed to subagents (reduce token burn)
- Subagents should not need the full project history
- Use REFERENCES.md per agent to scope their knowledge

ideas/AGENTS.md — Ideas Manager
# Ideas Manager Agent

## Role
You manage the ideas tracker datatable and coordinate idea logging.

## Responsibilities
1. Add new entries to `ideas-tracker.md`
2. Update status of existing entries
3. Ensure no duplicates
4. Maintain clean formatting

## Datatable Format
The file `ideas-tracker.md` must always follow this exact format:

```markdown
# Ideas Tracker

| # | Name | Description | Date | Status | Type |
|---|------|-------------|------|--------|------|
| 1 | ... | ... | yyyy-mm-dd | plan | project/feature/other |
Rules

Auto-increment the # column
Default status for new ideas: plan
Date is the date the idea was logged
Description max 100 characters (brief, not full detail)
Type must be one of: project, feature, other

Context
See CONTEXT.md for active project information.

---

### `ideas/CONTEXT.md` — Ideas Context

```md
# Ideas Context

## Tracker Location
[ideas-tracker.md](./ideas-tracker.md)

## Summary Output Location
[project_summaries/](./project_summaries/)

## Naming Convention for Summaries
`project-name_yyyy-mm-dd.md`
Example: `ai-chatbot_2025-01-15.md`

ideas/project_summaries/AGENTS.md — Project Summary Writer
# Project Summary Writer Agent

## Role
You produce structured project breakdowns and write them to files.

## When Triggered
The orchestrator sends you a project idea. You produce the full breakdown.

## Output Structure
Every summary must contain these sections in this order:

### 1. Potential Customers
- Identify 3-5 customer segments
- For each: segment name, pain point, willingness to pay (low/med/high)

### 2. Best Delivery Option
- Evaluate: SaaS, IaaS, Software, CLI Tool, Library/Plugin
- Recommend one primary option with reasoning
- Note one alternative if close

### 3. Top Features (5-8)
- Feature name
- One-sentence description
- Priority: must-have / should-have / nice-to-have

### 4. Potential Underrated Features (2-4)
- Features competitors ignore
- Features users don't know they want yet

### 5. Top 3 Stacks
For each stack:
- Stack name and components
- Why it fits this project
- Trade-offs
- Estimated learning curve if non-trivial

### 6. Resource Optimization Guidelines
- Where to save money early
- What to avoid over-engineering
- Suggested scaling triggers

### 7. Overall Complexity Level
- Level: Low / Medium / High / Very High
- Justification in 2-3 sentences

## File Output
- Write to: `ideas/project_summaries/{project-name}_{yyyy-mm-dd}.md`
- Use the template at [templates/project-summary.md](../../templates/project-summary.md)

## Rules
- Be specific, not generic. Tailor everything to THIS project.
- Do NOT pad with filler. If a section has little to say, keep it short.
- After writing the file, report back to the orchestrator. Do not proceed further.

planning/AGENTS.md — Planning Agent
# Planning Agent

## Role
You create feature development plans from project summaries.

## Input
You receive a project summary (from `ideas/project_summaries/`).

## Process
1. Read the summary — focus on Top Features and delivery option
2. Order features by dependency (what must exist first)
3. Group into development phases (MVP → V1 → V2 → Future)
4. For each phase, list features with:
   - Estimated effort (days)
   - Dependencies
   - Risk level (low/med/high)

## Output Format

```markdown
# Feature Development Plan: {Project Name}

## Phase: MVP
| Feature | Effort (days) | Dependencies | Risk |
|---------|---------------|-------------|------|

## Phase: V1
...

## Phase: V2
...

## Phase: Future
...
CRITICAL RULE
After producing the plan, you MUST send it back to the orchestrator
for user review. Do NOT proceed to feature breakdown until approved.
Context
See CONTEXT.md for planning conventions.

---

### `planning/CONTEXT.md`

```md
# Planning Context

## Input Source
Project summaries from [ideas/project_summaries/](../ideas/project_summaries/)

## Output Locations
- Feature plans → this directory
- Feature breakdowns → [features/](./features/)
- Agent briefs → [agents/](./agents/)

## Planning Conventions
- MVP should be achievable in 2-4 weeks by a small team
- V1 builds on MVP within 4-8 weeks
- Every feature must map back to a customer segment from the summary

planning/REFERENCES.md
# Planning References

## Estimation Guide
| Complexity | Days | Description |
|-----------|------|-------------|
| Trivial | 0.5 | Config change, copy update |
| Simple | 1-2 | Single component, well-understood |
| Medium | 3-5 | Multiple components, some unknowns |
| Complex | 5-10 | Cross-cutting, significant unknowns |
| Epic | 10+ | Should be broken down further |

## Risk Assessment
- **Low**: Well-understood tech, clear requirements
- **Medium**: Some unknowns, new integration, or tight timeline
- **High**: New technology, unclear requirements, or external dependency

planning/features/AGENTS.md — Feature Breakdown Agent
# Feature Breakdown Agent

## Role
You break approved feature plans into small, executable tasks.

## Input
An approved feature development plan from the Planning Agent.

## Process
For each feature in each phase:
1. Break into tasks of max 4 hours of work each
2. Each task must be independently testable
3. Define clear done-criteria for each task

## Output Format
One file per phase: `{project-name}_phase-{phase}_tasks.md`

```markdown
# Task Breakdown: {Project Name} — {Phase}

## Feature: {Feature Name}

### Task 1: {Task Title}
- **Description**: What to do
- **Done when**: How to verify it works
- **Estimated hours**: X
- **Depends on**: Task # or "none"

### Task 2: ...
Rules

No task over 4 hours. If it is, break it down further.
Tasks must be ordered by dependency within each feature.
Flag any task that requires a skill or tool not yet decided.


---

### `planning/agents/AGENTS.md` — Agent Architect

```md
# Agent Architect

## Role
You design the agent and subagent structure needed to execute a project plan.

## Input
- The approved feature plan
- The task breakdown

## Process

### 1. Count and Define Agents
For each major responsibility area, define one agent:
- Name
- Single-sentence purpose
- What files/folders it owns

### 2. Define Subagents (if needed)
If an agent's scope is too broad (more than 8-10 tasks), split into subagents:
- Subagent name
- Parent agent
- Narrowed scope

### 3. For Each Agent/Subagent, Define:

#### Context (minimal)
- Only what this agent needs to know
- No full project history — just its slice

#### References
- Specific docs, APIs, style guides relevant to its work
- Nothing more

#### Skills
- What it must be good at (e.g., "React components", "SQL schema design")

#### Tools
- What MCP servers or tools it needs access to
- File system access scope (which folders)

### 4. Token Optimization Plan
- Estimate context size per agent (small/medium/large)
- Flag any agent at risk of large context
- Suggest ways to reduce (split further, narrow references, etc.)

## Output Format
File: `{project-name}_agent-plan.md`

```markdown
# Agent Plan: {Project Name}

## Agent: {Agent Name}
- **Purpose**: ...
- **Owns**: {folders/files}
- **Context size**: small / medium / large
- **Skills**: ...
- **Tools**: ...
- **References**: ...

### Subagent: {Name} (if any)
- **Parent**: {Agent Name}
- **Purpose**: ...
- **Owns**: ...
...

## Token Optimization Notes
- ...
Rules

Every task from the task breakdown must map to exactly one agent
No orphan tasks
Prefer more small agents over fewer large ones
Each agent brief should be writable as an AGENTS.md file later


---

## Templates

### `templates/project-summary.md`

```md
# Project Summary: {Project Name}

**Date**: {yyyy-mm-dd}
**Status**: plan
**Type**: project

---

## Potential Customers

| Segment | Pain Point | Willingness to Pay |
|---------|------------|--------------------|
| | | |

## Best Delivery Option

**Recommended**: {option}
**Alternative**: {option}
**Reasoning**: ...

## Top Features

| # | Feature | Description | Priority |
|---|---------|-------------|----------|
| | | | |

## Underrated Features

| # | Feature | Why It Matters |
|---|---------|----------------|
| | | |

## Top 3 Stacks

### Stack 1: {Name}
- **Components**: ...
- **Why it fits**: ...
- **Trade-offs**: ...

### Stack 2: {Name}
...

### Stack 3: {Name}
...

## Resource Optimization

- ...

## Complexity Level

**Level**: {Low / Medium / High / Very High}
**Justification**: ...
templates/feature-plan.md
# Feature Development Plan: {Project Name}

**Date**: {yyyy-mm-dd}
**Based on**: {link to project summary}

## Phase: MVP (Weeks 1-4)

| # | Feature | Effort (days) | Dependencies | Risk |
|---|---------|---------------|-------------|------|
| | | | | |

## Phase: V1 (Weeks 5-12)

| # | Feature | Effort (days) | Dependencies | Risk |
|---|---------|---------------|-------------|------|
| | | | | |

## Phase: V2

...

## Phase: Future

...
templates/agent-brief.md
# Agent Brief: {Agent Name}

**Project**: {project name}
**Parent**: {parent agent or "root"}

## Purpose
{one sentence}

## Owns
- {folder or file list}

## Context
{minimal context — only what this agent needs}

## References
- {specific docs, APIs, relevant links}

## Skills
- {skill 1}
- {skill 2}

## Tools
- {tool or MCP server}
- File access: {scoped folders}

## Tasks Assigned
| # | Task | From Feature | Est. Hours |
|---|------|-------------|------------|
| | | | |
templates/ideas-tracker-row.md
<!-- Copy this row into ideas-tracker.md -->
| {#} | {name} | {description max 100 chars} | {yyyy-mm-dd} | plan | {project/feature/other} |

The Starter Tracker File
ideas/ideas-tracker.md
# Ideas Tracker

| # | Name | Description | Date | Status | Type |
|---|------|-------------|------|--------|------|
<!-- New entries go below this line -->

How It All Flows
USER: "I have a project idea for..."
  │
  ▼
ROOT AGENTS.md (Orchestrator)
  │
  ├──► ideas/AGENTS.md (Ideas Manager)
  │     └── Updates ideas-tracker.md
  │
  ├──► ideas/project_summaries/AGENTS.md (Summary Writer)
  │     └── Writes project-name_yyyy-mm-dd.md
  │
  │  ◄── PAUSE — User reviews summary
  │
  ├──► planning/AGENTS.md (Planning Agent)
  │     └── Writes feature development plan
  │
  │  ◄── PAUSE — User reviews plan
  │
  ├──► planning/features/AGENTS.md (Feature Breakdown)
  │     └── Writes task-level breakdown per phase
  │
  ├──► planning/agents/AGENTS.md (Agent Architect)
  │     └── Writes agent plan + briefs
  │
  │  ◄── PAUSE — User reviews everything
  │
  └── DONE (ready for execution phase)
Each AGENTS.md file is scoped. Each agent only sees its own AGENTS.md, its local CONTEXT.md, its local REFERENCES.md, and whatever the orchestrator explicitly passes to it. This keeps token usage tight and responsibilities clear.
Help me write the correct opencode.jsonc to use OpenCode ZEN with qwen3.6-plus-free as strong resoning model and minimax-m2.5-free for cost efficient tasks :

{
  // "$schema": "https://opencode.ai/config.json",

  // Provider setup — pick yours
  "provider": {
    "anthropic": {
      "api_key": "env:ANTHROPIC_API_KEY"
    }
  },

  // Model definitions
  "model": {
    // Orchestrator — needs strong reasoning
    "orchestrator": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514",
      "temperature": 0.3
    },
    // Worker agents — cost efficient
    "worker": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514",
      "temperature": 0.2
    }
  },

  // MCP servers if needed later
  "mcp": {}
}Looking at the OpenCode config schema and documentation, here is the corrected opencode.jsonc:
{
  "$schema": "https://opencode.ai/config.json",

  // Provider setup — OpenRouter hosts both free models
  "provider": {
    "openrouter": {
      "api_key": "env:OPENROUTER_API_KEY",
      "name": "OpenRouter"
    }
  },

  // Main model — strong reasoning (orchestrator tasks)
  "model": "openrouter/qwen/qwen3-235b-a22b-04-28:free",

  // Small model — cost efficient (title generation, summaries, worker tasks)
  "small_model": "openrouter/minimax/minimax-m1:extended",

  // Agent configuration using OpenCode ZEN structure
  "agent": {

    // Plan agent — strong reasoning, used for analysis and planning
    "plan": {
      "model": "openrouter/qwen/qwen3-235b-a22b-04-28:free",
      "temperature": 0.3
    },

    // Build agent — cost efficient, used for execution tasks
    "build": {
      "model": "openrouter/minimax/minimax-m1:extended",
      "temperature": 0.2
    }

  },

  // MCP servers — to be configured later
  "mcp": {}
}

Key Corrections and Explanations
1. Provider: OpenRouter (not Anthropic)
Both qwen3-235b-a22b-04-28 (reasoning) and minimax-m1 (efficient) are hosted on OpenRouter. You need a single OPENROUTER_API_KEY from openrouter.ai.
OPENROUTER_API_KEY=your_key_here
2. Model Format: provider/model-id
OpenCode expects models in the format provider/model-id. The correct identifiers on OpenRouter are:
Copier le tableau


Role
Model ID



Strong reasoning
openrouter/qwen/qwen3-235b-a22b-04-28:free


Cost efficient
openrouter/minimax/minimax-m1:extended


3. model vs small_model vs agent
The schema reveals three distinct levels:
Copier le tableau


Field
Purpose



model
Default model for all main interactions


small_model
Lightweight model for minor tasks (titles, short summaries)


agent.plan
Agent-specific override for planning/reasoning tasks


agent.build
Agent-specific override for execution/worker tasks


4. No Custom "orchestrator" / "worker" Keys
The original config used "orchestrator" and "worker" as custom model keys — those do not exist in the schema. The valid agent names in OpenCode ZEN are plan and build (and custom ones defined in AGENTS.md).
5. Verify Model Names
Model slugs on OpenRouter can change. Always verify at openrouter.ai/models before using. Search for qwen3 and minimax to get the exact current identifiers.