Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ccs.kaitran.ca/llms.txt

Use this file to discover all available pages before exploring further.

​
Dashboard Logs

CCS includes a dedicated System -> Logs workspace for operational visibility. It is now a dedicated operations surface with a structured telemetry stream and an upstream-error compatibility tab.

​
Access

ccs config
# Open System -> Logs
# Or navigate directly to /logs inside the current dashboard session

​
Workspace Layout

The route exposes two tabs:
  • Stream - CCS-owned structured runtime telemetry
  • Upstream errors - legacy CLIProxy error files for compatibility

​
Stream

The main stream view is a log workspace, not a raw file dump:
  • Live activity header with live/syncing/disconnected status pill
  • entry, trace, and error counters
  • desktop 3-pane layout: filters, entry list, detail panel
  • mobile detail sheet when you select an entry
  • request-aware filters for source, level, module, stage, requestId, time window, and free-text search
  • “hide dashboard internals” filtering for quieter review
  • live-tail pause/resume controls with pending-count feedback

​
Entry Inspection

Selecting an entry opens a detail panel with:
  • Overview tab for timestamp, stage, requestId, latency, module, and source
  • Context tab for structured metadata with redaction-aware reveal controls
  • Raw tab for copyable JSON
  • Show trace action when the entry belongs to a correlated request trace

​
Upstream Errors

The second tab keeps provider and CLIProxy error files visible without making them the primary logging model. Use it when you need the old error-log lane or when only cliproxy.logging is enabled.

​
Storage Model

​
CCS-Owned Structured Logs

Native CCS logs live under: 
~/.ccs/logs/current.jsonl
~/.ccs/logs/archive/
These logs are controlled by the top-level logging config block and support:
  • minimum log level
  • log rotation by size
  • archive retention by day count
  • context redaction
  • a bounded in-memory buffer for dashboard reads

​
CLIProxy Runtime Logs

CLIProxy runtime files still live under: 
~/.ccs/cliproxy/logs/
Those files are controlled separately through cliproxy.logging.

​
Configuration

logging:
  enabled: true
  level: info
  rotate_mb: 10
  retain_days: 7
  redact: true
  live_buffer_size: 250
This is separate from: 
cliproxy:
  logging:
    enabled: false
    request_log: false
Use top-level logging for CCS-owned runtime events. Use cliproxy.logging only when you need extra CLIProxy runtime files for troubleshooting.

​
Operational Notes

  • Dashboard /api/logs reads are intentionally skipped by request logging so the log viewer does not recursively log itself.
  • The Home route links here through the logs handoff card once you need request-level inspection.
  • Remote users can inspect logs only within the dashboard access rules currently enforced by dashboard auth and localhost-only fallbacks.
  • Redaction is enabled by default so persisted context does not leak obvious secrets into the log stream.

​
Troubleshooting

​
The Logs page looks empty

  • Check whether top-level logging.enabled is still true
  • Trigger a fresh CCS action, then refresh the page
  • If you only enabled cliproxy.logging, look in the Upstream errors tab

​
I only need verbose CLIProxy request traces

Enable cliproxy.logging.request_log instead of raising the global CCS logging level unless you specifically want broader CCS runtime telemetry.