wayang-ai 0.5.0 → 0.5.2

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.
Files changed (3) hide show
  1. package/README.md +6 -3
  2. package/dist/cli.js +2361 -334
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -90,7 +90,8 @@ Or create `~/.wayang.config.json` manually:
90
90
  "my-model": {
91
91
  "endpoint": "https://api.anthropic.com",
92
92
  "modelName": "claude-sonnet-4-20250514",
93
- "apiKey": "xxx"
93
+ "apiKey": "xxx",
94
+ "contextWindowTokens": 200000
94
95
  }
95
96
  },
96
97
  "controller": { "provider": "my-model" },
@@ -100,10 +101,12 @@ Or create `~/.wayang.config.json` manually:
100
101
 
101
102
  API key can be set via config or the `WAYANG_LLM_API_KEY` environment variable.
102
103
 
103
- Workers default to `"toolChoice": "required"` — every step must emit a tool call, so a worker always finishes via its `done`/`fail` tools. Some OpenAI-compatible endpoints (e.g. internal llmproxy proxies) reject `tool_choice: "required"` with HTTP 400; for those, opt out per-endpoint in the `worker` section:
104
+ `contextWindowTokens` (optional, per provider) is the model's context window in tokens: the input budget the prompt must fit into, not the protocol's `max_tokens` output cap. The controller compacts the conversation once it reaches 90% of this budget. It defaults to 256000; set it explicitly for smaller-window models (e.g. `128000`), otherwise the provider rejects requests before compaction triggers. With env-only configuration use `WAYANG_CONTEXT_WINDOW_TOKENS`.
105
+
106
+ Workers default to `"toolChoice": "auto"` — the model decides whether to call a tool, since thinking endpoints (DeepSeek/GLM) reject `tool_choice: "required"` with HTTP 400. On endpoints that support it, set `"required"` to force a tool call every step, so a worker always finishes via its `done`/`fail` tools:
104
107
 
105
108
  ```json
106
- "worker": { "provider": "my-model", "maxConcurrency": 3, "toolChoice": "auto" }
109
+ "worker": { "provider": "my-model", "maxConcurrency": 3, "toolChoice": "required" }
107
110
  ```
108
111
 
109
112
  ### Run