CLI vs API Coverage
Last validated: 2026-05-20
Coverage Matrix
| Area | API support | CLI support | Notes |
|---|---|---|---|
| App CRUD + state | Yes | Yes | app group |
| Draft lifecycle | Yes | Yes | draft group |
| Version lifecycle | Yes | Yes | version group |
| Invoke streaming | Yes | Yes | invoke command |
| Execution get/watch/logs | Yes | Yes | execution group subset |
| Execution list | Yes | No | CLI returns unsupported error |
| App logs/events/replicas/stats APIs | Yes | No | No first-class CLI commands |
| Build create/get/list/log/cancel/upload | Yes | Yes | build group |
| Build secret save | Yes | Yes | build secrets set |
| Model list/get/embed/infer/chat/transcribe | Yes | Partial | CLI has ergonomics gaps in chat/transcribe |
| Model rerank APIs | Yes | No | API-only fallback |
| Secret CRUD | Yes | Yes | secret group |
| MCP tool list/get | Yes | Yes | mcp group |
| Public catalog APIs | Yes | No | API-only fallback |
| AdminService operations | Yes | No | mTLS internal plane, no CLI group |
| Run-once convenience command | N/A | Partial | Command exists but returns unsupported at runtime |
Fallback Strategy
When CLI coverage is missing or partial:
- Use direct gRPC method calls for strong contract alignment.
- Use gateway HTTP routes where your environment exposes and supports them.
- Keep a small internal wrapper library/script for repeated API-only operations (admin, observability, rerank, catalog).
Automation Guidance
- Pin CLI and API/proto versions in CI to reduce drift.
- Treat unsupported CLI commands as hard failures and route to API fallback automatically.
- Keep one integration smoke suite that exercises both CLI-covered and API-only critical paths.