AI Council vs OpenCode: what each one does

In short

AI Council is a self-hosted platform for development teams. It parses your repositories into a code graph on its own: stack, structure, dependencies and cycles, calls, data, architecture, DDD, patterns, style, code smells, and quality per ISO 25010. On top of the graph sits the project knowledge base: decisions, notes, diagrams, and changelogs. Each entry is tied to a place in the code and to a branch, and it reaches the agent when the agent touches the relevant file. Conventions live separately. These are rules with three scopes (code entities, paths, and the whole project), with MUST/SHOULD levels, states, and checks before an edit and against the diff. Around this you get review that posts to the merge request (MR), tickets, tasks, and companies with roles and a license. Static code analysis does not use a model, but without a model that is all you have left: review, knowledge review, AI chat, and workspaces run through a host worker, a bridge, and the vendor CLI/OAuth. The model lives on the host, not in the Council stack.

There are two ways to work with Council. On a developer's machine, Claude Code or Codex connects to it through MCP and hooks: project rules arrive with every message, file context arrives on Read/Edit/Bash, and a checklist comes at the end. In a workspace, the task runs on a VM in an isolated sysbox container, lives for days, and is driven by a person from the web UI, from analysis and diff through commit, push, and MR.

opencode is an open-source AI coding agent (MIT license). It is not an analyzer or a knowledge base. It is the agent itself: it reads files, edits them, runs commands, and talks to the model. It runs on the developer's machine as a CLI and terminal UI, plus a web app, an Electron desktop app, a VS Code extension, and an HTTP API/SDK. One server process serves one or more directories. Session history and attachments are stored in a single SQLite database, and file snapshots in a shadow git repo. You bring your own model: a provider key, an OAuth connection, or a managed provider through Console. The repository is a Bun monorepo with 35 packages, 4 services, and about 8,900 files.

It is not a Council competitor on knowledge. opencode occupies exactly the slot where the vendor agent CLI sits in a Council workspace. So the comparison only makes sense on the one thing they share, how the agent works with code, and on what each adds beyond that.

1. Understanding the code

	AI Council	opencode
Who reads the code	Council itself: it parses the repositories and builds a graph. No model is called during analysis	The agent itself: the model calls read, search, and shell tools. There is no background parsing
When	On project creation, on push to main (polling), on demand, and nightly. After each file edit by the agent (Write/Edit), the file and its dependents are recomputed	During a turn, when the model asks. Nothing is kept between sessions except history, snapshots, and instructions
What it extracts	Layers L0–L10: stack and framework guides; structure; dependencies and cycles; metrics and call graph; data layer (ORM, DDL); architecture style and forbidden dependencies; design patterns; code style; DDD (bounded contexts via Leiden, aggregates, events); file coupling from co-changes in git; code smells; quality per ISO 25010 and fitness functions; diagrams	Only what the model has read: files, ripgrep results, command output, diffs. No persistent graph, layers, metrics, or code smells
Languages	Python, PHP, TypeScript, JavaScript, Java, Kotlin, C#, C, C++, with full layer analysis	Any language the model can read. There is no code parsing of its own; tree-sitter is used to parse shell commands (bash, PowerShell) and for syntax highlighting in the TUI, not to build a graph
LSP	— (own parsing and graph)	LSP settings and operation permissions exist, but the runtime does not yet: `edit` and `write` carry a TODO "Add LSP notification and diagnostics after LSP runtime exists"
Multiple repositories	A project made of several repositories with a shared graph	One server serves several Locations (directories), each with its own config, permissions, and tools. A project is a directory with `.git`/`.hg`; workspace and worktree provide extra copies. No shared graph across repositories
External analyzers	SonarQube: imports its findings; own scanner (text languages, JVM, .NET, .NET Framework on Windows)	—
History	Edges are versioned after every run; `architecture_as_of` returns the architecture as of a date	History is the session event log plus file snapshots (shadow git) for undo and per-step diffs. No architecture history
Search	Semantic and regex search, `find_usages`, `find_path`, dependency graph, similar implementations; `ask_question` returns excerpts from the knowledge base without a model paraphrasing them	`grep` and `glob` via ripgrep, `read`, `shell`; `webfetch` and `websearch`. No semantic code search

2. Knowledge and rules

	AI Council	opencode
