omnillm

Configuration Templates Created

Overview

Created example configuration templates for all 5 AI coding assistants supported by ToolConfig. These templates provide users with a working starting point even if they don’t have existing configurations.

Templates Created

1. Droid (~/.factory/settings.json.example)

Location: C:\Users\jzhu\.factory\settings.json.example

Features:

• Custom models array with full parameter support
• Provider-level defaults (timeout, retry)
• Feature flags (streaming, tools, image support)
• Logging configuration
• UI customization options
• Plugin management

Default Model: GLM 5.1 via OmniLLM gateway

2. Claude Code (~/.claude/settings.json.example)

Location: C:\Users\jzhu\.claude\settings.json.example

Features:

• Model selection
• Environment variables for API routing to OmniLLM
• Plugin enablement
• Auto-update channel
• Dangerous mode prompt toggle

Default Model: qwen3.6-plus via OmniLLM gateway

3. Codex (~/.codex/config.toml.example)

Location: C:\Users\jzhu\.codex\config.toml.example

Features:

• TOML format configuration
• Profile-based settings
• Model provider definitions
• Project trust levels
• Reasoning effort configuration

Default Model: GPT-4 via OpenAI

4. OpenCode (~/.opencode/config.json.example)

Location: C:\Users\jzhu\.opencode\config.json.example

Features:

• Simple flat structure
• Provider and model selection
• Feature toggles (proxy_aware, auto_backup)
• Skills paths array
• MCP servers configuration

Default Model: GLM 5.1 via OmniLLM gateway

5. AMP (~/.amp/config.json.example)

Location: C:\Users\jzhu\.amp\config.json.example

Features:

• Hierarchical model configuration
• Provider definitions with retry logic
• Custom model capabilities
• Model limits and defaults
• UI and logging settings

Default Model: GLM 5.1 via OmniLLM gateway

Key Features of All Templates

✅ Ready to use - Valid JSON/TOML syntax ✅ OmniLLM integration - Pre-configured to route through OmniLLM gateway ✅ Environment variable support - Use ${OMNILLM_API_KEY} instead of hardcoding ✅ Sensible defaults - Working configuration out of the box ✅ Well-documented - Comments and clear field names ✅ Extensible - Easy to add more models or providers

Usage Instructions

Quick Start

1. Copy template to actual location:

   # Example for Droid
   cp ~/.factory/settings.json.example ~/.factory/settings.json
      
   # Example for OpenCode
   cp ~/.opencode/config.json.example ~/.opencode/config.json
   

2. Edit with your values:
   • Replace ${OMNILLM_API_KEY} with actual key or set env var
   • Update model names if needed
   • Adjust feature flags
3. Restart the tool or use ToolConfig UI to apply changes

Using ToolConfig UI

The ToolConfig UI in OmniLLM admin panel will automatically:

• Detect if config file doesn’t exist
• Show “○ new” badge
• Allow you to create and edit the file
• Save it to the correct location

No need to manually copy templates - just start editing in the UI!

Template Locations

User Home Directory (~)
├── .factory/
│   ├── settings.json.example          ← Droid template
│   └── README.md                       ← Usage guide
├── .claude/
│   └── settings.json.example           ← Claude Code template
├── .codex/
│   └── config.toml.example             ← Codex template
├── .opencode/
│   └── config.json.example             ← OpenCode template
└── .amp/
    └── config.json.example             ← AMP template

Benefits

✅ Zero configuration friction - Users can start immediately ✅ Consistent defaults - Everyone starts with same baseline ✅ Best practices - Templates follow recommended patterns ✅ Easy customization - Clear structure makes modifications simple ✅ Reduced support burden - Fewer “how do I configure this?” questions

Integration with ToolConfig

When a user opens ToolConfig UI for the first time:

1. Backend checks if config file exists
2. If not, shows “○ new” badge on the card
3. User can click the card and start editing
4. Structured editor provides intuitive UI
5. On save, creates the actual config file
6. Badge changes to “● exists”

Templates serve as reference for users who want to manually edit or understand the structure.

Next Steps

Consider adding:

• Validation schemas for each config type
• Interactive setup wizard in ToolConfig UI
• Import/export functionality
• Config migration tools between versions

This site is open source. Improve this page.