Kai (Tam Nhu) Tranandkaitranntt 2671b97039 fix(completion): improve shell completion UI/UX and fix mkdir errors (#10)
* fix(shell-completion): resolve ENOTDIR error when parent path is a file

Fixes issue where `--shell-completion` fails with ENOTDIR error when
a file exists where a directory should be created (e.g., ~/.zsh exists
as a file instead of a directory).

Changes:
- Added ensureDirectory() helper that safely creates directories
- Validates parent paths are directories, not files
- Provides clear error message when file conflicts occur
- Applied to all shell installers (bash, zsh, fish, powershell)
- Maintains idempotent behavior (safe to call multiple times)

Before: mkdir with recursive:true fails silently with ENOTDIR
After: Clear error message guides user to resolve file conflict

* chore: bump version to 4.1.4

* feat(completion): improve UI/UX with descriptions and grouping

Improves shell completion UI/UX across all shells (bash, zsh, fish,
PowerShell) with better organization and clearer descriptions.

Changes:
- Zsh: Added descriptions for all profiles and grouped by category
  - Commands: "auth", "doctor" with descriptions
  - Model profiles: glm, glmt, kimi, etc. with descriptions
  - Account profiles: Dynamic with "Account-based profile" label
  - Used _alternative for visual grouping
- Fish: Added explicit completions with descriptions for known profiles
  - Replaced generic profile listing with specific entries
  - Each profile now shows clear description (e.g., "GLM-4.6 (cost-optimized)")
- Bash: Added --shell-completion flag and subflags completion
- PowerShell: Added --shell-completion flag and subflags completion
- All shells: Added completion for --shell-completion subflags

Before (zsh):
  ccs
  auth     -- Manage multiple Claude accounts
  doctor   -- Run health check and diagnostics
  default  glm      glmt     kimi     max

After (zsh):
  commands
    auth    -- Manage multiple Claude accounts
    doctor  -- Run health check and diagnostics
  model profiles
    default -- Default Claude Sonnet 4.5
    glm     -- GLM-4.6 (cost-optimized)
    glmt    -- GLM-4.6 with thinking mode
    kimi    -- Kimi for Coding (long-context)
    max     -- Claude Opus (maximum capability)
  account profiles
    work    -- Account-based profile
    personal -- Account-based profile

Consistent, organized, and informative completion across all shells.

* fix(completion): handle custom profiles and fix zsh syntax errors

Fixes two issues:
1. Zsh syntax errors with _describe -t flag in _alternative
2. Adds general handling for custom settings profiles (e.g., m2)

Changes:
- Zsh: Fixed _alternative syntax (removed -t tag from _describe calls)
  - Error was: "_describe:21: bad option: -M"
  - Cause: Tag is auto-derived in _alternative, don't specify with -t
- Fish: Added __fish_ccs_get_custom_settings_profiles function
  - Dynamically loads non-hardcoded profiles from config.json
  - Shows "Settings-based profile" description for custom profiles
- Removed 'max' from hardcoded known profiles
  - 'max' is user's account-based profile, not a default setting

Now supports any custom settings profile (e.g., m2.settings.json for
Minimax M2) without hardcoding. Custom profiles show with generic
"Settings-based profile" description.

Installation properly overwrites:
- fs.copyFileSync overwrites completion files by default
- RC files only modified if marker not already present

* fix(zsh): simplify completion to avoid _alternative syntax issues

Replaced _alternative with multiple _describe calls to fix persistent
zsh completion errors.

The _alternative approach was causing:
- '_describe:21: bad option: -M'
- '(eval):1: bad substitution'
- Unwanted variable expansion in completion menu

New approach uses sequential _describe calls which zsh handles correctly.
Simpler, more reliable, and still shows grouped completion with
descriptions.

Before: _alternative with complex nested _describe calls (broken)
After: Three simple _describe calls (works correctly)

* feat(zsh): add colors and improved formatting to completion

Enhances zsh completion UI/UX with colors and better spacing:

Colors:
- Blue: commands (auth, doctor)
- Green: model profiles (default, glm, glmt, kimi, custom)
- Yellow: account profiles
- Gray: descriptions

Formatting:
- Wider separator (  --  ) for better readability
- Group headers in bold cyan
- Menu selection enabled for navigation
- list-rows-first for better column layout

Before:
  auth    -- Manage multiple Claude accounts
  default  -- Default Claude Sonnet 4.5
  doctor  -- Run health check and diagnostics
  glm      -- GLM-4.6 (cost-optimized)

After:
  commands (cyan header)
  auth    --  Manage multiple Claude accounts  (blue)
  doctor  --  Run health check and diagnostics (blue)

  model profiles (cyan header)
  default  --  Default Claude Sonnet 4.5       (green)
  glm      --  GLM-4.6 (cost-optimized)        (green)
  glmt     --  GLM-4.6 with thinking mode      (green)
  kimi     --  Kimi for Coding (long-context)  (green)

  account profiles (cyan header)
  max  --  Account-based profile              (yellow)

Table-like appearance with colors matching --help output style.

* feat(fish): add colors to completion descriptions

Adds color-coded descriptions to Fish completion matching zsh style:

Colors:
- Blue: commands (auth, doctor)
- Green: model profiles (default, glm, glmt, kimi, custom)
- Yellow: account profiles

Fish has excellent native color support via set_color, making this
straightforward to implement.

Before:
  auth       Manage multiple Claude accounts
  default    Default Claude Sonnet 4.5
  glm        GLM-4.6 (cost-optimized)
  max        Account profile

After:
  auth       Manage multiple Claude accounts       (blue)
  default    Default Claude Sonnet 4.5            (green)
  glm        GLM-4.6 (cost-optimized)             (green)
  max        Account profile                      (yellow)

Consistent color scheme across zsh and fish shells.

* fix(zsh): correct color application for commands vs descriptions

Fixed color codes being applied backwards - commands were gray while
descriptions were colorful.

Issue:
- Used '1;34' format which zsh misinterpreted
- Commands appeared gray (unreadable)
- Descriptions appeared in color

Fix:
- Simplified color codes from '1;34' to '34' (just the color, no style prefix)
- Pattern now: =(#b)(command)(-- description)=34=90
  - First group (command): color 34 (blue/green/yellow)
  - Second group (description): color 90 (gray)

Before:
  auth    --  Manage multiple Claude accounts  (gray) (blue)

After:
  auth    --  Manage multiple Claude accounts  (blue) (gray)

Commands now properly colored, descriptions muted.

* feat(zsh): improve section header visibility with separators

Makes section headers more distinct and recognizable as dividers:

Before:
  commands
  auth    --  ...

After:

  ── commands ──
  auth    --  ...

Changes:
- Added blank line before headers ($'\n')
- Bold yellow with decorative separators (── text ──)
- Clearly distinguishes section headers from actual commands

Now it's obvious that 'commands', 'model profiles', and 'account
profiles' are just section labels, not completable items.

* fix(zsh): use full ANSI color codes to fix reversed colors

The issue was using shorthand color codes (34, 90) instead of full
ANSI format (0;34, 2;37). Zsh was misinterpreting the shorthand,
causing colors to be applied to wrong groups.

Fixed:
- Commands: 0;34 (normal blue) - was appearing gray
- Model profiles: 0;32 (normal green) - was appearing gray
- Account profiles: 0;33 (normal yellow) - was appearing gray
- Descriptions: 2;37 (dim white) - was appearing colorful

Color codes must be escaped as 0\;34 in zsh strings.

Before fix:
  auth      (gray) --  description (blue)

After fix:
  auth      (blue) --  description (dim gray)

* fix(zsh): swap color order for completion groups

Zsh may apply colors in reverse order to capture groups on some systems.
Swapped color order: group 2 first, then group 1.

Pattern: (command)(separator + description)
Was: =blue=dim_white (applied as: blue to cmd, dim to desc)
Now: =dim_white=blue (applied as: dim to desc, blue to cmd)

Testing if this resolves the reversed color issue.

* fix(zsh): add empty leading color to fix reversed coloring

ROOT CAUSE: Zsh list-colors apply first color to WHOLE match, then
override with subsequent colors for each group. Without an empty
leading color, the whole match color leaks to groups without overrides.

Pattern behavior:
  =(#b)(cmd)(desc)=BLUE=DIM
    → Whole: BLUE, Group1: DIM (override), Group2: BLUE (no override)
    → Result: cmd=dim, desc=BLUE (REVERSED!)

  =(#b)(cmd)(desc)==BLUE=DIM
    → Whole: none, Group1: BLUE, Group2: DIM
    → Result: cmd=BLUE, desc=dim (CORRECT!)

The '==' at start means 'no whole-match color', preventing color bleed.

Now commands will be colorful (blue/green/yellow) and descriptions dim.

* refactor(help): remove specific account examples and generalize description

Removed deterministic account examples (work, personal, team) to make
the help text more generic and less prescriptive.

Changes:
- Removed 'ccs work' and 'ccs personal' example lines
- Removed 'Multi-account workflow' examples section
- Updated description from 'multiple Claude accounts (work, personal, team)'
  to 'multiple Claude accounts and alternative models'
- Changed to 'Run different Claude CLI sessions concurrently'
- Applied consistently across Node.js (bin/ccs.js), bash (lib/ccs),
  and PowerShell (lib/ccs.ps1)

This makes the help text more flexible and doesn't imply specific
use cases or account naming conventions.

* refactor(help): clarify delegation section and remove non-existent command

Updated delegation section in help text across all implementations:

Changes:
- Renamed section from 'Delegation (Token Optimization)' to
  'Delegation (inside Claude Code CLI)' to clarify context
- Removed non-existent '/ccs:create m2' command
- Simplified description to focus on cost savings
- Updated command descriptions:
  - '/ccs:glm' now 'for simple tasks' (clearer use case)
  - '/ccs:kimi' unchanged (already clear)
- Added delegation section to PowerShell help (was missing)
- Consistent messaging across Node.js, bash, and PowerShell

The new section makes it immediately clear that delegation commands
are used within Claude Code CLI sessions, not as standalone commands.

---------
2025-11-18 01:19:28 -05:00

CCS - Claude Code Switch

CCS Logo

One command, zero downtime, multiple accounts

Switch between multiple Claude accounts, GLM, and Kimi instantly.
Stop hitting rate limits. Keep working continuously.

License Platform npm PoweredBy

Languages: English | Tiếng Việt | 日本語


Quick Start

Installation

npm Package (Recommended)

macOS / Linux / Windows

npm install -g @kaitranntt/ccs

All major package managers are supported:

# yarn
yarn global add @kaitranntt/ccs

# pnpm (70% less disk space)
pnpm add -g @kaitranntt/ccs

# bun (30x faster)
bun add -g @kaitranntt/ccs
Alternative: Direct Install (Traditional)

macOS / Linux

curl -fsSL ccs.kaitran.ca/install | bash

Windows PowerShell

irm ccs.kaitran.ca/install | iex

Note: Traditional installs bypass Node.js routing for faster startup, but npm is prioritized for easier deployment automation.


Configuration (Auto-created)

CCS automatically creates configuration during installation (via npm postinstall script).

~/.ccs/config.json:

{
  "profiles": {
    "glm": "~/.ccs/glm.settings.json",
    "glmt": "~/.ccs/glmt.settings.json",
    "kimi": "~/.ccs/kimi.settings.json",
    "default": "~/.claude/settings.json"
  }
}

Custom Claude CLI Path


If Claude CLI is installed in a non-standard location (D drive, custom directory), set CCS_CLAUDE_PATH:

export CCS_CLAUDE_PATH="/path/to/claude"              # Unix
$env:CCS_CLAUDE_PATH = "D:\Tools\Claude\claude.exe"   # Windows

See also: Troubleshooting Guide for detailed setup instructions.


Windows users: Enable Developer Mode for true symlinks (better performance, instant sync):

  1. Open SettingsPrivacy & SecurityFor developers
  2. Enable Developer Mode
  3. Reinstall CCS: npm install -g @kaitranntt/ccs

Warning: Without Developer Mode, CCS automatically falls back to copying directories (works but no instant sync across profiles).


Your First Switch

Important

Before using alternative models, update API keys in settings files:

  • GLM: Edit ~/.ccs/glm.settings.json and add your Z.AI Coding Plan API Key
  • GLMT: Edit ~/.ccs/glmt.settings.json and add your Z.AI Coding Plan API Key
  • Kimi: Edit ~/.ccs/kimi.settings.json and add your Kimi API key

Parallel Workflow: Planning + Execution

# Terminal 1 - Planning (Claude Sonnet)
ccs "Plan a REST API with authentication and rate limiting"

# Terminal 2 - Execution (GLM, cost-optimized)
ccs glm "Implement the user authentication endpoints from the plan"
Thinking Models (Kimi & GLMT)
# Kimi - Stable thinking support
ccs kimi "Design a caching strategy with trade-off analysis"

# GLMT - Experimental (see full disclaimer below)
ccs glmt "Debug complex algorithm with reasoning steps"

Note: GLMT is experimental and unstable. See GLM with Thinking (GLMT) section below for full details.


The Daily Developer Pain Point

STOP Switching. START Orchestrating.

Session limits shouldn't kill your flow state.

You're deep in implementation. Context loaded. Solution crystallizing.
Then: 🔴 "You've reached your usage limit."

Momentum gone. Context lost. Productivity crater.

The Solution: Parallel Workflows

OLD WAY: Switch When You Hit Limits (Reactive)
graph LR
    A[2pm: Building features<br/>In the zone] --> B[3pm: Usage limit hit<br/>BLOCKED]
    B --> C[3:05pm: Stop work<br/>Edit settings.json]
    C --> D[3:15pm: Switch accounts<br/>Context lost]
    D --> E[3:30pm: Restart<br/>Trying to focus]
    E --> F[4pm: Finally productive<br/>Back in flow]

    style A fill:#d4edda,stroke:#333,color:#000
    style B fill:#f8d7da,stroke:#333,color:#000
    style C fill:#fff3cd,stroke:#333,color:#000
    style D fill:#f8d7da,stroke:#333,color:#000
    style E fill:#fff3cd,stroke:#333,color:#000
    style F fill:#d4edda,stroke:#333,color:#000

Result: 1 hour lost, momentum destroyed, frustration builds

NEW WAY: Run Parallel From Start (Proactive) - RECOMMENDED
graph LR
    A[2pm: Start work] --> B[Terminal 1: Claude Pro<br/>Strategic planning]
    A --> C[Terminal 2: GLM<br/>Code execution]
    B --> D[3pm: Still shipping<br/>No interruptions]
    C --> D
    D --> E[4pm: Flow state<br/>Productivity peak]
    E --> F[5pm: Features shipped<br/>Context maintained]

    style A fill:#e7f3ff,stroke:#333,color:#000
    style B fill:#cfe2ff,stroke:#333,color:#000
    style C fill:#cfe2ff,stroke:#333,color:#000
    style D fill:#d4edda,stroke:#333,color:#000
    style E fill:#d4edda,stroke:#333,color:#000
    style F fill:#d4edda,stroke:#333,color:#000

Result: Zero downtime, continuous productivity, less frustration

💰 The Value Proposition:

  • Setup: Your existing Claude Pro + GLM Lite (cost-effective add-on)
  • Value: Save 1 hour/day × 20 workdays = 20 hours/month recovered
  • ROI: Your development time is worth more than the setup cost
  • Reality: Shipping faster than the overhead

Choose Your Path

Budget-Focused: GLM Only
  • Best for: Cost-conscious development, basic code generation
  • Usage: Just use ccs glm directly for cost-effective AI assistance
  • Reality: No Claude access, but capable for many coding tasks
  • Setup: GLM API key only, very affordable
Recommended for Daily Development: 1 Claude Pro + 1 GLM Lite
  • Best for: Daily code delivery, serious development work
  • Usage: ccs for planning + ccs glm for execution (parallel workflow)
  • Reality: Perfect balance of capability and cost for most developers
  • Value: Never hit session limits, continuous productivity
Power User: Multiple Claude Pro + GLM Pro
  • Best for: Heavy workloads, concurrent projects, solo dev
  • Unlocks: Never drain session or weekly limits
  • Workflow: 3+ terminals running specialized tasks simultaneously
Privacy-Focused: Work/Personal Isolation
  • When needed: Strict separation of work and personal AI contexts
  • Setup: ccs auth create work + ccs auth create personal
  • Note: Advanced feature - most users don't need this

Why CCS Instead of Manual Switching?

CCS isn't about "switching when you hit limits at 3pm."

It's about running in parallel from the start.

The Core Difference

Manual Switching CCS Orchestration
🔴 Hit limits → Stop work → Edit config files → Restart Multiple terminals running different models from the start
😰 Context loss and flow state interruption 😌 Continuous productivity with preserved context
📝 Sequential task handling Parallel workflows (planning + execution simultaneously)
🛠️ Reactive problem solving when blocked 🎯 Proactive workflow design prevents blocks

What CCS Gives You

  • Zero Context Switching: Keep your flow state without interruption
  • Parallel Productivity: Strategic planning in one terminal, code execution in another
  • Instant Account Management: One command switches, no config file editing
  • Work-Life Separation: Isolate contexts without logging out
  • Cross-Platform Consistency: Same smooth experience on macOS, Linux, Windows

Manual context switching breaks workflow. CCS orchestrates seamlessly.


Architecture

Profile Types

Settings-based: GLM, GLMT, Kimi, default

  • Uses --settings flag pointing to config files
  • GLMT: Embedded proxy for thinking mode support

Account-based: work, personal, team

  • Uses CLAUDE_CONFIG_DIR for isolated instances
  • Create with ccs auth create <profile>

Shared Data (v3.1+)

CCS items (v4.1): Commands and skills symlinked from ~/.ccs/.claude/ to ~/.claude/ - single source of truth with auto-propagation.

Profile access: ~/.ccs/shared/ symlinks to ~/.claude/ - no duplication across profiles.

~/.ccs/
├── .claude/                 # CCS items (ships with package, v4.1)
│   ├── commands/ccs/        # Delegation commands (/ccs:glm, /ccs:kimi)
│   ├── skills/ccs-delegation/  # AI decision framework
│   └── agents/ccs-delegator.md # Proactive delegation agent
├── shared/                  # Symlinks to ~/.claude/ (for profiles)
│   ├── agents@ → ~/.claude/agents/
│   ├── commands@ → ~/.claude/commands/
│   └── skills@ → ~/.claude/skills/
├── instances/               # Profile-specific data
│   └── work/
│       ├── agents@ → shared/agents/
│       ├── commands@ → shared/commands/
│       ├── skills@ → shared/skills/
│       ├── settings.json    # API keys, credentials
│       ├── sessions/        # Conversation history
│       └── ...

~/.claude/                   # User's Claude directory
├── commands/ccs@ → ~/.ccs/.claude/commands/ccs/  # Selective symlink
├── skills/ccs-delegation@ → ~/.ccs/.claude/skills/ccs-delegation/
└── agents/ccs-delegator.md@ → ~/.ccs/.claude/agents/ccs-delegator.md

Symlink Chain: work profile → ~/.ccs/shared/ → ~/.claude/ → ~/.ccs/.claude/ (CCS items)

Type Files
CCS items ~/.ccs/.claude/ (ships with package, selective symlinks to ~/.claude/)
Shared ~/.ccs/shared/ (symlinks to ~/.claude/)
Profile-specific settings.json, sessions/, todolists/, logs/

Note

Windows: Symlink support requires Developer Mode (v4.2 will add copy fallback)


Usage Examples

Basic Switching

ccs              # Claude subscription (default)
ccs glm          # GLM (cost-optimized)
ccs kimi         # Kimi (with thinking support)

Multi-Account Setup

# Create accounts
ccs auth create work
ccs auth create personal

Run concurrently in separate terminals:

# Terminal 1 - Work
ccs work "implement feature"

# Terminal 2 - Personal (concurrent)
ccs personal "review code"

Help & Version

ccs --version    # Show version
ccs --help       # Show all commands and options

AI-Powered Delegation

Tip

New in v4.0: Delegate tasks to cost-optimized models (GLM, Kimi) directly from your main Claude session. Save 81% on simple tasks with real-time visibility.

What is Delegation?

CCS Delegation lets you send tasks to alternative models (glm, kimi) from your main Claude session using the -p flag or slash commands (/ccs:glm, /ccs:kimi).

Why use it?

  • Token efficiency: Simple tasks cost 81% less on GLM vs main Claude session
  • Context preservation: Main session stays clean, no pollution from mechanical tasks
  • Real-time visibility: See tool usage as tasks execute ([Tool] Write: index.html)
  • Multi-turn support: Resume sessions with :continue for iterative work

Quick Examples

Direct CLI:

# Delegate simple task to GLM (cost-optimized)
ccs glm -p "add tests for UserService"

# Delegate long-context task to Kimi
ccs kimi -p "analyze all files in src/ and document architecture"

# Continue previous session
ccs glm:continue -p "run the tests and fix any failures"

Via Slash Commands (inside Claude sessions):

# In your main Claude session:
/ccs:glm "refactor auth.js to use async/await"
/ccs:kimi "find all deprecated API usages across codebase"
/ccs:glm:continue "also update the README examples"

Via Natural Language (Claude auto-delegates):

# Claude detects delegation patterns and auto-executes:
"Use ccs glm to add tests for all *.service.js files"
"Delegate to kimi: analyze project structure"

Real-Time Output

See exactly what's happening as tasks execute:

$ ccs glm -p "/cook create a landing page"
[i] Delegating to GLM-4.6...
[Tool] Write: /home/user/project/index.html
[Tool] Write: /home/user/project/styles.css
[Tool] Write: /home/user/project/script.js
[Tool] Edit: /home/user/project/styles.css
[i] Execution completed in 45.2s

╔══════════════════════════════════════════════════════╗
║ Working Directory: /home/user/project               ║
║ Model: GLM-4.6                                       ║
║ Duration: 45.2s                                      ║
║ Exit Code: 0                                         ║
║ Session ID: 3a4f8c21                                 ║
║ Total Cost: $0.0015                                  ║
║ Turns: 3                                             ║
╚══════════════════════════════════════════════════════╝

Advanced Features

Slash Command Support: Delegation preserves custom slash commands in prompts:

ccs glm -p "/cook create responsive landing page"
# Executes /cook command in delegated GLM session

Signal Handling: Ctrl+C or Esc properly kills delegated processes (no orphans):

# Hit Ctrl+C during delegation
[!] Parent process terminating, killing delegated session...

Time-Based Limits: 10-minute default timeout with graceful termination (supports :continue):

ccs glm -p "complex task"  # Auto-terminates after 10min if needed
ccs glm:continue -p "pick up where we left off"

Cost Savings Example

Traditional (Main Session):

Context load: 2000 tokens
Discussion:   1500 tokens
Code gen:     4500 tokens
─────────────────────────
Total:        8000 tokens → $0.032

Delegation (GLM):

3x tasks via GLM: 1500 tokens → $0.0045
─────────────────────────────────────────
Savings:                        $0.0275 (86% reduction)

Documentation

  • Workflow Diagrams: See docs/ccs-delegation-diagrams.md for visual architecture
  • Skill Reference: .claude/skills/ccs-delegation/ for AI decision framework
  • Agent Docs: .claude/agents/ccs-delegator.md for orchestration patterns

GLM with Thinking (GLMT)

Caution

NOT PRODUCTION READY - EXPERIMENTAL FEATURE

GLMT is experimental and requires extensive debugging:

  • Streaming and tool support still under active development
  • May experience unexpected errors, timeouts, or incomplete responses
  • Requires frequent debugging and manual intervention
  • Not recommended for critical workflows or production use

Alternative for GLM Thinking: Consider going through the CCR hustle with the Transformer of Bedolla (ZaiTransformer) for a more stable implementation.

Important

GLMT requires npm installation (npm install -g @kaitranntt/ccs). Not available in native shell versions (requires Node.js HTTP server).


Note

Acknowledgments: The Foundation That Made GLMT Possible

CCS's GLMT implementation owes its existence to the groundbreaking work of @Bedolla, who created ZaiTransformer - the first integration to bridge Claude Code Router (CCR) with Z.AI's reasoning capabilities.

Why this matters: Before ZaiTransformer, no one had successfully integrated Z.AI's thinking mode with Claude Code's workflow. Bedolla's work wasn't just helpful - it was foundational. His implementation of:

  • Request/response transformation architecture - The conceptual blueprint for how to bridge Anthropic and OpenAI formats
  • Thinking mode control mechanisms - The patterns for managing reasoning_content delivery
  • Embedded proxy design - The architecture that CCS's GLMT proxy is built upon

These contributions directly inspired and enabled GLMT's design. Without ZaiTransformer's pioneering work, GLMT wouldn't exist in its current form. The technical patterns, transformation logic, and proxy architecture implemented in CCS are a direct evolution of the concepts Bedolla first proved viable.

Recognition: If you benefit from GLMT's thinking capabilities, you're benefiting from Bedolla's vision and engineering. Please consider starring ZaiTransformer to support pioneering work in the Claude Code ecosystem.


GLM vs GLMT Comparison


Feature GLM (ccs glm) GLMT (ccs glmt)
Endpoint Anthropic-compatible OpenAI-compatible
Thinking No Experimental (reasoning_content)
Tool Support Basic Unstable (v3.5+)
MCP Tools Limited Buggy (v3.5+)
Streaming Stable Experimental (v3.4+)
TTFB <500ms <500ms (sometimes), 2-10s+ (often)
Use Case Reliable work Debugging experiments only

Tool Support (v3.5) - EXPERIMENTAL


GLMT attempts MCP tools and function calling:

  • Bidirectional Transformation: Anthropic tools ↔ OpenAI format (unstable)
  • MCP Integration: MCP tools sometimes execute (often output XML garbage)
  • Streaming Tool Calls: Real-time tool calls (when not crashing)
  • Backward Compatible: May break existing thinking support
  • Configuration Required: Frequent manual debugging needed

Streaming Support (v3.4) - OFTEN FAILS


GLMT attempts real-time streaming with incremental reasoning content delivery:

  • Default: Streaming enabled (TTFB <500ms when it works)
  • Auto-fallback: Frequently switches to buffered mode due to errors
  • Thinking parameter: Claude CLI thinking parameter sometimes works
    • May ignore thinking.type and budget_tokens
    • Precedence: CLI parameter > message tags > default (when not broken)

Status: Z.AI (tested, tool calls frequently break, requires constant debugging)

How It Works (When It Works)


  1. CCS spawns embedded HTTP proxy on localhost (if not crashing)
  2. Proxy attempts to convert Anthropic format → OpenAI format (often fails)
  3. Tries to transform Anthropic tools → OpenAI function calling format (buggy)
  4. Forwards to Z.AI with reasoning parameters and tools (when not timing out)
  5. Attempts to convert reasoning_content → thinking blocks (partial or broken)
  6. Attempts to convert OpenAI tool_calls → Anthropic tool_use blocks (XML garbage common)
  7. Thinking and tool calls sometimes appear in Claude Code UI (when not broken)

Control Tags & Keywords


Control Tags:

  • <Thinking:On|Off> - Enable/disable reasoning blocks (default: On)
  • <Effort:Low|Medium|High> - Control reasoning depth (deprecated - Z.AI only supports binary thinking)

Thinking Keywords (inconsistent activation):

  • think - Sometimes enables reasoning (low effort)
  • think hard - Sometimes enables reasoning (medium effort)
  • think harder - Sometimes enables reasoning (high effort)
  • ultrathink - Attempts maximum reasoning depth (often breaks)

Environment Variables


GLMT features (all experimental):

  • Forced English output enforcement (sometimes works)
  • Random thinking mode activation (unpredictable)
  • Attempted streaming with frequent fallback to buffered mode

General:

  • CCS_DEBUG_LOG=1 - Enable debug file logging
  • CCS_CLAUDE_PATH=/path/to/claude - Custom Claude CLI path

API Key Setup


# Edit GLMT settings
nano ~/.ccs/glmt.settings.json

Set Z.AI API key (requires coding plan):

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "your-z-ai-api-key"
  }
}

Security Limits (DoS Protection)


v3.4 Protection Limits:

Limit Value Purpose
SSE buffer 1MB max per event Prevent buffer overflow
Content buffer 10MB max per block Limit thinking/text blocks
Content blocks 100 max per message Prevent DoS attacks
Request timeout 120s Both streaming and buffered

Debugging


Enable verbose logging:

ccs glmt --verbose "your prompt"

Enable debug file logging:

export CCS_DEBUG_LOG=1
ccs glmt --verbose "your prompt"
# Logs: ~/.ccs/logs/

GLMT debugging:

# Verbose logging shows streaming status and reasoning details
ccs glmt --verbose "test"

Check reasoning content:

cat ~/.ccs/logs/*response-openai.json | jq '.choices[0].message.reasoning_content'

Troubleshooting:

  • If absent: Z.AI API issue (verify key, account status)
  • If present: Transformation issue (check response-anthropic.json)

Maintenance

Health Check

Run diagnostics to verify your CCS installation:

ccs doctor

Checks performed:

  • ✓ Claude CLI availability
  • ✓ Configuration files (config.json, profiles)
  • ✓ CCS symlinks to ~/.claude/
  • ✓ Delegation system
  • ✓ File permissions

Output:

[?] Checking Claude CLI... [OK]
[?] Checking ~/.ccs/ directory... [OK]
[?] Checking config.json... [OK]
[?] Checking CCS symlinks... [OK]
...
Status: Installation healthy

Update CCS Items

If you modify CCS items or need to re-install symlinks:

ccs update

What it does:

  • Re-creates selective symlinks from ~/.ccs/.claude/ to ~/.claude/
  • Backs up existing files before replacing
  • Safe to run multiple times (idempotent)

When to use:

  • After manual modifications to ~/.claude/
  • If ccs doctor reports symlink issues
  • After upgrading CCS to a new version

Uninstall

Package Managers


# npm
npm uninstall -g @kaitranntt/ccs

# yarn
yarn global remove @kaitranntt/ccs

# pnpm
pnpm remove -g @kaitranntt/ccs

# bun
bun remove -g @kaitranntt/ccs

Official Uninstaller


# macOS / Linux
curl -fsSL ccs.kaitran.ca/uninstall | bash

# Windows PowerShell
irm ccs.kaitran.ca/uninstall | iex

🎯 Philosophy

  • YAGNI: No features "just in case"
  • KISS: Simple bash, no complexity
  • DRY: One source of truth (config)

📖 Documentation

Complete documentation in docs/:

🤝 Contributing

We welcome contributions! Please see our Contributing Guide for details.

Star History

Star History Chart

License

CCS is licensed under the MIT License.

Made with ❤️ for developers who hit rate limits too often

Star this repo | 🐛 Report issues | 📖 Read docs

S
Description
Switch between Claude accounts, Gemini, Copilot, OpenRouter (300+ models) via CLIProxyAPI OAuth proxy. Visual dashboard, remote proxy support, WebSearch fallback. Zero-config to production-ready.
Readme MIT
33 MiB
Languages
TypeScript 81.4%
HTML 8.1%
JavaScript 7.1%
Swift 1.7%
Shell 1%
Other 0.6%