HTTP 400 with abacus/gpt-5 — Invalid `input_text` content type

[desert wedge]

Can't find any info about abacus. My bot says openclaw is sending an unaccepted content type and he can't fix it.

```# Bug Report: HTTP 400 with abacus/gpt-5 — Invalid input_text content type

Summary

When using abacus/gpt-5 model, requests fail with HTTP 400 due to invalid content type input_text.

Error Message

HTTP 400: Error code: 400 - {
  'error': {
    'message': "Invalid value: 'input_text'. Supported values are: 'output_text' and 'refusal'.",
    'type': 'invalid_request_error',
    'param': 'input[1].content[0]',
    'code': 'invalid_value'
  }
}

Environment

• OpenClaw version: (run openclaw --version)
• Model: abacus/gpt-5
• Provider config: api: "openai-completions"

[frigid roost]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[desert wedge]

1. Configure abacus provider with gpt-5 model
2. Switch to `abacus/gpt-5` via `/model abacus-gpt5`
3. Send any message
4. Request fails with HTTP 400

## Analysis
The error indicates OpenClaw is sending message content with `type: "input_text"`, but GPT-5's API only accepts `"output_text"` and `"refusal"` as valid content types.

The `input[N]` index in the error varies based on conversation length — it's rejecting whichever message contains the `input_text` type.

## Expected Behavior
Messages should be formatted with content types that GPT-5 accepts, or fall back to the standard Chat Completions API format.

## Possible Fixes
1. Use `text` type instead of `input_text` for user/system message content
2. Map content types appropriately for GPT-5's schema
3. Use Chat Completions API format instead of Responses API for this model

## Model Config (for reference)
```yaml
gpt-5:
  reasoning: false
  supportsDeveloperRole: false

---

Drafted 2026-02-09 by Marvin

[inner fractal]

abacus isn’t a documented/built-in OpenClaw provider right now (so there’s nothing official to link to). In practice it’s usually configured as a custom OpenAI-compatible provider via models.providers.abacus.

About the actual 400:

• That error is coming from an OpenAI Responses-style endpoint (the tell is input[...] + content part type validation).
• In the Responses schema, input_text is only valid for input roles (user/system/developer).
  If the server thinks input[1] is an assistant message (history), then content[].type must be output_text (or refusal) — hence:

  “Supported values are: output_text and refusal”

So this is basically a Responses-API transcript shape mismatch (often: assistant/history getting sent in the request in a form the proxy validates strictly).

Quick workaround to try

If Abacus only supports Chat Completions properly, force chat-completions mode:

models: {

  mode: "merge",
  providers: {
    abacus: {
      // ...
      api: "openai-completions"
    }
  }
}

That makes OpenClaw use /v1/chat/completions instead of /v1/responses and avoids the input_text/output_text content-part typing altogether.

If you must use openai-responses with Abacus, then either:

• Abacus’s Responses compatibility is buggy/too strict, or
• OpenClaw needs a fix for how it formats history for Responses against OpenAI-compatible proxies.

Can you paste these so we can tell which it is?

1. openclaw --version
2. openclaw models status --plain
3. Your models.providers.abacus block (redact the key), especially baseUrl + api

Docs refs:

• Supported provider APIs (openai-completions vs openai-responses): https://docs.openclaw.ai/gateway/configuration
• Raw request logging (if needed): https://docs.openclaw.ai/debugging

That analysis has one key bit flipped:

• In the OpenAI Responses schema, input_text is correct for user/system/developer input.
• The error Supported values are: output_text and refusal only happens when the server believes that particular item is an assistant message (assistant message content parts are output_text|refusal).

So this isn’t “GPT‑5 doesn’t accept input_text” — it’s “your Abacus endpoint (or OpenClaw version) is ending up sending/validating a message as assistant while its content is shaped like user input.”

Most likely causes

1. You’re actually using openai-responses, not chat-completions, against an endpoint that doesn’t fully support Responses.

   • Note: for custom providers, if api is omitted, it defaults to openai-responses.

2. Your model entry overrides the provider:

   • models.providers.abacus.api = "openai-completions" can still be overridden by a per-model api: "openai-responses" in the model definition.

3. You’re on an older OpenClaw/pi-ai build with a Responses formatting bug (less likely, but version will tell).

Quick workaround (if Abacus is only Chat Completions compatible)

Force the provider/model to chat-completions:

models: {
  mode: "merge",
  providers: {
    abacus: {
      baseUrl: "https://YOUR_BASE_URL/v1",
      apiKey: "${ABACUS_API_KEY}",
      api: "openai-completions",
      models: [{ id: "gpt-5", name: "GPT-5 (Abacus)", reasoning: false, input: ["text"] }]
    }
  }
}

Then restart the gateway and start a fresh session (/reset or /new) before retrying (old history from a different API shape can keep tripping validation).

Docs for the models.providers.*.api knob + example: https://docs.openclaw.ai/gateway/configuration#models-custom-providers--base-urls

To debug precisely, paste these (they’ll show what API you’re really on)

1. openclaw --version
2. openclaw models status --plain (or --json if you prefer)
3. Your models.providers.abacus block (redact keys)

If models status shows abacus/gpt-5 using openai-responses, that explains why you’re seeing input[N]... errors (that’s the Responses endpoint).

If after forcing openai-completions you still see the same error, it’s almost certainly a per-model api override (or the config isn’t being loaded from where you think).

If we confirm it’s an OpenClaw bug (after version + status), the right escalation path is a GitHub issue with those outputs + minimal config: https://github.com/openclaw/openclaw/issues

[desert wedge]

2. shows only currently loaded model (version info included in block)

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Turning "I'll reply later" into "my bot replied instantly".

moonshot/kimi-k2.5
admin@MarvinMBP ~ % 

my models.providers.abacus block is quite large, let's see... Some models keys deleted for brevity...

"abacus": {
      "baseUrl": "https://routellm.abacus.ai/v1",
      "apiKey": "s2_abababababababababababab",
      "api": "openai-completions",
      "models": [
        {
          "id": "claude-opus-4-6",
          "name": "Abacus Claude Opus 4.6",
          "reasoning": true,
          "input": [
            "text",
            "image"
          ],
          "cost": {
            "input": 5,
            "output": 25,
            "cacheRead": 0,
            "cacheWrite": 0
          },
          "contextWindow": 200000,
          "maxTokens": 128000,
          "compat": {
            "supportsDeveloperRole": false
          }
        }, 
        {
          "id": "gpt-5",
          "name": "Abacus GPT-5",
          "reasoning": false,
          "input": [
            "text",
            "image"
          ],
          "cost": {
            "input": 1.25,
            "output": 10,
            "cacheRead": 0,
            "cacheWrite": 0
          },
          "contextWindow": 128000,
          "maxTokens": 16384,
          "compat": {
            "supportsDeveloperRole": false
          }
        }
      ]

[inner fractal]

Your models.providers.abacus block looks fine for Chat Completions (api: "openai-completions"). But the specific error you’re getting:

param: input[1].content[0] and complaining about input_text vs output_text/refusal

…can only come from a Responses-style request (Chat Completions doesn’t even have input_text / output_text content-part types).

So in practice, your running bot is still hitting openai-responses, or it’s not actually using the abacus/gpt-5 model entry you think it is.

2 fast checks

1. Confirm OpenClaw actually sees abacus + what API it thinks it should use:

openclaw models list --provider abacus --plain
# (or --json)

If that output shows api: openai-responses anywhere for gpt-5, that explains everything.

2. Check the effective merged file the Gateway uses (this catches “edited config but daemon didn’t reload / models.json still old”):

cat ~/.openclaw/agents/main/agent/models.json | jq '.providers.abacus.api, .providers.abacus.models[] | select(.id=="gpt-5") | {id, api}'

Most common fix

After any change to models.providers, restart the gateway so it re-merges/writes models.json:

openclaw gateway restart

Then try switching again.

Belt-and-suspenders workaround

Even though provider-level api should apply, you can force it at the model level too (in case something else is overriding):

{
  id: "gpt-5",
  name: "Abacus GPT-5",
  api: "openai-completions",
  reasoning: false,
  input: ["text", "image"],
  compat: { supportsDeveloperRole: false }
}

If after restart + the checks above it still routes through Responses, paste the output of:

• openclaw models list --provider abacus --plain
• and the jq command result

…and we can pinpoint where the override is coming from (stale models.json, different agentId, different state dir/user for the daemon, alias resolving to the wrong provider, etc.).

[desert wedge]

1. models list...

~ % openclaw models list --provider abacus --plain

🦞 OpenClaw 2026.2.6-3 (85ed6c7) — Siri's competent cousin.

abacus/claude-opus-4-6
abacus/claude-opus-4-5-20251101
abacus/claude-sonnet-4-5-20250929
abacus/grok-4-fast-non-reasoning
abacus/deepseek-ai/DeepSeek-V3.2
abacus/gpt-5

2. shell error. same in bash.

jq: error (at <stdin>:221): Cannot index string with string "id"

I haven't tried making any edits to the specific model key yet.

[inner fractal]

That jq error is actually a really useful clue:

Why your jq blew up

jq: Cannot index string with string "id" means at least one entry in:

.providers.abacus.models[]

is a string, not an object. So select(.id=="gpt-5") tries to do .id on a string and dies.

Try these two to confirm what’s in there:

jq '.providers.abacus | { baseUrl, api, modelsType:(.models|type), model0:(.models[0]) }' \
  ~/.openclaw/agents/main/agent/models.json

jq '.providers.abacus.models | map(type) | unique' ~/.openclaw/agents/main/agent/models.json

If you see ["string"] (or ["string","object"]) then your models.json is not in the “full model objects” form you pasted in chat.

Why this matches the input_text / output_text error

That 400 is Responses API-style validation. Abacus RouteLLM’s docs/examples are Chat Completions (/v1/chat/completions). If OpenClaw ends up treating gpt-5 as a “known OpenAI model”, it will often default to openai-responses unless you force otherwise.

So the pragmatic fix is: force Chat Completions at the model level (not just provider level), specifically for gpt-5:

{
  id: "gpt-5",
  name: "Abacus GPT-5",

  api: "openai-completions",
  reasoning: false,
  input: ["text","image"],
  compat: {
    supportsDeveloperRole: false,

    // Abacus commonly rejects the OpenAI tool "strict" field.
    // pi-ai will omit it if you set this:
    supportsStrictMode: false
  }
}

(That supportsStrictMode: false is important too — otherwise the next error you often hit with Abacus is a “strict not allowed/unknown field” tool-schema rejection.)

Make sure the running gateway actually picks up the change

After updating config, restart the gateway so it rewrites/loads the effective models.json:

openclaw gateway restart

If you paste the output of:

jq '.providers.abacus.api, .providers.abacus.models[0:5]' ~/.openclaw/agents/main/agent/models.json

…I can tell you immediately whether you’re still on the “string shorthand” (which is what’s likely causing the API selection weirdness) or on proper model objects.

[desert wedge]

jq providers output: Trimmed for entries 0 and 6.
opus 4.6 works.
GPT-5 does not.

 ~ % jq '.providers.abacus.api, .providers.abacus.models[0:6]' ~/.openclaw/agents/main/agent/models.json
"openai-completions"
[
  {
    "id": "claude-opus-4-6",
    "name": "Abacus Claude Opus 4.6",
    "reasoning": true,
    "input": [
      "text",
      "image"
    ],
    "cost": {
      "input": 5,
      "output": 25,
      "cacheRead": 0,
      "cacheWrite": 0
    },
    "contextWindow": 200000,
    "maxTokens": 128000,
    "compat": {
      "supportsDeveloperRole": false
    }
  },
  {
    "id": "gpt-5",
    "name": "Abacus GPT-5",
    "reasoning": false,
    "input": [
      "text",
      "image"
    ],
    "cost": {
      "input": 1.25,
      "output": 10,
      "cacheRead": 0,
      "cacheWrite": 0
    },
    "contextWindow": 128000,
    "maxTokens": 16384,
    "compat": {
      "supportsDeveloperRole": false
    }
  }
]

I haven't edited anything yet. Interpreting requests as my currently loaded model is not GPT-5.

If I understand correctly: I should add the

api: "openai-completions",

key and also compat.supportsStrictMode: false

to the appropriate models.json, to force gpt-5 to use openai-completions at the model level?

(with gateway restart to force reload config)

[inner fractal]

That 400 is exactly what you get when the request is going through an OpenAI Responses-style payload (input[].content[].type="input_text"), and Abacus RouteLLM is rejecting that schema. So the remaining job is to prove what API OpenClaw thinks abacus/gpt-5 is, and then force it to Chat Completions.

1) Inspect the effective models.json (this usually reveals the bug in 30 seconds)

On the gateway host:

FILE=~/.openclaw/agents/main/agent/models.json

# provider-level api
jq -r '.providers.abacus.api' "$FILE"

# what types are in the models array (should be only "object")
jq '.providers.abacus.models | map(type) | unique' "$FILE"

# show anything that's a string (if this prints "gpt-5", that's likely your smoking gun)

jq -r '.providers.abacus.models[] | select(type=="string")' "$FILE"

# show the gpt-5 entry as OpenClaw sees it
jq '.providers.abacus.models[]
    | select(type=="object" and .id=="gpt-5")
    | {id, api, compat}' "$FILE"

What we’re looking for:

• If you see any strings in .providers.abacus.models (especially "gpt-5"), that explains both:
  • your earlier jq crash, and
  • why OpenClaw might be inheriting “known gpt-5 defaults” (often Responses API) instead of your provider-level api: "openai-completions".

2) Force Chat Completions at the model level (belt + suspenders)

In your OpenClaw config (~/.openclaw/openclaw.json or wherever your service points—openclaw gateway status shows the exact path), make sure the Abacus model entry is an object and set api on the model too:

models: {
  // TEMP while debugging: guarantees no old junk survives the merge
  mode: "replace",

  providers: {
    abacus: {
      baseUrl: "https://routellm.abacus.ai/v1",
      apiKey: "${ABACUS_API_KEY}",
      api: "openai-completions",
      models: [
        {
          id: "gpt-5",
          name: "Abacus GPT-5 (chat)",

          api: "openai-completions",

          // keep whatever you had here:
          reasoning: false,
          input: ["text", "image"],

          // recommended for OpenAI-compatible proxies
          compat: {
            supportsDeveloperRole: false,
            supportsStrictMode: false
          }
        }
      ]
    }
  }

}

Then:

openclaw gateway restart

(And try from a fresh chat session: /reset or /new in Discord.)

Once it works, you can switch models.mode back to "merge" if you prefer—"replace" is just the “make it deterministic” debugging move.

Docs reference for this flow:

• https://docs.openclaw.ai/gateway/configuration (search for models (custom providers + base URLs))
• https://docs.openclaw.ai/concepts/model-providers

3) If it still hits /responses, prove it with OpenAI SDK logging (super definitive)

The OpenAI Node SDK can log the exact URL being called. Temporarily add to the gateway environment:

export OPENAI_LOG=info
# (or debug, but debug may include bodies; don’t paste that publicly)

Put it in the place your gateway service loads env from (commonly ~/.openclaw/.env), restart, reproduce once, then check openclaw logs --follow for a line that includes either:

• POST .../responses ← bad (Responses)
• POST .../chat/completions ← good (Chat Completions)

If you paste anything back, paste only the single line showing the URL/path (no headers/bodies).

---

If you run the jq commands in (1) and paste the outputs (redacting secrets), I can tell you exactly why your abacus/gpt-5 is still being treated as Responses API.

[opaque token]

i'm having similar issue and cannot get abacus to work with abacus

i mean abacus to work with openclaw

[inner fractal]

That error is a Responses API schema error:

Invalid value: 'input_text'. Supported values are: 'output_text' and 'refusal'.

In OpenAI’s /v1/responses format, user items use type: "input_text", but assistant items must use type: "output_text" (or refusal). So the upstream (Abacus) is telling you: “you sent me an assistant message, but labeled its content as input_text”.

Practically, it usually means one of these is true:

1. You’re accidentally hitting Responses (api: "openai-responses") when you thought you were using Chat Completions (api: "openai-completions"), or
2. Abacus’s OpenAI-compatible proxy doesn’t correctly support the Responses API (common), so anything that requires /v1/responses will fail.

What I need from you to pinpoint it

Please paste:

1. openclaw --version
2. openclaw models status
3. Your models.providers.abacus block (redact the key), plus what you set as the agent default model

4. One log snippet showing whether it’s calling /v1/chat/completions or /v1/responses:
   • run openclaw logs --follow, trigger one message, then paste the relevant lines

The usual fix / workaround

• If Abacus only supports Chat Completions: configure it as a custom provider with:

  • api: "openai-completions"
  • and use a model that works via chat completions on that proxy.

• If you must use gpt-5 specifically: in many setups that ends up needing Responses. If Abacus doesn’t fully implement Responses, you’ll likely need to run gpt-5 via the official OpenAI provider/endpoint (or any proxy that explicitly supports /v1/responses end-to-end).

Also make sure after changing config you actually restart the gateway:

openclaw gateway restart

Send the 4 items above and I’ll tell you exactly which side is mismatched (OpenClaw config vs Abacus API support) and what to change.

Yep — if you want Abacus to work with OpenClaw, you have to treat it as a custom OpenAI-compatible provider.

The specific input_text error almost always means: OpenClaw is hitting an OpenAI “Responses API” style endpoint, but Abacus doesn’t fully support that schema (it’s rejecting input_text, which is a legit input type in Responses). Most proxies only reliably support Chat Completions.

What to do (most likely fix)

1. Force Chat Completions for the Abacus provider:

• set api: "openai-completions" (not openai-responses)
• make sure your baseUrl points at Abacus’s OpenAI-compatible root (often ends with /v1)

Example config (JSON5):

{
  env: { ABACUS_API_KEY: "sk-..." },

  models: {

    mode: "merge",
    providers: {
      abacus: {
        baseUrl: "https://<abacus-host>/v1",
        apiKey: "${ABACUS_API_KEY}",
        api: "openai-completions",
        models: [
          { id: "gpt-5", name: "GPT-5 (Abacus)" },
        ],
      },
    },
  },

  agents: {
    defaults: {

      model: { primary: "abacus/gpt-5" },
    },
  },
}

2. Restart:

openclaw gateway restart

If that still doesn’t work

Then either:

• Abacus doesn’t support gpt-5 via chat completions, or
• the base URL/model id doesn’t match what Abacus expects.