Knowledge base	Decisions, notes, Mermaid diagrams, changelogs. Each entry is tied to code and reaches the agent when it touches the relevant file	No separate knowledge base. There are instructions (files like `AGENTS.md`), skills (`SKILL.md`, up to 10 files), slash commands, agents, and references. Memory is session history, compaction, and instructions on disk
Freshness	An entry holds its place in the code on its branch and goes back for re-checking when the code under it changes, when the entry itself changes, when a similar entry appears, or when the branch is merged. The reviewer model (read-only) must quote the source verbatim; the result is a label, and the text is left untouched	Not re-checked: instructions are read from files on disk, and keeping them current is up to a person or the agent
Branches	Knowledge and the graph are stored per branch; the agent sees its own branch, the parent, and what has been merged; on merge, entries move over	Sessions are tied to a project and directory; workspace and worktree provide isolation. No per-branch knowledge
Rules	Conventions with three scopes: code entities, paths (they apply even to a file that does not exist yet), and the whole project. MUST/SHOULD levels; "draft", "retired", and "deleted" states. Checked before an edit and against the diff	`AGENTS.md` instructions, `allow`/`ask`/`deny` permissions, provider and integration policies, config layers. No rules engine tied to entities and paths
How it reaches the agent	Claude Code hooks: project rules with every user message; a broad channel before each action; file context on every Read/Edit/Bash; a checklist at the end of the turn. KB gate: the agent cannot open code until it has queried the knowledge base, and only a person can lift the gate	Builds context itself, from the inside: system prompt, instructions, skills, and tool definitions. Plugin hooks run in-process. No external hooks like Claude Code has
MCP	Server: about 60 tools, profiles, per-session modes, XML responses with a size cap	Client: stdio/socket/remote servers, OAuth, prompts/resources, elicitation. About 15 built-in tools of its own
Portability	Bulk export and import of knowledge, copying between projects	Export and import of sessions and auth; layered config. No knowledge transfer

3. Requirements and tasks

	AI Council	opencode
Requirements	Tracing tests to requirements by tags: coverage and gaps; "no test" is a tri-state, not requirements management	—
Tickets	Jira, GitHub Issues, Redmine: reading, extracting into knowledge, ticket advice from the graph	— (GitHub automation only in its own repository: triage bots in CI)
Working on your own machine	The agent is the developer's Claude Code; Council supplies context and rules; local diff review, diff breakdown, diff checks against the rules	This is its main mode: CLI, TUI, web app, desktop, VS Code. A person drives each turn in the terminal or the browser
Workspace	Tasks run on a VM in a sysbox container and live for days; a person drives the agent from the UI chat; a mentor; diff → commit → push → MR	One server on the machine, several clients. Sessions with an input queue (steer/queue), interruption, questions, and permission prompts; subagents and background jobs. No per-task isolation on a separate VM
PR	Review that posts to the MR (GitHub, GitLab, Bitbucket)	No MR posting; the agent can call `gh` through the shell if you ask it to

4. Review and models

	AI Council	opencode
Code review	A separate service: looks at what changed, gives a verdict per file, runs a second pass, posts to the MR without duplicates	None; there is a session diff view and snapshots for undo
Models	A model is required: on the host, two processes work through the vendor's OAuth, serving AI chat and six background jobs (review, knowledge review, ticket analysis, and others). Without a model, only static code analysis remains.	Your own key or OAuth for dozens of providers: OpenAI, Anthropic, Google/Vertex, Bedrock, Azure, xAI, Groq, OpenRouter, DeepSeek, Mistral, Moonshot, and more; custom and local endpoints through the generic `openai-compatible`/`anthropic-compatible`. The models.dev catalog supplies models, prices, and limits; there is prompt caching and compaction
Model governance	Model and budget are set in project settings	Managed provider through Console: the organization sets `provider.use`, `tool.use`, and `integration.use` policies; Console sends approvals to the client
Agents	Claude Code and Codex (hooks, MCP); MCP is available to any client	One agent with modes (`build`, `plan`, custom agents and subagents) and an ACP bridge for editors. It is the agent itself, not a wrapper around a dozen CLIs

5. Platform

	AI Council	opencode
