Root cause of the GPT-account "empty turn: no text and no tool calls"
failures, found by replaying the real stored response: the CEO actually
called hire_agent five times, but the ChatGPT/Codex backend delivers each
output item in a response.output_item.done event and then sends a
response.completed whose response.output is []. accumulateResponsesStream
read only the completion event, so every tool call was discarded and the
turn parsed as empty — the run failed and the company never staffed.
Collect items from output_item.done and fall back to them when the
completion carries no output of its own; keep using the completion output
when it is populated (non-Codex Responses backends). Verified against the
real captured stream (5 hires recovered) and unit-tested with the exact
event shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The GPT-account (Codex) path supports tool calls and worked before; my
forced tool_choice broke it and was the wrong fix. The real regression was
strict:null in the rebuild's tool definitions, which made the endpoint drop
the tool list so the model had nothing to call — a "Done" run that hired no
one. Forcing then turned that silent failure into a red one.
Restore the original "auto" loop (no forced tool_choice, no finish tool) and
keep only the one-line strict:null omission. Codex now receives valid tools
on the working "auto" choice, as in the version that worked.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The gpt-account (Codex) turn built its function tools with strict:null. The
Responses API expects strict to be a boolean or omitted; null is malformed,
so the endpoint dropped the whole tool list — leaving the model with nothing
to call. That is exactly the "model returned no tool calls" failure on the
GPT-account path. Omit strict when null; keep the boolean otherwise. Locked
with a test, alongside the Bedrock/Gemini forced-tool-choice encoding.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Every catalog provider can now drive agent execution:
- Azure OpenAI -> Chat Completions at the deployment URL with api-key
- AWS Bedrock -> Converse API signed natively with SigV4 (node:crypto)
- Vertex AI -> Gemini generateContent with a service-account JWT (RS256)
exchanged for a cached access token
The credential resolver maps each cloud profile to the turn's needs; the router
covers all 16 providers. Pure encoders, the SigV4 signer and the GCP auth are
unit-tested; no AWS/GCP SDK dependency.
New 'Custom OpenAI-compatible' and 'Custom Anthropic-compatible' providers let
an agent run against any compatible endpoint by base URL + key: the turn posts
Chat Completions (/chat/completions) or Anthropic Messages (/v1/messages) at the
configured base URL. Backfilled into existing orgs by migration 037.
The loop was gated to API-key providers, so a GPT-account (Codex) CEO failed
with 'requires an API-key provider'. Port Pi's actual request handlers natively
so every agent-capable provider runs:
- chat-completions turn for xAI, Groq, Mistral, Cerebras, OpenRouter
- Codex SSE Responses for GPT account
- Anthropic-OAuth (Claude Code system + beta headers) for Claude Pro/Max
- Copilot proxy (baseUrl from the token) for GitHub Copilot
- Gemini Code Assist for Google Antigravity
A credential resolver refreshes expired OAuth access tokens at request time and
persists the rotation; the runner routes by provider key and passes the resolved
credential. The heartbeat now retries failed tasks (bounded to 3 attempts) so a
run that failed on the old gate recovers automatically. Cloud providers
(Azure/Bedrock/Vertex) still report a clear unsupported message.
ZacharyZhang-NYandClaude Opus 4.8