Support runtimes and providers other than Claude/Anthropic (aka support opencode, codex, gemini, etc)

[jchadwick]

Anthropic is already shutting down peoples' subs for using them with OpenClaw, so I wonder if it is prudent to make this more flexible to select another provider when that fate befalls nanoclaw users.

Opencode, for example, is a (open source!) Claude Code CLI competitor with built-in support for a wide variety of providers right out of the box. Depending on the day and the legal situation, Claude Sub is even one of those providers.

Would it be worth looking into decoupling this from Claude and to any of the more AGENTS.md "compliant" CLIs?

[dmulder]

Could we just use a wrapper? I wrote this thing since I switched to opencode recently (and all my scripts call into Claude already): https://github.com/dmulder/claude_wrapper

[UBy]

Cool, but if Nanoclaw becomes more popular people are going to ask for more than OpenCode.

[jchadwick]

Yes, right. Opencode was just an example.

For starters, just using AGENTS.md which everything other than Claude supports. Skills are a relatively standard thing now, easily supported with symlinks.

Those are just examples, but I wanted to open the discussion

[shanyou]

ACP-Based Multi-Runtime + Shared Skills Architecture

I've been exploring a solution that addresses both the runtime flexibility and skill management concerns discussed here. Here's a proposal:

1. ACP (Agent Communication Protocol) Integration

ACP is an open protocol stewarded by Linux Foundation that enables agent interoperability via RESTful APIs. It's already supported by multiple tools and provides:

• Standard REST endpoints for agent communication
• Multi-modal support (text, code, files, media)
• Sync/async + streaming capabilities
• Agent discovery via manifests

2. Proposed Architecture

WhatsApp → SQLite → Nanoclaw Core → ACP Client → ACP Server (Claude|OpenCode|etc.) → Response

Tool Adapters would enable switching runtimes:

• ClaudeAdapter - wraps Claude Agent SDK
• OpenCodeAdapter - uses OpenCode's ACP support (or claude_wrapper)
• GenericAdapter - for any ACP-compliant tool

3. Shared Skills Management

This addresses a key concern: letting Nanoclaw manage skills that are shared across tools.

Directory Structure:

skills/
├── core/        # Nanoclaw-specific skills
├── user/        # User custom skills
└── shared/       # Shared with ALL runtime tools
    └── git-workflow/SKILL.md

Container Setup with Symlinks:

/workspace/skills/
└── shared/
.claude/skills → /workspace/skills/shared/
.agents/skills → /workspace/skills/shared/

OpenCode already supports multiple skill paths:

• .claude/skills/*/SKILL.md (Claude compatible)
• .agents/skills/*/SKILL.md (AGENTS.md compatible)
• ~/.claude/skills/*/SKILL.md (global Claude)

4. Nanoclaw as Skill ACP Server

Nanoclaw would run an ACP server that exposes:

GET    /skills           # List all skills
GET    /skills/{name}    # Get skill content  
POST   /skills/{name}    # Create/update skill
DELETE /skills/{name}    # Delete skill

Runtime tools in containers call these endpoints to access shared skills.

5. User Experience

# Switch runtime
@Andy switch tool to opencode

# Manage shared skills (via WhatsApp)
@Andy create a skill called "database-migration" for Postgres patterns
@Andy list all shared skills
@Andy delete "database-migration" skill

6. Benefits

1. Runtime Independence - Not tied to Claude or any single tool
2. Single Skill Source - One skill definition works across all tools
3. Nanoclaw in Control - Skills managed through the WhatsApp interface
4. AGENTS.md Native - Leverages the cross-tool standard
5. Easy Extensibility - New tools just need ACP support

7. Implementation Path

1. Create Tool Adapter interface and base ACP client
2. Implement Claude adapter (minimal change to existing code)
3. Add skill symlinks setup to container-runner.ts
4. Build Nanoclaw Skill Manager ACP server
5. Add OpenCode adapter (possibly reuse claude_wrapper)

This approach keeps Nanoclaw's philosophy: small, understandable code that solves real problems without over-engineering.

Thoughts?

[jchadwick]

Implementation specifics aside, this is exactly the kind of thinking I was advocating for.

Don't know enough about the specifics of ACP to say whether or not this is the "right" way, but it sure seems like it.

[lassegit]

Don't most providers support the OpenAI API using different baseUrl?

import OpenAI from 'openai';

const openai = new OpenAI({
    apiKey: "ANTHROPIC_API_KEY",   // Your Claude API key
    baseURL: "https://api.anthropic.com/v1/",  // Claude API endpoint
});

[jchadwick]

No that would be API key usage. This thread is about subscription usage.

[shaunie2fly]

I would integrate using the opencode SDK. Replacing the claude code sdk

[multivac2x]

Could we just use a wrapper? I wrote this thing since I switched to opencode recently (and all my scripts call into Claude already): https://github.com/dmulder/claude_wrapper

I am trying now to install with your wrapper to see if is it working.

[TomGranot]

Reviewed during triage. This is now the canonical issue for alternative runtime support — duplicates #38, #70, #85, and #127 have been closed pointing here. The project currently depends on Claude Agent SDK and Claude Code, but the channel abstraction (#156) and skill system make it possible to swap runtimes via skills. Keeping open as the tracking issue for this feature area.