Provider Commands
Providers are the LLM services that power Lattice's intelligence—whether local models through Ollama or cloud APIs from Anthropic and OpenAI. The provider commands let you inspect configuration, test connectivity, and troubleshoot issues when AI interactions fail.
Listing Configured Providers
When you want to see which LLM providers are available to Lattice, the lattice-ctl provider list command shows your configured providers:
lattice-ctl provider list
This displays every provider defined in your configuration, showing their type (local or cloud), connection details, default models, and enabled status. The list helps you understand your LLM landscape at a glance—which providers are active, how they're configured, and which is set as default.
Understanding the provider list is crucial when debugging issues. If you expect to use Ollama but it doesn't appear in the list, you know the configuration is wrong or missing. If a provider shows as disabled when you need it active, you know to check the enabled field in your configuration file. The list provides ground truth about what the daemon thinks it has access to.
For programmatic access to provider information, JSON output structures the data for parsing:
lattice-ctl provider list --format json
The JSON format includes all provider metadata in a structure you can process with tools like jq. This becomes valuable when building automation that needs to verify provider availability or generate reports about configured providers.
Inspecting Provider Details
Sometimes you need more information about a specific provider than the list provides. The lattice-ctl provider show command retrieves detailed configuration for a single provider:
lattice-ctl provider show ollama
This shows comprehensive details about how the Ollama provider is configured—its base URL, which model is default, whether it's enabled, and any authentication configuration. The detailed view helps you verify configuration accuracy and understand exactly how the daemon will interact with this provider.
Provider IDs must match exactly what's in your configuration. The show command uses these IDs to look up providers, so "ollama" and "Ollama" are different identifiers even though they look similar. If a show command fails, verify you're using the exact provider ID from your configuration file.
provider test
Test connectivity to a provider.
lattice-ctl provider test <PROVIDER_ID> [--verbose]
Options:
--verbose, -v- Show detailed connection info
Examples:
# Quick test
lattice-ctl provider test ollama
# Output:
# Testing provider: ollama
# ✓ Connection successful
# ✓ Base URL reachable: http://localhost:11434
# ✓ Provider healthy
# Verbose test
lattice-ctl provider test ollama --verbose
# Output:
# Testing provider: ollama
# ✓ Connection successful
# ✓ Base URL: http://localhost:11434
# ✓ Response time: 45ms
# ✓ Provider version: 0.1.20
# ✓ Available models: 3
Common issues:
# Provider unreachable
lattice-ctl provider test ollama
# Error: Connection refused
# → Start Ollama: ollama serve
# API key missing
lattice-ctl provider test anthropic
# Error: Missing API key
# → Set in config or environment: export ANTHROPIC_API_KEY=sk-...
Testing Provider Connectivity
Configuration alone doesn't guarantee a provider will work—network issues, authentication problems, or service outages can prevent access even when configuration is correct. The lattice-ctl provider test command verifies that the daemon can actually reach and communicate with a provider:
lattice-ctl provider test ollama
The test command attempts to connect to the provider, authenticate if necessary, and execute a simple request to verify everything works end-to-end. A successful test confirms the provider is accessible and ready for use. A failed test indicates problems that need investigation—the output explains what went wrong, whether it's unreachable network endpoints, invalid credentials, or provider-side errors.
For local providers like Ollama, test failures usually mean the service isn't running. For cloud providers like Anthropic, failures often indicate missing or invalid API keys. The error messages guide you toward the specific issue that needs fixing.
Adding the --verbose flag produces detailed connection information that's invaluable for debugging subtle issues:
lattice-ctl provider test ollama --verbose
Verbose output shows the complete connection sequence: DNS resolution, TCP connection establishment, TLS handshake (for HTTPS), HTTP request/response details, and timing information. This granular visibility helps identify where in the connection process things are failing when standard test output isn't specific enough.
Listing Available Models
Providers offer different models with varying capabilities, and knowing which models are available helps you choose the right one for each task. The lattice-ctl provider models command queries a provider for its model inventory:
lattice-ctl provider models ollama
For local providers like Ollama, this shows models you've already downloaded and have available locally. For cloud providers, it lists all models you have access to through your subscription or API tier. The model list includes names you use to reference models in configuration or when requesting specific model usage.
Model availability varies by provider and changes over time as new models release and old ones deprecate. Periodically checking model lists ensures you're aware of new options and helps you understand why a model you expected might not be available—perhaps you haven't downloaded it yet for local providers, or your API tier doesn't include it for cloud providers.
JSON output provides structured model data including metadata like model sizes, capabilities, and version information when providers expose it:
lattice-ctl provider models ollama --format json
This structured format is useful for generating model selection UI in applications or for automated tooling that needs to validate model availability before attempting to use specific models.
Troubleshooting Provider Issues
When providers aren't working, systematic troubleshooting helps identify the root cause quickly.
For local providers that report connection failures, first verify the service is actually running. Check for the provider's process with ps aux | grep ollama for Ollama or verify LM Studio is open and its server is started. If the provider isn't running, start it before retrying your test. Sometimes services crash silently—checking process status is always the first step.
Network connectivity problems manifest as timeouts or "connection refused" errors. For local providers, ensure you're using the correct URL and port—Ollama defaults to localhost:11434, while LM Studio uses localhost:1234. Test the endpoint manually with curl to rule out network-level issues: curl http://localhost:11434 should return a response if Ollama is running.
Cloud provider authentication failures almost always indicate API key issues. Verify the key is set correctly with echo $ANTHROPIC_API_KEY or whatever environment variable the provider uses. Check that the key hasn't expired or been revoked in the provider's console. Ensure the daemon inherited the environment variable—if you set it after starting the daemon, restart the daemon to pick up the new value.
When models don't appear in the models list, the cause depends on provider type. For Ollama, you need to explicitly download models with ollama pull before they appear. For LM Studio, models must be downloaded through the app's interface. For cloud providers, your API tier might not include access to certain models—check your subscription level in the provider's console.
If provider tests succeed but actual usage fails, the problem likely lies in model configuration or request formation rather than provider connectivity. Verify your default model exists in the provider's model list. Check daemon logs for detailed error messages explaining what's failing during actual inference requests.
Next Steps
Provider configuration is just the beginning of using Lattice effectively. The configuration guide covers provider setup in more detail, including all available configuration options. The local models guide walks through Ollama and LM Studio setup specifically. For cloud providers, see the cloud providers guide covering Anthropic, OpenAI, and Google. Finally, the daemon control guide explains how to manage the daemon process that connects to these providers.