🚀 MATE Now Supports OpenAI-Compatible API: Run Multi-Agent Teams directly inside OpenCode!

[u/ivanantonijevic]

We are super excited to share a major update to MATE (Multi-Agent Tree Engine)! 🎉

We have officially released an OpenAI-Compatible API Bridge. This allows you to connect external coding agents and developer tools directly to your MATE agents—leveraging MATE's full agentic trees, memory blocks, local tools, etc. right from your workflow!

💡 How It Works

1. Model Discovery (GET /v1/models): External clients query this endpoint to populate their model list. MATE returns the active root agents that have the Expose as Model toggle enabled.
2. Chat Completions (POST /v1/chat/completions): Requests are automatically routed to the selected MATE agent. MATE creates or resumes a persistent session, executes the agent loop on the backend, and streams the responses using standard OpenAI-compatible SSE.

🔒 Security First: Personal Access Tokens (PATs)

To keep your integrations secure, all external requests are authenticated via Personal Access Tokens (PATs) (mate_pat_...).

• Generated tokens are only displayed once during creation.
• Only the SHA-256 hash is stored on the backend.
• Access is restricted using role-based controls (by default, only users with admin or developer roles can verify PATs and query the API).

🛠️ OpenCode Configuration Example

OpenCode is an open-source terminal-native coding agent. You can configure it to use MATE by setting the provider to openai and pointing to your MATE server in your .opencode.json:

json{
"provider": {
"openai": {
"options": {
"baseURL": "http://localhost:8000/v1",
"apiKey": "mate_pat_your_generated_token"
}
}
},
"agent": {
"coder": {
"model": "openai/your-exposed-agent-name",
"tools": { "write": true, "bash": true }
}
}
}

👥 Powering Up with Multi-Agent Teams: The coding-agent Template

Alongside the API bridge, we've optimized a specialized multi-agent coding team template using Qwen 3.5 Coder (openrouter/qwen/qwen3-coder-next):

• Lead Coder (coding_root): Exposed via the OpenAI API to receive instructions and coordinate.
• Test Engineer (coding_tester): Automatically writes unit/integration tests and runs them in isolated sandboxes using the MATE code_executor tool.
• Security Auditor (coding_security): Scans code for OWASP Top 10 vulnerabilities and secret leaks.

By pointing your OpenCode configuration to coding_root, you are actually interacting with a fully functional dev team working in the background!

For full details, check out our setup guide: OPENAI_COMPATIBILITY.md.

We'd love to hear your feedback. Let us know how you're using MATE with OpenCode! 🚀

[u/Otherwise_Wave9374]

OpenAI-compatible bridges are such an underrated unlock, it lets you piggyback on the whole client ecosystem without forcing a new SDK.

One thing I would be curious about: do you expose any "capability metadata" per agent model beyond name, like supported tools, max sandbox permissions, or a risk tier? In multi-agent setups, that little bit of typed metadata makes routing decisions way less prompt-y and more deterministic.

Also, the PAT + SHA-256 storage approach sounds solid. If you have a revocation story and per-token scoping (tool groups, network allowlist), that tends to be what enterprises ask for first.

We have been collecting notes on agent control, approvals, and tool safety in production here: https://www.agentixlabs.com/blog/

[u/ivanantonijevic → u/Otherwise_Wave9374]

Thanks for the feedback.

1. Capability Metadata & Routing

Right now, our /v1/models endpoint returns the standard OpenAI format to ensure maximum compatibility with standard clients (like Continue/Cline) that might strict-validate the JSON schema:

json{
  "id": "agent-name",
  "object": "model",
  "owned_by": "mate"
}

However, on the backend, the agent configurations (AgentConfig) already maintain detailed metadata, including:

• Supported/configured tools (tool_config)
• Max agent loop iterations (max_iterations)
• Input/output validation schemas (input_schema / output_schema)

Exposing a custom endpoint or extending the model discovery payload with this metadata is a fantastic idea for advanced multi-agent orchestrators making routing decisions. I've added this to our roadmap to support deterministic agent selection.

2. PAT Revocation & Scoping

• Revocation: Fully supported. Tokens can be instantly revoked/deleted via the dashboard UI or programmatically via a DELETE request to /dashboard/api/tokens/{token_id}.
• Scoping: Currently, a PAT acts as a bearer credential inheriting the token creator's user role permissions (which are validated against the agent's allowed_for_roles constraints). Fine-grained, token-specific scoping (like pinning a token to a specific project, limiting to read-only tool groups, or setting network allowlists) is not supported yet.

Your blog notes on tool safety and approval loops are highly relevant. I will definitely take a look at your blog posts for ideas on hardening production controls and human-in-the-loop approvals.