[FEATURE] Alternative Tool Response Format for Claude Code

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The current JSON-based tool format, while robust, presents several challenges for LLM generation:

{
  "tool": "Edit",
  "parameters": {
    "file_path": "config.js",
    "old_string": "debug: false,\nport: 3000",
    "new_string": "debug: true,\nport: 3000"
  }
}

Issues:

1. Token inefficiency: 200-300 tokens for simple operations
2. Parsing errors: ~10-15% failure rate due to malformed JSON
3. Escape complexity: Quotes, newlines, backslashes require careful escaping
4. Cognitive load: Tracking nested structure during streaming generation

Proposed Solution

A delimiter-based format using § symbol and emojis:

§✏️config.js
  port: 3000,
-  debug: false
+  debug: true
§🔚

Format Specification:

• §📖file.txt - Read file
• §✏️file.txt - Edit file (followed by diff)
• §📝file.txt - Create file (followed by content)
• §💻command - Execute shell command
• §🔚 - End multi-line content

Performance Comparison

Real-world example - Adding a package.json script:

Current JSON format (267 tokens):

{
  "tool": "Edit",
  "parameters": {
    "file_path": "package.json",
    "old_string": "  \"scripts\": {\n    \"start\": \"node index.js\",\n    \"test\": \"jest\"\n  }",
    "new_string": "  \"scripts\": {\n    \"start\": \"node index.js\",\n    \"test\": \"jest\",\n    \"dev\": \"node index.js --debug\"\n  }"
  }
}

Proposed format (31 tokens):

§✏️package.json
    "start": "node index.js",
    "test": "jest",
+    "dev": "node index.js --debug"
  }
§🔚

Result: 88% token reduction

Implementation Benefits

1. Token Efficiency

• 70-85% reduction in token usage
• Faster response times
• Lower API costs
• More context available for actual problem-solving

2. Error Reduction

• Current JSON: Common errors include unclosed brackets, missing commas, incorrect escaping
• Proposed format: Nearly impossible to create unparseable output
• Parser can recover from most mistakes (missing end marker, etc.)

3. Natural Generation

• Linear, streaming-friendly format
• No need to track nested structures
• Directly matches how LLMs generate text

4. Human Readable

• Developers can easily read and understand the commands
• Debugging is simplified
• Logs are more compact and scannable

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_