Users	Companies → members → roles (can be per project) → permissions. Company API keys. Data is separated by company: a request without a company is rejected. Per-installation license and seat limits	A single developer. Server mode is turned on explicitly; without a password the server runs with no authentication, as stated in SECURITY.md. Console adds organization policies for managed providers
Interface	About 50 web UI pages: code, graph, branches, quality, rules, review, knowledge, tickets, tasks, MCP Live, administration, System Health	TUI (SolidJS + OpenTUI), web app, Electron desktop, VS Code extension, HTTP API/SDK (about 139 endpoints), ACP for editors
Monitoring	Telemetry for every MCP and hook call, with no personal data; a repeated search by the agent signals a poor first answer. About 22 Prometheus rules with tests; System Health screen, tracing	Logs and `debug` commands, a `stats` service (usage analytics), OpenTelemetry in utilities. No Prometheus, System Health, or observability dashboards
Self-healing	Temporal reconciliation with the database, cleanup of orphaned data, background batch deletion of projects, nightly backup with a weekly restore check, pruning of old telemetry	Claims and an event log: a turn resumes after a crash within a retry budget; orphaned tool calls and compactions are closed; background jobs and persistent PTYs are restored. No backup or restore check
Storage	Neo4j, Qdrant, PostgreSQL per service, Temporal, NATS, Redis	A single SQLite database (Drizzle) + shadow git for snapshots + tool output files; attachments are blobs in SQLite
Isolation	A sysbox container per task, one-time credentials for push, a read-only knowledge reviewer, permission checks in a single gateway, SSRF protection	Not a sandbox (SECURITY.md): permissions are a UX aid, not isolation. Directories are isolated by Location; CodeMode gives no network, file, or process access; plugins are trusted like config; third-party MCP servers are outside the trust boundary. The threat model has no separate protection for outbound URLs
Delivery	A distribution for self-hosted installation, or SaaS; on the developer's machine, MCP and hooks	Bun/npm, binaries, desktop, Nix, VS Code extension; CI on GitHub Actions, SST infrastructure (Cloudflare, AWS)
License	Proprietary	MIT

Bottom line

opencode is not a Council competitor on knowledge and rules. It is exactly the layer that Council fills with the vendor CLI in a workspace: the agent itself, which reads code, calls tools, talks to the model, and holds the session. So "which is stronger" only makes sense on the one thing they share, how the agent works with code.

Where opencode is stronger:

runs locally, with no server and no Council key;
dozens of providers and your choice of model, including custom and local endpoints;
MIT license and a one-command install;
a clean core: event sourcing in SQLite, crash recovery, an input queue, per-tool permissions, CodeMode;
surfaces: TUI, web, desktop, VS Code, SDK; ACP for editors;
open source, so you can embed it: @opencode/sdk assembles Client + Core + Server inside another process.

Where Council is stronger: depth, and everything around the agent.

It understands the project, not just the session. The L0–L10 graph: stack, structure, dependencies and cycles, calls, data, architecture and forbidden dependencies, patterns, style, DDD, co-change, code smells, ISO 25010, diagrams; static analysis does not call a model. opencode is an agent. It reads code but does not build a project graph.
Knowledge is tied to code and branches. An entry lives on a branch, reaches the agent when it touches the file, and goes back for re-checking when the code under it changes; the reviewer must quote the source. opencode has the session and its context, but no knowledge base of decisions and their reasons.
Conventions are checked before the edit and against the diff. Three scopes (entities, paths, project), MUST/SHOULD, states, delivery through hooks with every message, and file context on Read/Edit/Bash; the KB gate blocks reading code until the agent has queried the knowledge base. opencode builds context its own way, but it has no authoritative team rules.
Code and knowledge review run as a service. A verdict per file, a second pass, MR posting without duplicates; a separate knowledge review with quotes and calibration. opencode is the agent; it has no review service and no MR posting.
Tasks on a VM with a human in the loop. A task in a sysbox container lives for days, and a person drives it from the UI: analysis → diff → commit → push → MR; one-time credentials, RBAC, SSRF protection. opencode runs locally and does not provide this layer.
Teamwork, permissions, and licensing. Companies → members → roles (including per project) → permissions, company API keys, license and seats; self-hosted/offline or SaaS. opencode is an MIT tool for a single developer, with no multi-user model and no license or seats.
Visibility into what the agent does. Telemetry for every MCP and hook call with no PII, repeated agent searches as a signal, about 22 Prometheus rules, System Health, tracing; Temporal reconciliation with the database, cleanup of orphaned data, backup with a restore check. opencode has session event sourcing, but no per-call observability and no platform System Health.

Can they work together? Yes, but not as fully as with Claude Code. opencode is an MCP client, so Council tools (brief_me_on, list_knowledge, search_code, check_diff_conventions, and the rest) are available to it: just add the Council MCP server to its config. What opencode does not get are the Council hooks: the rulebook on every prompt, file context on every Read/Edit, and the KB gate. opencode has its own way of building context. For Council to deliver rules to opencode the way it does to Claude Code, you would need an opencode plugin (opencode supports in-process hooks) or a separate integration. That does not exist today.

AI Council and anomalyco/opencode: what each one does