Introducing the OpenCaddis SDK: Build Your Own Addons

Why Addons

OpenCaddis ships with 10 built-in plugins that cover a lot of ground — web browsing, file management, PowerShell, Docker, email, memory, and more. But every team has different needs. A dental practice wants to integrate with their practice management software. A DevOps team wants to pull from their monitoring stack. A research team wants to connect to their proprietary data store.

We can't build all of that ourselves. And we shouldn't try. The right answer is to make OpenCaddis extensible and let the community build what they need.

OpenCaddis already had FabrCore plugins (IFabrPlugin) for adding agent tools. But we needed a layer above that — one that could register application services, contribute settings UI, and manage persistent configuration. That's what the OpenCaddis SDK provides.

What's in the SDK

The SDK is intentionally small. Three interfaces and an attribute — that's it:

Here's a complete addon in under 20 lines:

using Microsoft.Extensions.DependencyInjection;
using OpenCaddis.Sdk;

[CaddisAddon("MyAddon")]
public class MyAddon : ICaddisAddon
{
    public string Name => "My Custom Addon";

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<MyCustomService>();
    }
}

Build it, copy the DLL into the OpenCaddis output directory, restart. Your addon is discovered and loaded automatically — no configuration, no registration code, no assembly references back to OpenCaddis.

Zero-Registration Discovery

The discovery mechanism is simple and deliberate. At startup, OpenCaddis loads every assembly in the output directory, scans for types with the [CaddisAddon] attribute that implement ICaddisAddon, and calls ConfigureServices() on each one.

This means addon authors don't need to know how OpenCaddis wires up its DI container. They don't need a project reference to the main application. They just need the SDK, a class with the right attribute and interface, and a DLL in the right folder.

It's the same pattern that made plugin systems in tools like VS Code and JetBrains successful — convention over configuration, with the framework handling discovery.

Persistent Configuration

Most addons need to store settings — API keys, endpoints, feature flags. The SDK provides ICaddisConfigService for this. It reads and writes named sections in opencaddis.json, alongside agent definitions.

var settings = await _config.GetAddonConfigAsync<MySettings>("MyAddon")
    ?? new MySettings();

settings.ApiEndpoint = "https://api.example.com";
await _config.SetAddonConfigAsync("MyAddon", settings);

The configuration is strongly typed on the addon side and stored as JSON extension data on disk. No schema conflicts between addons — each one owns its named section.

Addons + Plugins Working Together

The most powerful pattern is combining both layers. An addon registers shared services at startup (HTTP clients, API wrappers, database connections), and a FabrCore plugin exposes those services as tools that agents can call.

// Addon: registers the API client at startup
[CaddisAddon("Weather")]
public class WeatherAddon : ICaddisAddon
{
    public string Name => "Weather";
    public void ConfigureServices(IServiceCollection services)
        => services.AddHttpClient<WeatherApiClient>();
}

// Plugin: gives agents a weather tool
[PluginAlias("Weather")]
public class WeatherPlugin : IFabrPlugin
{
    private WeatherApiClient _client = default!;

    public Task InitializeAsync(
        AgentConfiguration config, IServiceProvider sp)
    {
        _client = sp.GetRequiredService<WeatherApiClient>();
        return Task.CompletedTask;
    }

    [Description("Get the current weather for a city")]
    public async Task<string> GetWeather(string city)
        => await _client.GetForecastAsync(city);
}

Both are in the same assembly, both are auto-discovered, and agents can use the weather tool immediately after restart. No changes to OpenCaddis itself.

The Bigger Picture: An Addon Marketplace

Today's SDK release is the foundation. The interfaces are stable and usable right now — you can build and deploy addons today. But this is the beginning of something larger.

Here's where we're headed:

• NuGet distribution — publish OpenCaddis.Sdk as a NuGet package so addon authors can dotnet add package instead of cloning the repo
• Addon marketplace — a community directory where developers can publish, discover, and install addons directly from the OpenCaddis UI
• Richer UI hooks — addons that contribute sidebar panels, chat decorators, and custom pages, not just settings
• Addon sandboxing — permission scoping and trust levels for community-published addons

The goal is for addons to become the primary way OpenCaddis grows. The built-in plugins demonstrate patterns. The community builds what's actually needed.

Get Started

The SDK is available now in the OpenCaddis repository. Full documentation is on the SDK & Addons docs page.

# Clone the repo
git clone https://github.com/vulcan365/OpenCaddis.git

# Create your addon project
cd OpenCaddis/src
dotnet new classlib -n MyAddon -f net10.0
dotnet add MyAddon reference OpenCaddis.Sdk/OpenCaddis.Sdk.csproj

# Build and deploy
dotnet build MyAddon -c Release
cp MyAddon/bin/Release/net10.0/MyAddon.dll OpenCaddis/bin/Release/net10.0/