netra-zen 1.0.7__tar.gz → 1.0.8__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {netra_zen-1.0.7/netra_zen.egg-info → netra_zen-1.0.8}/PKG-INFO +172 -7
- {netra_zen-1.0.7 → netra_zen-1.0.8}/README.md +166 -6
- {netra_zen-1.0.7 → netra_zen-1.0.8/netra_zen.egg-info}/PKG-INFO +172 -7
- {netra_zen-1.0.7 → netra_zen-1.0.8}/netra_zen.egg-info/SOURCES.txt +1 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/netra_zen.egg-info/requires.txt +5 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/pyproject.toml +6 -1
- {netra_zen-1.0.7 → netra_zen-1.0.8}/requirements.txt +5 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/agent_cli.py +195 -23
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/agent_logs.py +93 -15
- netra_zen-1.0.8/scripts/verify_log_transmission.py +140 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/setup.py +6 -1
- {netra_zen-1.0.7 → netra_zen-1.0.8}/LICENSE.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/MANIFEST.in +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/agent_interface/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/agent_interface/base_agent.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/config_example.json +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/CACHE_TOKENS_GUIDE.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/Cost_allocation.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/DOLLAR_BUDGET_USAGE_EXAMPLES.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/EXAMPLES.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/MODEL_COLUMN_GUIDE.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/apex_integration_test_plan.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/docs/zen_agent_cli_parallel_plan.md +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/netra_zen.egg-info/dependency_links.txt +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/netra_zen.egg-info/entry_points.txt +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/netra_zen.egg-info/top_level.txt +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/prebuilt_commands_example.json +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/requirements-dev.txt +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/__main__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/bump_version.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/demo_log_collection.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/scripts/embed_release_credentials.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/setup.cfg +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_agent_interface.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_agent_logs.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_apex_integration.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_cli_extensions.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_cli_integration.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_direct_command_execution.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_dollar_budget_enhancement.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_permission_fix_windows.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_pricing_engine.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_runner.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_workspace_detection.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_zen_commands.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_zen_integration.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_zen_metrics.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/tests/test_zen_unit.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_budget/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_budget/budget_manager.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_budget/models.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_budget/visualization.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_transparency/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/token_transparency/claude_pricing_engine.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen/__main__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen/telemetry/__init__.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen/telemetry/embedded_credentials.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen/telemetry/manager.py +0 -0
- {netra_zen-1.0.7 → netra_zen-1.0.8}/zen_orchestrator.py +0 -0
@@ -1,6 +1,6 @@
|
|
1
1
|
Metadata-Version: 2.4
|
2
2
|
Name: netra-zen
|
3
|
-
Version: 1.0.
|
3
|
+
Version: 1.0.8
|
4
4
|
Summary: Multi-instance Claude orchestrator for parallel task execution
|
5
5
|
Home-page: https://github.com/netra-systems/zen
|
6
6
|
Author: Systems
|
@@ -30,6 +30,11 @@ Description-Content-Type: text/markdown
|
|
30
30
|
License-File: LICENSE.md
|
31
31
|
Requires-Dist: PyYAML>=6.0
|
32
32
|
Requires-Dist: python-dateutil>=2.8.2
|
33
|
+
Requires-Dist: aiohttp>=3.8.0
|
34
|
+
Requires-Dist: websockets>=11.0
|
35
|
+
Requires-Dist: rich>=13.0.0
|
36
|
+
Requires-Dist: PyJWT>=2.8.0
|
37
|
+
Requires-Dist: psutil>=5.9.0
|
33
38
|
Requires-Dist: opentelemetry-sdk>=1.20.0
|
34
39
|
Requires-Dist: opentelemetry-exporter-gcp-trace>=1.6.0
|
35
40
|
Requires-Dist: google-cloud-trace>=1.11.0
|
@@ -55,17 +60,42 @@ It works by analyzing your usage logs for metadata optimizations. It is focused
|
|
55
60
|
|
56
61
|
This is a micro startup effort, aiming to provide real value for individual devs in exchange for feedback. Our intent is to charge businesses for larger scale optimizations.
|
57
62
|
|
58
|
-
The process is simple. One time install, then one command. It auto grabs the last
|
63
|
+
The process is simple. One time install, then one command. It auto grabs the last 3 log files and provides actionable items to update going forward to get the value of the optimizations.
|
59
64
|
|
60
65
|
## Quick start
|
61
66
|
|
62
67
|
1. `pip install netra-zen`
|
63
|
-
2. `zen --apex --send-logs
|
68
|
+
2. `zen --apex --send-logs`
|
64
69
|
3. Read the results and update claude settings, prompts, commands, etc. as needed to benefit
|
65
70
|
|
66
|
-
By default it will optimize based on logs no thought on the message is needed. Just copy and paste #2!
|
67
71
|
See detailed install below if needed.
|
68
72
|
|
73
|
+
### Log Collection Options
|
74
|
+
|
75
|
+
The optimizer analyzes your Claude Code usage logs to identify optimization opportunities. You can customize what logs are sent:
|
76
|
+
|
77
|
+
```bash
|
78
|
+
# Send logs from the 3 most recent files (default)
|
79
|
+
zen --apex --send-logs
|
80
|
+
|
81
|
+
# Send logs from more files for deeper analysis
|
82
|
+
zen --apex --send-logs --logs-count 5
|
83
|
+
|
84
|
+
# Send logs from a specific project
|
85
|
+
zen --apex --send-logs --logs-project "my-project-name"
|
86
|
+
|
87
|
+
# Send logs from a custom location
|
88
|
+
zen --apex --send-logs --logs-path "/path/to/.claude/Projects"
|
89
|
+
|
90
|
+
# Combine options for targeted analysis
|
91
|
+
zen --apex --send-logs --logs-count 3 --logs-project "production-app"
|
92
|
+
```
|
93
|
+
|
94
|
+
**Important:**
|
95
|
+
- `--logs-count` specifies the number of **files** to read, not entries
|
96
|
+
- Each file may contain many log entries
|
97
|
+
- The tool will display exactly how many entries from how many files are being sent
|
98
|
+
|
69
99
|
## Example output
|
70
100
|

|
71
101
|
|
@@ -75,12 +105,147 @@ See detailed install below if needed.
|
|
75
105
|
This was just changing a few small lines on a 400 line command.
|
76
106
|

|
77
107
|
|
108
|
+
## Notes
|
109
|
+
- Have an optimization idea or area you want it to focus on? Create a git issue and we can add that to our evals.
|
110
|
+
|
111
|
+
## Example output from single file
|
112
|
+
```
|
113
|
+
zen --apex --send-logs --logs-path /Users/user/.claude/projects/-Users-Desktop-netra-apex/7ac6d7ac-abc3-4903-a482-......-1.jsonl
|
114
|
+
|
115
|
+
SUCCESS: WebSocket connected successfully!
|
116
|
+
|
117
|
+
============================================================
|
118
|
+
📤 SENDING LOGS TO OPTIMIZER
|
119
|
+
============================================================
|
120
|
+
Total Entries: 781
|
121
|
+
Files Read: 1
|
122
|
+
Payload Size: 5.52 MB
|
123
|
+
|
124
|
+
Files:
|
125
|
+
• 7ac6d7ac-abc3-4903-a482-.....jsonl (hash: 908dbc51, 781 entries)
|
126
|
+
|
127
|
+
Payload Confirmation:
|
128
|
+
✓ 'jsonl_logs' key added to payload
|
129
|
+
✓ First log entry timestamp: 2025-10-03T18:26:02.089Z
|
130
|
+
✓ Last log entry timestamp: 2025-10-03T19:31:21.876Z
|
131
|
+
============================================================
|
132
|
+
|
133
|
+
[11:32:55.190] [DEBUG] GOLDEN PATH TRACE: Prepared WebSocket payload for run_id=cli_20251008_113255_25048,
|
134
|
+
thread_id=cli_thread_f887c58e7759
|
135
|
+
[11:32:55.191] [DEBUG] ✓ TRANSMISSION PROOF: Payload contains 781 JSONL log entries in 'jsonl_logs' key
|
136
|
+
SUCCESS: Message sent with run_id: cli_20251008_113255_25048
|
137
|
+
⏳ Waiting 120 seconds for events...
|
138
|
+
Receiving events...
|
139
|
+
[11:32:55.284] [DEBUG] Listening for WebSocket events...
|
140
|
+
[11:32:55.284] [DEBUG] GOLDEN PATH TRACE: Event listener started after successful connection
|
141
|
+
[11:32:56.655] [DEBUG] WebSocket Event #1: raw_message_received
|
142
|
+
[11:32:56.657] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=connection_established
|
143
|
+
[11:32:56.658] [DEBUG] WebSocket Event #2: connection_established
|
144
|
+
[11:32:56] [CONN] Connected as: e2e-staging-2d677771
|
145
|
+
[11:33:01.364] [DEBUG] WebSocket Event #3: raw_message_received
|
146
|
+
[11:33:01.366] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=thread_created
|
147
|
+
[11:33:01.367] [DEBUG] WebSocket Event #4: thread_created
|
148
|
+
[11:33:01] [EVENT] thread_created: {"type": "thread_created", "payload": {"thread_id":
|
149
|
+
"thread_session_969_44184cce", "timestamp": 1759...
|
150
|
+
[11:33:02.901] [DEBUG] WebSocket Event #5: raw_message_received
|
151
|
+
[11:33:02.903] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
152
|
+
[11:33:02.904] [DEBUG] WebSocket Event #6: agent_started
|
153
|
+
[11:33:02] 🧠 Agent: netra-assistant started (run: run_sess...)
|
154
|
+
[11:33:04.744] [DEBUG] WebSocket Event #7: raw_message_received
|
155
|
+
[11:33:04.746] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
156
|
+
[11:33:04.747] [DEBUG] WebSocket Event #8: agent_started
|
157
|
+
[11:33:04] 🧠 Agent: netra-assistant started (run: run_sess...)
|
158
|
+
[11:33:06.366] [DEBUG] WebSocket Event #9: raw_message_received
|
159
|
+
[11:33:06.368] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
160
|
+
[11:33:06.369] [DEBUG] WebSocket Event #10: agent_started
|
161
|
+
[11:33:06] 🧠 Agent: MessageHandler started (run: run_sess...)
|
162
|
+
[11:33:14.781] [DEBUG] WebSocket Event #11: raw_message_received
|
163
|
+
[11:33:14.783] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
164
|
+
[11:33:14.784] [DEBUG] WebSocket Event #12: agent_started
|
165
|
+
[11:33:14] 🧠 Agent: claude_code_optimizer started (run: run_sess...)
|
166
|
+
[11:33:23.241] [DEBUG] WebSocket Event #13: raw_message_received
|
167
|
+
[11:33:23.243] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_thinking
|
168
|
+
[11:33:23.244] [DEBUG] WebSocket Event #14: agent_thinking
|
169
|
+
[11:33:23] 💭 Thinking: Preparing optimization prompt
|
170
|
+
⠹ 💭 Preparing optimization prompt[11:34:27.586] [DEBUG] WebSocket Event #15: raw_message_received
|
171
|
+
[11:34:27.588] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_completed
|
172
|
+
[11:34:27.589] [DEBUG] WebSocket Event #16: agent_completed
|
173
|
+
⠹ 💭 Preparing optimization prompt
|
174
|
+
[11:34:27] 🧠 Agent Completed: claude_code_optimizer (run: run_sess...) - {"status": "done", "result":
|
175
|
+
{"optimizations": [{"issue": "Repeated Full File Read", "evidence": "Th...
|
176
|
+
╭────────────────────────────────── Final Agent Result - Optimization Pointers ──────────────────────────────────╮
|
177
|
+
│ { │
|
178
|
+
│ "status": "done", │
|
179
|
+
│ "result": { │
|
180
|
+
│ "optimizations": [ │
|
181
|
+
│ { │
|
182
|
+
│ "issue": "Repeated Full File Read", │
|
183
|
+
│ "evidence": "The file `api/src/routes/user.js` was read in its entirety using `cat` twice. The model │
|
184
|
+
│ read it once to understand the code, but then read the entire file again later to re-confirm a detail it had │
|
185
|
+
│ forgotten.", │
|
186
|
+
│ "token_waste": "High (~2.5k tokens). The entire content of the 250-line file was added to the context │
|
187
|
+
│ a second time, providing no new information.", │
|
188
|
+
│ "fix": "The model should retain the context of files it has already read within the same task. If it │
|
189
|
+
│ needs to re-check a specific detail, it should use a targeted tool like `grep` or `read_lines` (e.g., `grep -C │
|
190
|
+
│ 5 'findUser' api/src/routes/user.js`) instead of re-reading the entire file.", │
|
191
|
+
│ "ideal prompt": "The user profile page isn't loading the user's name. The API endpoint is in │
|
192
|
+
│ `api/src/routes/user.js` and it calls the `findUser` function from `api/src/db/utils.js`. Please investigate │
|
193
|
+
│ the data flow between these two files and fix the issue.", │
|
194
|
+
│ "priority": "high" │
|
195
|
+
│ }, │
|
196
|
+
│ { │
|
197
|
+
│ "issue": "Excessive Context Gathering", │
|
198
|
+
│ "evidence": "The `cat` command was used on two large files (`user.js` and `utils.js`), ingesting a │
|
199
|
+
│ total of 400 lines of code into the context. The actual bug was confined to a small 5-line function within │
|
200
|
+
│ `utils.js`.", │
|
201
|
+
│ "token_waste": "High (~4k tokens). Most of the file content was irrelevant to the specific task of │
|
202
|
+
│ fixing the `findUser` function's return value.", │
|
203
|
+
│ "fix": "Instead of `cat`, the model should use more precise tools to gather context. After identifying │
|
204
|
+
│ the relevant function with `grep`, it could have used a command like `read_lines('api/src/db/utils.js', │
|
205
|
+
│ start_line, end_line)` or `grep -A 10 'const findUser' api/src/db/utils.js` to read only the function's │
|
206
|
+
│ definition and its immediate surroundings.", │
|
207
|
+
│ "ideal prompt": "The `findUser` function in `api/src/db/utils.js` is not returning the user's name │
|
208
|
+
│ field. Please add it to the return object.", │
|
209
|
+
│ "priority": "high" │
|
210
|
+
│ }, │
|
211
|
+
│ { │
|
212
|
+
│ "issue": "Inefficient Project-Wide Search", │
|
213
|
+
│ "evidence": "A recursive grep (`grep -r \"findUser\" .`) was used to find the definition of │
|
214
|
+
│ `findUser`. While effective, this can be slow and return a lot of irrelevant matches (like comments, logs, │
|
215
|
+
│ etc.) in a large codebase, consuming tokens in the tool output.", │
|
216
|
+
│ "token_waste": "Medium (~500 tokens). The `grep` returned multiple matches, including the call site │
|
217
|
+
│ which was already known. In a larger project, this could return dozens of matches.", │
|
218
|
+
│ "fix": "If the project structure is conventional, a more targeted search would be better. For example, │
|
219
|
+
│ knowing `db` utilities are likely in a `db` or `utils` directory, a command like `grep 'findUser' │
|
220
|
+
│ api/src/db/*.js` would be more direct and produce less noise.", │
|
221
|
+
│ "ideal prompt": "The `findUser` function, defined in the `api/src/db/` directory, seems to be causing │
|
222
|
+
│ a bug. Can you find its definition and check what it returns?", │
|
223
|
+
│ "priority": "low" │
|
224
|
+
│ } │
|
225
|
+
│ ], │
|
226
|
+
│ "summary": { │
|
227
|
+
│ "total_issues": 3, │
|
228
|
+
│ "estimated_savings": "~7k tokens", │
|
229
|
+
│ "top_priority": "Avoid repeated full file reads. The model should trust its context or use targeted │
|
230
|
+
│ tools like `grep` to refresh specific details instead of re-ingesting entire files." │
|
231
|
+
│ } │
|
232
|
+
│ }, │
|
233
|
+
│ "message": "Claude Code optimization analysis complete" │
|
234
|
+
│ } │
|
235
|
+
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
|
236
|
+
|
237
|
+
📊 Received 8 events
|
238
|
+
```
|
239
|
+
|
240
|
+
# Advanced features & detailed install guide
|
241
|
+
|
242
|
+
In addition to optimizing your costs and latency,
|
243
|
+
you can control budgets and other advanced features.
|
78
244
|
|
79
|
-
# Other features & detailed install guide
|
80
245
|
### Orchestrator
|
81
246
|
|
82
|
-
|
83
|
-
-
|
247
|
+
Orchestrator allows you to:
|
248
|
+
- Orchestrator runs multiple Code CLI instances for peaceful parallel task execution.
|
84
249
|
- Run multiple headless Claude Code CLI instances simultaneously.
|
85
250
|
- Calm unified results (status, time, token usage)
|
86
251
|
- Relax **"5-hour limit reached"** lockout fears with easy token budget limits
|
@@ -6,17 +6,42 @@ It works by analyzing your usage logs for metadata optimizations. It is focused
|
|
6
6
|
|
7
7
|
This is a micro startup effort, aiming to provide real value for individual devs in exchange for feedback. Our intent is to charge businesses for larger scale optimizations.
|
8
8
|
|
9
|
-
The process is simple. One time install, then one command. It auto grabs the last
|
9
|
+
The process is simple. One time install, then one command. It auto grabs the last 3 log files and provides actionable items to update going forward to get the value of the optimizations.
|
10
10
|
|
11
11
|
## Quick start
|
12
12
|
|
13
13
|
1. `pip install netra-zen`
|
14
|
-
2. `zen --apex --send-logs
|
14
|
+
2. `zen --apex --send-logs`
|
15
15
|
3. Read the results and update claude settings, prompts, commands, etc. as needed to benefit
|
16
16
|
|
17
|
-
By default it will optimize based on logs no thought on the message is needed. Just copy and paste #2!
|
18
17
|
See detailed install below if needed.
|
19
18
|
|
19
|
+
### Log Collection Options
|
20
|
+
|
21
|
+
The optimizer analyzes your Claude Code usage logs to identify optimization opportunities. You can customize what logs are sent:
|
22
|
+
|
23
|
+
```bash
|
24
|
+
# Send logs from the 3 most recent files (default)
|
25
|
+
zen --apex --send-logs
|
26
|
+
|
27
|
+
# Send logs from more files for deeper analysis
|
28
|
+
zen --apex --send-logs --logs-count 5
|
29
|
+
|
30
|
+
# Send logs from a specific project
|
31
|
+
zen --apex --send-logs --logs-project "my-project-name"
|
32
|
+
|
33
|
+
# Send logs from a custom location
|
34
|
+
zen --apex --send-logs --logs-path "/path/to/.claude/Projects"
|
35
|
+
|
36
|
+
# Combine options for targeted analysis
|
37
|
+
zen --apex --send-logs --logs-count 3 --logs-project "production-app"
|
38
|
+
```
|
39
|
+
|
40
|
+
**Important:**
|
41
|
+
- `--logs-count` specifies the number of **files** to read, not entries
|
42
|
+
- Each file may contain many log entries
|
43
|
+
- The tool will display exactly how many entries from how many files are being sent
|
44
|
+
|
20
45
|
## Example output
|
21
46
|

|
22
47
|
|
@@ -26,12 +51,147 @@ See detailed install below if needed.
|
|
26
51
|
This was just changing a few small lines on a 400 line command.
|
27
52
|

|
28
53
|
|
54
|
+
## Notes
|
55
|
+
- Have an optimization idea or area you want it to focus on? Create a git issue and we can add that to our evals.
|
56
|
+
|
57
|
+
## Example output from single file
|
58
|
+
```
|
59
|
+
zen --apex --send-logs --logs-path /Users/user/.claude/projects/-Users-Desktop-netra-apex/7ac6d7ac-abc3-4903-a482-......-1.jsonl
|
60
|
+
|
61
|
+
SUCCESS: WebSocket connected successfully!
|
62
|
+
|
63
|
+
============================================================
|
64
|
+
📤 SENDING LOGS TO OPTIMIZER
|
65
|
+
============================================================
|
66
|
+
Total Entries: 781
|
67
|
+
Files Read: 1
|
68
|
+
Payload Size: 5.52 MB
|
69
|
+
|
70
|
+
Files:
|
71
|
+
• 7ac6d7ac-abc3-4903-a482-.....jsonl (hash: 908dbc51, 781 entries)
|
72
|
+
|
73
|
+
Payload Confirmation:
|
74
|
+
✓ 'jsonl_logs' key added to payload
|
75
|
+
✓ First log entry timestamp: 2025-10-03T18:26:02.089Z
|
76
|
+
✓ Last log entry timestamp: 2025-10-03T19:31:21.876Z
|
77
|
+
============================================================
|
78
|
+
|
79
|
+
[11:32:55.190] [DEBUG] GOLDEN PATH TRACE: Prepared WebSocket payload for run_id=cli_20251008_113255_25048,
|
80
|
+
thread_id=cli_thread_f887c58e7759
|
81
|
+
[11:32:55.191] [DEBUG] ✓ TRANSMISSION PROOF: Payload contains 781 JSONL log entries in 'jsonl_logs' key
|
82
|
+
SUCCESS: Message sent with run_id: cli_20251008_113255_25048
|
83
|
+
⏳ Waiting 120 seconds for events...
|
84
|
+
Receiving events...
|
85
|
+
[11:32:55.284] [DEBUG] Listening for WebSocket events...
|
86
|
+
[11:32:55.284] [DEBUG] GOLDEN PATH TRACE: Event listener started after successful connection
|
87
|
+
[11:32:56.655] [DEBUG] WebSocket Event #1: raw_message_received
|
88
|
+
[11:32:56.657] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=connection_established
|
89
|
+
[11:32:56.658] [DEBUG] WebSocket Event #2: connection_established
|
90
|
+
[11:32:56] [CONN] Connected as: e2e-staging-2d677771
|
91
|
+
[11:33:01.364] [DEBUG] WebSocket Event #3: raw_message_received
|
92
|
+
[11:33:01.366] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=thread_created
|
93
|
+
[11:33:01.367] [DEBUG] WebSocket Event #4: thread_created
|
94
|
+
[11:33:01] [EVENT] thread_created: {"type": "thread_created", "payload": {"thread_id":
|
95
|
+
"thread_session_969_44184cce", "timestamp": 1759...
|
96
|
+
[11:33:02.901] [DEBUG] WebSocket Event #5: raw_message_received
|
97
|
+
[11:33:02.903] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
98
|
+
[11:33:02.904] [DEBUG] WebSocket Event #6: agent_started
|
99
|
+
[11:33:02] 🧠 Agent: netra-assistant started (run: run_sess...)
|
100
|
+
[11:33:04.744] [DEBUG] WebSocket Event #7: raw_message_received
|
101
|
+
[11:33:04.746] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
102
|
+
[11:33:04.747] [DEBUG] WebSocket Event #8: agent_started
|
103
|
+
[11:33:04] 🧠 Agent: netra-assistant started (run: run_sess...)
|
104
|
+
[11:33:06.366] [DEBUG] WebSocket Event #9: raw_message_received
|
105
|
+
[11:33:06.368] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
106
|
+
[11:33:06.369] [DEBUG] WebSocket Event #10: agent_started
|
107
|
+
[11:33:06] 🧠 Agent: MessageHandler started (run: run_sess...)
|
108
|
+
[11:33:14.781] [DEBUG] WebSocket Event #11: raw_message_received
|
109
|
+
[11:33:14.783] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
110
|
+
[11:33:14.784] [DEBUG] WebSocket Event #12: agent_started
|
111
|
+
[11:33:14] 🧠 Agent: claude_code_optimizer started (run: run_sess...)
|
112
|
+
[11:33:23.241] [DEBUG] WebSocket Event #13: raw_message_received
|
113
|
+
[11:33:23.243] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_thinking
|
114
|
+
[11:33:23.244] [DEBUG] WebSocket Event #14: agent_thinking
|
115
|
+
[11:33:23] 💭 Thinking: Preparing optimization prompt
|
116
|
+
⠹ 💭 Preparing optimization prompt[11:34:27.586] [DEBUG] WebSocket Event #15: raw_message_received
|
117
|
+
[11:34:27.588] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_completed
|
118
|
+
[11:34:27.589] [DEBUG] WebSocket Event #16: agent_completed
|
119
|
+
⠹ 💭 Preparing optimization prompt
|
120
|
+
[11:34:27] 🧠 Agent Completed: claude_code_optimizer (run: run_sess...) - {"status": "done", "result":
|
121
|
+
{"optimizations": [{"issue": "Repeated Full File Read", "evidence": "Th...
|
122
|
+
╭────────────────────────────────── Final Agent Result - Optimization Pointers ──────────────────────────────────╮
|
123
|
+
│ { │
|
124
|
+
│ "status": "done", │
|
125
|
+
│ "result": { │
|
126
|
+
│ "optimizations": [ │
|
127
|
+
│ { │
|
128
|
+
│ "issue": "Repeated Full File Read", │
|
129
|
+
│ "evidence": "The file `api/src/routes/user.js` was read in its entirety using `cat` twice. The model │
|
130
|
+
│ read it once to understand the code, but then read the entire file again later to re-confirm a detail it had │
|
131
|
+
│ forgotten.", │
|
132
|
+
│ "token_waste": "High (~2.5k tokens). The entire content of the 250-line file was added to the context │
|
133
|
+
│ a second time, providing no new information.", │
|
134
|
+
│ "fix": "The model should retain the context of files it has already read within the same task. If it │
|
135
|
+
│ needs to re-check a specific detail, it should use a targeted tool like `grep` or `read_lines` (e.g., `grep -C │
|
136
|
+
│ 5 'findUser' api/src/routes/user.js`) instead of re-reading the entire file.", │
|
137
|
+
│ "ideal prompt": "The user profile page isn't loading the user's name. The API endpoint is in │
|
138
|
+
│ `api/src/routes/user.js` and it calls the `findUser` function from `api/src/db/utils.js`. Please investigate │
|
139
|
+
│ the data flow between these two files and fix the issue.", │
|
140
|
+
│ "priority": "high" │
|
141
|
+
│ }, │
|
142
|
+
│ { │
|
143
|
+
│ "issue": "Excessive Context Gathering", │
|
144
|
+
│ "evidence": "The `cat` command was used on two large files (`user.js` and `utils.js`), ingesting a │
|
145
|
+
│ total of 400 lines of code into the context. The actual bug was confined to a small 5-line function within │
|
146
|
+
│ `utils.js`.", │
|
147
|
+
│ "token_waste": "High (~4k tokens). Most of the file content was irrelevant to the specific task of │
|
148
|
+
│ fixing the `findUser` function's return value.", │
|
149
|
+
│ "fix": "Instead of `cat`, the model should use more precise tools to gather context. After identifying │
|
150
|
+
│ the relevant function with `grep`, it could have used a command like `read_lines('api/src/db/utils.js', │
|
151
|
+
│ start_line, end_line)` or `grep -A 10 'const findUser' api/src/db/utils.js` to read only the function's │
|
152
|
+
│ definition and its immediate surroundings.", │
|
153
|
+
│ "ideal prompt": "The `findUser` function in `api/src/db/utils.js` is not returning the user's name │
|
154
|
+
│ field. Please add it to the return object.", │
|
155
|
+
│ "priority": "high" │
|
156
|
+
│ }, │
|
157
|
+
│ { │
|
158
|
+
│ "issue": "Inefficient Project-Wide Search", │
|
159
|
+
│ "evidence": "A recursive grep (`grep -r \"findUser\" .`) was used to find the definition of │
|
160
|
+
│ `findUser`. While effective, this can be slow and return a lot of irrelevant matches (like comments, logs, │
|
161
|
+
│ etc.) in a large codebase, consuming tokens in the tool output.", │
|
162
|
+
│ "token_waste": "Medium (~500 tokens). The `grep` returned multiple matches, including the call site │
|
163
|
+
│ which was already known. In a larger project, this could return dozens of matches.", │
|
164
|
+
│ "fix": "If the project structure is conventional, a more targeted search would be better. For example, │
|
165
|
+
│ knowing `db` utilities are likely in a `db` or `utils` directory, a command like `grep 'findUser' │
|
166
|
+
│ api/src/db/*.js` would be more direct and produce less noise.", │
|
167
|
+
│ "ideal prompt": "The `findUser` function, defined in the `api/src/db/` directory, seems to be causing │
|
168
|
+
│ a bug. Can you find its definition and check what it returns?", │
|
169
|
+
│ "priority": "low" │
|
170
|
+
│ } │
|
171
|
+
│ ], │
|
172
|
+
│ "summary": { │
|
173
|
+
│ "total_issues": 3, │
|
174
|
+
│ "estimated_savings": "~7k tokens", │
|
175
|
+
│ "top_priority": "Avoid repeated full file reads. The model should trust its context or use targeted │
|
176
|
+
│ tools like `grep` to refresh specific details instead of re-ingesting entire files." │
|
177
|
+
│ } │
|
178
|
+
│ }, │
|
179
|
+
│ "message": "Claude Code optimization analysis complete" │
|
180
|
+
│ } │
|
181
|
+
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
|
182
|
+
|
183
|
+
📊 Received 8 events
|
184
|
+
```
|
185
|
+
|
186
|
+
# Advanced features & detailed install guide
|
187
|
+
|
188
|
+
In addition to optimizing your costs and latency,
|
189
|
+
you can control budgets and other advanced features.
|
29
190
|
|
30
|
-
# Other features & detailed install guide
|
31
191
|
### Orchestrator
|
32
192
|
|
33
|
-
|
34
|
-
-
|
193
|
+
Orchestrator allows you to:
|
194
|
+
- Orchestrator runs multiple Code CLI instances for peaceful parallel task execution.
|
35
195
|
- Run multiple headless Claude Code CLI instances simultaneously.
|
36
196
|
- Calm unified results (status, time, token usage)
|
37
197
|
- Relax **"5-hour limit reached"** lockout fears with easy token budget limits
|
@@ -1,6 +1,6 @@
|
|
1
1
|
Metadata-Version: 2.4
|
2
2
|
Name: netra-zen
|
3
|
-
Version: 1.0.
|
3
|
+
Version: 1.0.8
|
4
4
|
Summary: Multi-instance Claude orchestrator for parallel task execution
|
5
5
|
Home-page: https://github.com/netra-systems/zen
|
6
6
|
Author: Systems
|
@@ -30,6 +30,11 @@ Description-Content-Type: text/markdown
|
|
30
30
|
License-File: LICENSE.md
|
31
31
|
Requires-Dist: PyYAML>=6.0
|
32
32
|
Requires-Dist: python-dateutil>=2.8.2
|
33
|
+
Requires-Dist: aiohttp>=3.8.0
|
34
|
+
Requires-Dist: websockets>=11.0
|
35
|
+
Requires-Dist: rich>=13.0.0
|
36
|
+
Requires-Dist: PyJWT>=2.8.0
|
37
|
+
Requires-Dist: psutil>=5.9.0
|
33
38
|
Requires-Dist: opentelemetry-sdk>=1.20.0
|
34
39
|
Requires-Dist: opentelemetry-exporter-gcp-trace>=1.6.0
|
35
40
|
Requires-Dist: google-cloud-trace>=1.11.0
|
@@ -55,17 +60,42 @@ It works by analyzing your usage logs for metadata optimizations. It is focused
|
|
55
60
|
|
56
61
|
This is a micro startup effort, aiming to provide real value for individual devs in exchange for feedback. Our intent is to charge businesses for larger scale optimizations.
|
57
62
|
|
58
|
-
The process is simple. One time install, then one command. It auto grabs the last
|
63
|
+
The process is simple. One time install, then one command. It auto grabs the last 3 log files and provides actionable items to update going forward to get the value of the optimizations.
|
59
64
|
|
60
65
|
## Quick start
|
61
66
|
|
62
67
|
1. `pip install netra-zen`
|
63
|
-
2. `zen --apex --send-logs
|
68
|
+
2. `zen --apex --send-logs`
|
64
69
|
3. Read the results and update claude settings, prompts, commands, etc. as needed to benefit
|
65
70
|
|
66
|
-
By default it will optimize based on logs no thought on the message is needed. Just copy and paste #2!
|
67
71
|
See detailed install below if needed.
|
68
72
|
|
73
|
+
### Log Collection Options
|
74
|
+
|
75
|
+
The optimizer analyzes your Claude Code usage logs to identify optimization opportunities. You can customize what logs are sent:
|
76
|
+
|
77
|
+
```bash
|
78
|
+
# Send logs from the 3 most recent files (default)
|
79
|
+
zen --apex --send-logs
|
80
|
+
|
81
|
+
# Send logs from more files for deeper analysis
|
82
|
+
zen --apex --send-logs --logs-count 5
|
83
|
+
|
84
|
+
# Send logs from a specific project
|
85
|
+
zen --apex --send-logs --logs-project "my-project-name"
|
86
|
+
|
87
|
+
# Send logs from a custom location
|
88
|
+
zen --apex --send-logs --logs-path "/path/to/.claude/Projects"
|
89
|
+
|
90
|
+
# Combine options for targeted analysis
|
91
|
+
zen --apex --send-logs --logs-count 3 --logs-project "production-app"
|
92
|
+
```
|
93
|
+
|
94
|
+
**Important:**
|
95
|
+
- `--logs-count` specifies the number of **files** to read, not entries
|
96
|
+
- Each file may contain many log entries
|
97
|
+
- The tool will display exactly how many entries from how many files are being sent
|
98
|
+
|
69
99
|
## Example output
|
70
100
|

|
71
101
|
|
@@ -75,12 +105,147 @@ See detailed install below if needed.
|
|
75
105
|
This was just changing a few small lines on a 400 line command.
|
76
106
|

|
77
107
|
|
108
|
+
## Notes
|
109
|
+
- Have an optimization idea or area you want it to focus on? Create a git issue and we can add that to our evals.
|
110
|
+
|
111
|
+
## Example output from single file
|
112
|
+
```
|
113
|
+
zen --apex --send-logs --logs-path /Users/user/.claude/projects/-Users-Desktop-netra-apex/7ac6d7ac-abc3-4903-a482-......-1.jsonl
|
114
|
+
|
115
|
+
SUCCESS: WebSocket connected successfully!
|
116
|
+
|
117
|
+
============================================================
|
118
|
+
📤 SENDING LOGS TO OPTIMIZER
|
119
|
+
============================================================
|
120
|
+
Total Entries: 781
|
121
|
+
Files Read: 1
|
122
|
+
Payload Size: 5.52 MB
|
123
|
+
|
124
|
+
Files:
|
125
|
+
• 7ac6d7ac-abc3-4903-a482-.....jsonl (hash: 908dbc51, 781 entries)
|
126
|
+
|
127
|
+
Payload Confirmation:
|
128
|
+
✓ 'jsonl_logs' key added to payload
|
129
|
+
✓ First log entry timestamp: 2025-10-03T18:26:02.089Z
|
130
|
+
✓ Last log entry timestamp: 2025-10-03T19:31:21.876Z
|
131
|
+
============================================================
|
132
|
+
|
133
|
+
[11:32:55.190] [DEBUG] GOLDEN PATH TRACE: Prepared WebSocket payload for run_id=cli_20251008_113255_25048,
|
134
|
+
thread_id=cli_thread_f887c58e7759
|
135
|
+
[11:32:55.191] [DEBUG] ✓ TRANSMISSION PROOF: Payload contains 781 JSONL log entries in 'jsonl_logs' key
|
136
|
+
SUCCESS: Message sent with run_id: cli_20251008_113255_25048
|
137
|
+
⏳ Waiting 120 seconds for events...
|
138
|
+
Receiving events...
|
139
|
+
[11:32:55.284] [DEBUG] Listening for WebSocket events...
|
140
|
+
[11:32:55.284] [DEBUG] GOLDEN PATH TRACE: Event listener started after successful connection
|
141
|
+
[11:32:56.655] [DEBUG] WebSocket Event #1: raw_message_received
|
142
|
+
[11:32:56.657] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=connection_established
|
143
|
+
[11:32:56.658] [DEBUG] WebSocket Event #2: connection_established
|
144
|
+
[11:32:56] [CONN] Connected as: e2e-staging-2d677771
|
145
|
+
[11:33:01.364] [DEBUG] WebSocket Event #3: raw_message_received
|
146
|
+
[11:33:01.366] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=thread_created
|
147
|
+
[11:33:01.367] [DEBUG] WebSocket Event #4: thread_created
|
148
|
+
[11:33:01] [EVENT] thread_created: {"type": "thread_created", "payload": {"thread_id":
|
149
|
+
"thread_session_969_44184cce", "timestamp": 1759...
|
150
|
+
[11:33:02.901] [DEBUG] WebSocket Event #5: raw_message_received
|
151
|
+
[11:33:02.903] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
152
|
+
[11:33:02.904] [DEBUG] WebSocket Event #6: agent_started
|
153
|
+
[11:33:02] 🧠 Agent: netra-assistant started (run: run_sess...)
|
154
|
+
[11:33:04.744] [DEBUG] WebSocket Event #7: raw_message_received
|
155
|
+
[11:33:04.746] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
156
|
+
[11:33:04.747] [DEBUG] WebSocket Event #8: agent_started
|
157
|
+
[11:33:04] 🧠 Agent: netra-assistant started (run: run_sess...)
|
158
|
+
[11:33:06.366] [DEBUG] WebSocket Event #9: raw_message_received
|
159
|
+
[11:33:06.368] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
160
|
+
[11:33:06.369] [DEBUG] WebSocket Event #10: agent_started
|
161
|
+
[11:33:06] 🧠 Agent: MessageHandler started (run: run_sess...)
|
162
|
+
[11:33:14.781] [DEBUG] WebSocket Event #11: raw_message_received
|
163
|
+
[11:33:14.783] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_started
|
164
|
+
[11:33:14.784] [DEBUG] WebSocket Event #12: agent_started
|
165
|
+
[11:33:14] 🧠 Agent: claude_code_optimizer started (run: run_sess...)
|
166
|
+
[11:33:23.241] [DEBUG] WebSocket Event #13: raw_message_received
|
167
|
+
[11:33:23.243] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_thinking
|
168
|
+
[11:33:23.244] [DEBUG] WebSocket Event #14: agent_thinking
|
169
|
+
[11:33:23] 💭 Thinking: Preparing optimization prompt
|
170
|
+
⠹ 💭 Preparing optimization prompt[11:34:27.586] [DEBUG] WebSocket Event #15: raw_message_received
|
171
|
+
[11:34:27.588] [DEBUG] GOLDEN PATH TRACE: Parsed WebSocket event type=agent_completed
|
172
|
+
[11:34:27.589] [DEBUG] WebSocket Event #16: agent_completed
|
173
|
+
⠹ 💭 Preparing optimization prompt
|
174
|
+
[11:34:27] 🧠 Agent Completed: claude_code_optimizer (run: run_sess...) - {"status": "done", "result":
|
175
|
+
{"optimizations": [{"issue": "Repeated Full File Read", "evidence": "Th...
|
176
|
+
╭────────────────────────────────── Final Agent Result - Optimization Pointers ──────────────────────────────────╮
|
177
|
+
│ { │
|
178
|
+
│ "status": "done", │
|
179
|
+
│ "result": { │
|
180
|
+
│ "optimizations": [ │
|
181
|
+
│ { │
|
182
|
+
│ "issue": "Repeated Full File Read", │
|
183
|
+
│ "evidence": "The file `api/src/routes/user.js` was read in its entirety using `cat` twice. The model │
|
184
|
+
│ read it once to understand the code, but then read the entire file again later to re-confirm a detail it had │
|
185
|
+
│ forgotten.", │
|
186
|
+
│ "token_waste": "High (~2.5k tokens). The entire content of the 250-line file was added to the context │
|
187
|
+
│ a second time, providing no new information.", │
|
188
|
+
│ "fix": "The model should retain the context of files it has already read within the same task. If it │
|
189
|
+
│ needs to re-check a specific detail, it should use a targeted tool like `grep` or `read_lines` (e.g., `grep -C │
|
190
|
+
│ 5 'findUser' api/src/routes/user.js`) instead of re-reading the entire file.", │
|
191
|
+
│ "ideal prompt": "The user profile page isn't loading the user's name. The API endpoint is in │
|
192
|
+
│ `api/src/routes/user.js` and it calls the `findUser` function from `api/src/db/utils.js`. Please investigate │
|
193
|
+
│ the data flow between these two files and fix the issue.", │
|
194
|
+
│ "priority": "high" │
|
195
|
+
│ }, │
|
196
|
+
│ { │
|
197
|
+
│ "issue": "Excessive Context Gathering", │
|
198
|
+
│ "evidence": "The `cat` command was used on two large files (`user.js` and `utils.js`), ingesting a │
|
199
|
+
│ total of 400 lines of code into the context. The actual bug was confined to a small 5-line function within │
|
200
|
+
│ `utils.js`.", │
|
201
|
+
│ "token_waste": "High (~4k tokens). Most of the file content was irrelevant to the specific task of │
|
202
|
+
│ fixing the `findUser` function's return value.", │
|
203
|
+
│ "fix": "Instead of `cat`, the model should use more precise tools to gather context. After identifying │
|
204
|
+
│ the relevant function with `grep`, it could have used a command like `read_lines('api/src/db/utils.js', │
|
205
|
+
│ start_line, end_line)` or `grep -A 10 'const findUser' api/src/db/utils.js` to read only the function's │
|
206
|
+
│ definition and its immediate surroundings.", │
|
207
|
+
│ "ideal prompt": "The `findUser` function in `api/src/db/utils.js` is not returning the user's name │
|
208
|
+
│ field. Please add it to the return object.", │
|
209
|
+
│ "priority": "high" │
|
210
|
+
│ }, │
|
211
|
+
│ { │
|
212
|
+
│ "issue": "Inefficient Project-Wide Search", │
|
213
|
+
│ "evidence": "A recursive grep (`grep -r \"findUser\" .`) was used to find the definition of │
|
214
|
+
│ `findUser`. While effective, this can be slow and return a lot of irrelevant matches (like comments, logs, │
|
215
|
+
│ etc.) in a large codebase, consuming tokens in the tool output.", │
|
216
|
+
│ "token_waste": "Medium (~500 tokens). The `grep` returned multiple matches, including the call site │
|
217
|
+
│ which was already known. In a larger project, this could return dozens of matches.", │
|
218
|
+
│ "fix": "If the project structure is conventional, a more targeted search would be better. For example, │
|
219
|
+
│ knowing `db` utilities are likely in a `db` or `utils` directory, a command like `grep 'findUser' │
|
220
|
+
│ api/src/db/*.js` would be more direct and produce less noise.", │
|
221
|
+
│ "ideal prompt": "The `findUser` function, defined in the `api/src/db/` directory, seems to be causing │
|
222
|
+
│ a bug. Can you find its definition and check what it returns?", │
|
223
|
+
│ "priority": "low" │
|
224
|
+
│ } │
|
225
|
+
│ ], │
|
226
|
+
│ "summary": { │
|
227
|
+
│ "total_issues": 3, │
|
228
|
+
│ "estimated_savings": "~7k tokens", │
|
229
|
+
│ "top_priority": "Avoid repeated full file reads. The model should trust its context or use targeted │
|
230
|
+
│ tools like `grep` to refresh specific details instead of re-ingesting entire files." │
|
231
|
+
│ } │
|
232
|
+
│ }, │
|
233
|
+
│ "message": "Claude Code optimization analysis complete" │
|
234
|
+
│ } │
|
235
|
+
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
|
236
|
+
|
237
|
+
📊 Received 8 events
|
238
|
+
```
|
239
|
+
|
240
|
+
# Advanced features & detailed install guide
|
241
|
+
|
242
|
+
In addition to optimizing your costs and latency,
|
243
|
+
you can control budgets and other advanced features.
|
78
244
|
|
79
|
-
# Other features & detailed install guide
|
80
245
|
### Orchestrator
|
81
246
|
|
82
|
-
|
83
|
-
-
|
247
|
+
Orchestrator allows you to:
|
248
|
+
- Orchestrator runs multiple Code CLI instances for peaceful parallel task execution.
|
84
249
|
- Run multiple headless Claude Code CLI instances simultaneously.
|
85
250
|
- Calm unified results (status, time, token usage)
|
86
251
|
- Relax **"5-hour limit reached"** lockout fears with easy token budget limits
|