DEEPSEEK_V4_FLASH_THINKING_LEVEL_MAP (which enables the low effort level)
was only applied to deepseek/deepseek-v4-flash, so the same model served
through opencode and opencode-go only offered off/high/max. models.dev
reports reasoning_options effort values of low/high/max for these
providers, and the live opencode-go API accepts reasoning_effort=low
(verified against https://opencode.ai/zen/go/v1).
Apply the flash map to every deepseek-v4-flash variant on the deepseek,
opencode, and opencode-go providers. qwen-token-plan is left unchanged
since its gateway support for the low effort level is not verified.
* feat(ai): route xAI models through Responses and default to Grok 4.6
Send built-in xAI catalog models through the Responses API with
store: false and include reasoning.encrypted_content so encrypted
reasoning is requested and replayed, including future models.dev
additions. Thinking levels come from models.dev reasoning_options
(grok-4.6 exposes xhigh); models without verified options
(grok-build-0.1) keep reasoning always on and never send unsupported
"none"/"minimal" efforts. Narrow the xAI provider to the Responses API,
send pi's runtime User-Agent on xAI requests for provider-side
attribution, and make Grok 4.6 the default xAI model.
* fix(ai): drop duplicate xAI encrypted-reasoning tests
Azure already covers the shared replay path; keep the xAI-specific include-without-effort case next to the existing request tests.
---------
Co-authored-by: Jaaneek <Jaaneek@users.noreply.github.com>
The login-time policy updates can drain the Copilot API rate-limit
bucket, in which case the follow-up GET /models is rejected with 429
(observed response: retry-after: 2, body 'too many requests') and login
aborts. Honor Retry-After and retry once instead of failing (#8121).
Batching policy POSTs at concurrency 4 still bursts 30 requests during
login, which trips the Copilot API rate limiter and makes the following
GET /models fail with 429, aborting login (#8121). Send the policy
updates one at a time instead.
TuiAltScreen.copySelectionToClipboard() wrote a bare OSC 52 sequence and
flashed "Copied!" unconditionally. Terminals that ignore OSC 52 clipboard
writes (macOS Terminal.app, VTE terminals, tmux without OSC 52 passthrough)
left the system clipboard untouched while the toast reported success.
Add an injectable copySelection option to TuiAltScreenOptions (an async
handler returning whether the copy succeeded) and use it when provided,
falling back to the existing OSC 52 write otherwise. The coding agent now
injects its native clipboard implementation (clipboard addon + pbcopy /
wl-copy / xclip / xsel), so selection copy reaches the real clipboard and
the toast only fires on verified success, with "Copy failed" otherwise.
Closes#7761
Co-authored-by: 富永 誠 <makoto@credify.one>
APP_NAME is derived from piConfig.name so a rebranded distribution shows
its own name, and roughly 90 call sites already use it. Twelve
user-facing strings hardcoded "pi" instead, so those messages named the
upstream binary regardless of piConfig.name:
- the trust project folder prompt
- "Restart pi for this to take effect." after a saved trust decision
- the "Start without extensions" hint on an extension load failure
- the invalid session file error
- the executable location in the self-update-unavailable notice
- the three auth command usage strings and the unknown auth command
error, which are printed next to `${APP_NAME} --help` in main.ts and
so contradicted it
- "is configured outside pi." in the provider setup dialog
- the uncaughtException line
Output is unchanged for pi itself: piConfig has no name, so APP_NAME
falls back to "pi".
`parseFrontmatter` runs a real YAML parser, so `tools: [read, bash]`
arrives as an array while `tools: read, bash` arrives as a string. The
loader only handled the string form and called `.split(",")`, which
throws on the array form.
The throw escapes `loadAgentsFromDir` -- only `readdirSync` and
`readFileSync` are guarded -- so one agent file using the array form
broke discovery for every agent in that scope, not just itself.
Normalize both spellings in one helper, and type the frontmatter fields
as `unknown` so the string assumptions are explicit. The previous
`parseFrontmatter<Record<string, string>>` annotation asserted a shape
the YAML parser never guarantees, which is what hid the mismatch from
tsc while `AgentConfig.tools` was already typed `string[]`.
Vegard Stikbakke