Skip to content

devin adapter ignores provider output budget — every Codex turn is silently capped at the encoder's 8192 default #5190

Closed

Description

@GPLaider

Client or integration

Codex CLI

Area

Provider adapter

Summary

The devin adapter never forwards a configured output budget. When the caller omits max_output_tokens — which Codex always does — the cloud-direct encoder falls back to DEFAULT_MAX_OUTPUT_TOKENS = 8192 (src/adapters/devin/cloud-direct/chat.ts), so every devin/* turn is capped at 8192 output tokens. Any turn that legitimately needs more (e.g. writing a whole source file in one tool call) ends as an upstream incomplete / max_output_tokens, which Codex surfaces as stream disconnected before completion: Incomplete response returned, reason: max_output_tokens after several full-size retries hit the same deterministic wall.

There is also no config escape hatch: applyOAuthPresetCatalog in src/oauth/index.ts iterates OAUTH_RECONCILE_FIELDS (which includes defaultMaxOutputTokens and modelMaxOutputTokens) and deletes any field the registry preset doesn't define, so a hand-edited value in config.json is wiped on every startup. The devin registry entry defines neither field.

Reproduction

  1. ocx start with a signed-in devin provider (authMode: oauth, adapter: devin, https://server.codeium.com).
  2. Route a Codex turn to devin/swe-2 that produces a long single response (e.g. "write this entire C file").
  3. Observe ~/.opencodex/usage.jsonl: outputTokens: 8192 exactly, terminalStatus: "incomplete", terminalSource: "upstream", upstreamError: "Output reached the requested token limit (max_output_tokens)". Codex retries the turn verbatim (identical inputTokens across consecutive entries) and each retry dies at the same bound.
  4. Separately: curl /v1/responses with "max_output_tokens": 64 truncates at exactly 64 tokens — proving the wire field reaches the encoder — while any request omitting it cannot exceed 8192.

Version

2.58.0 (still present in 2.59.0 — maxInputTokens was wired to config there, maxOutputTokens was not)

Operating system

Windows 11 x64

Provider and model

devin / swe-2 (affects every devin model)

Logs or error output

{"provider":"devin","model":"swe-2","status":200,"terminalSource":"upstream","terminalStatus":"incomplete","closeReason":"terminal","upstreamError":"Output reached the requested token limit (max_output_tokens)","usage":{"inputTokens":136830,"outputTokens":8192,"totalTokens":145022}}

Codex client side:

stream disconnected before completion: Incomplete response returned, reason: max_output_tokens

Suggested fix

  • In adapters/devin.ts runTurn, resolve the cap like the other adapters do:
    const maxOutputTokens = typeof parsed.options.maxOutputTokens === "number"
      ? parsed.options.maxOutputTokens
      : modelRecordValue(provider.modelMaxOutputTokens, parsed.modelId) ?? provider.defaultMaxOutputTokens;
    and pass it through when > 0.
  • Give the devin registry entry a defaultMaxOutputTokens (the Anthropic entry already does this for the same reason), and/or exempt defaultMaxOutputTokens/modelMaxOutputTokens from the OAuth reconcile delete branch, the way requiresReasoningPlaceholderModels is already exempted.

Verified locally with those two changes: a request that previously truncated at exactly 8192 completed with 16,327 output tokens.

Redacted configuration

{
  "providers": {
    "devin": {
      "adapter": "devin",
      "baseUrl": "https://server.codeium.com",
      "authMode": "oauth",
      "defaultModel": "swe-2",
      "liveModels": true
    }
  }
}

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. github-actions commented on Sep 19, 2026

    @github-actions
    Contributor

    Issue reopened

    The report now contains the information required by the automated check. Thanks for updating it.

  2. added
    bugSomething isn't working
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    providerProvider adapters, OpenAI-compat presets, upstream API quirks
    on Sep 20, 2026
  3. Ingwannu commented on Sep 20, 2026

    @Ingwannu
    Owner

    Confirmed on current dev (2a2c01a7). The explicit request value is forwarded at src/adapters/devin.ts:609, but omission falls through to the encoder's hard DEFAULT_MAX_OUTPUT_TOKENS = 8192; the provider/catalog output budget is never consulted. The OAuth preset also has no durable Devin output-cap default, so this is not operator-recoverable through a stable provider edit.

    The fix should resolve one authoritative cap before runDevinCloudTurn: explicit request override first, then exact model output cap, then provider default. Keep input context and output budget separate, reject non-positive/non-finite values, and do not use the context window as an output cap. Add regressions for explicit 64, model-specific cap, provider fallback, and absent metadata; also prove OAuth reconciliation preserves the registry-owned default rather than deleting it. Keeping open as a verified truncation bug.

  4. added a commit that references this issue on Sep 20, 2026
    447ac22
  5. lidge-jun commented on Sep 20, 2026

    @lidge-jun
    Owner

    Fixed on dev by #5265 (447ac22ca65baabd573dbd429abe28ed9deff594).

    Two defects, not one. The adapter forwarded only a caller-supplied max_output_tokens, and Codex never sends one, so every devin/* turn was capped at the cloud-direct encoder's 8192 fallback however the provider was configured. The escape hatch was closed as well: no OAuth preset declares defaultMaxOutputTokens or modelMaxOutputTokens, so a hand-edited value was deleted before the next startup finished.

    The resolver now reads the caller's explicit value, then the configured per-model cap, then the provider default, and only then leaves the encoder fallback. It never reads the context window, which is a separate quantity. tests/providers/devin-output-budget.test.ts holds each case, including that an explicit small cap survives a larger configured budget and that the context window never becomes the output cap.

    The repeated identical attempts described here were the client's, not a proxy retry: an upstream incomplete / max_output_tokens is a successful streaming response that has already emitted events, so it matches no replay condition.

    Closing on dev. PRs here target dev, so GitHub does not auto-close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansbugSomething isn't workingproviderProvider adapters, OpenAI-compat presets, upstream API quirkstoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions