DEV Community: APIClaw

Pointing Cursor, [CC], and Codex at a different API endpoint (what actually breaks)

APIClaw — Sun, 25 Oct 2026 19:48:00 +0000

Swapping the model behind a coding tool is usually described as a one-line config change. It is, but only for tools that were built with a provider abstraction in the first place. Here is what differs across the popular ones, and the four things that break in practice.

The common shape

Almost every tool that supports a custom endpoint wants the same three values:

Base URL — the root that paths like /v1/chat/completions are appended to.
API key — often any non-empty string, since the gateway does the real authentication.
Model name — the exact identifier the gateway expects, not the marketing name.

The failures cluster in the details of those three.

Cursor

Cursor's custom API mode lives in Settings, under the OpenAI API section. You set an override base URL and a key, then add models manually by name. Two things trip people up: the model list is not discovered automatically, so a typo in a model identifier looks like an authentication failure; and Cursor sends requests shaped for the OpenAI schema, so a gateway must accept that schema rather than only the native provider format.

[CC]

[CC] reads two environment variables: ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN. Set both, then launch normally. The frequent mistake is setting only the base URL and leaving the tool to use its stored login, which takes precedence. Explicitly exporting the token is what makes the override take effect.

Codex CLI

Codex reads a config file (~/.codex/config.toml) with a model provider block. You define a provider with a base_url and env_key, then select it as the active model provider. The env_key names an environment variable rather than holding the secret, so the key never lands in the config file — useful, and a common source of confusion when the variable is unset.

The four things that actually break

1. Trailing slashes and version prefixes. https://host/v1 and https://host are different base URLs. Most tools append /v1/chat/completions themselves, so including /v1 in the base gives you /v1/v1/... and a 404 that looks like an outage.

2. Model identifiers. claude-sonnet-4 is not a universal name. If the gateway expects a namespaced form, the marketing name fails. Check the gateway's model list rather than guessing.

3. Streaming format. A gateway can accept chat completions but emit stream chunks in a slightly different envelope. The tool then hangs waiting for a delta that never arrives, or prints nothing until the response completes. This is the hardest failure to diagnose because the HTTP status is 200.

4. Tool-call schema. Coding agents depend heavily on tool calls. If the gateway translates them imperfectly, the agent loops or silently stops using tools. You notice this as "the agent got dumber," not as an error.

How to test in five minutes

Send one non-streaming request with curl to the base URL and confirm a normal JSON completion.
Repeat with "stream": true and confirm chunks arrive incrementally rather than all at once.
Send one request containing a tool definition and confirm the response has a tool_calls block.
Only then wire it into the tool.

Doing those three curls first separates a config problem from a gateway problem before you spend an hour blaming the editor.

Why the base URL matters for pricing too

A gateway is not only a proxy. It decides how you are billed, and that choice is more consequential for coding agents than for chat. Token metering makes the cost of a long agent run knowable only after it finishes. A per-request allowance bounds it by the number of steps you permit.

The gateway I use for this is APIClaw — [OI]-compatible, so the three steps above work unchanged, and priced per request rather than per token. The per-tool setup notes for Cursor, [CC], Codex and about twenty others are in the docs. Whatever gateway you pick, run the three curls before you trust the config.

What actually triggers Claude's 5-hour limit (and the four ways around it)

APIClaw — Sun, 25 Oct 2026 19:05:33 +0000

If you have hit "You've reached your usage limit. You can resume in X hours" in the middle of a refactor, the useful question is not how many messages you get. It is what the clock is measuring and when it started.

The window is rolling, not daily

The five-hour limit is a rolling window. The timer starts at the timestamp of your first message in a usage session, not at midnight and not at the moment you get blocked.

Two consequences follow, and they explain most of the confusion:

Two people on identical plans hit their limits at completely different clock times.
The five hours you wait is measured from when you started, so a burst that begins at 09:00 unlocks at 14:00 even if you hit the wall at 09:40.

There is also a separate weekly cap that resets independently of the five-hour window. Hitting the session limit does not mean you have exhausted the weekly allowance, and vice versa.

It is not a fixed message count

Anthropic does not publish a universal message quota. Usage is weighted by several factors that compound:

Conversation length — longer threads consume more of the allowance, because each turn carries the accumulated context.
Model choice — the larger models draw down the allowance faster than the smaller ones.
Attachments and file contents — reading a large file into context counts against you.
Tools, effort level, and artifacts — extended thinking and tool loops are not free.

Published estimates put Claude Pro at roughly 45 messages per five-hour window, Max 5x around 225, and Max 20x around 900. Treat those as order-of-magnitude figures that vary with everything above, not as published guarantees.

Why agent sessions drain it so much faster than chat

This is the part that surprises people, and it is mechanical rather than mysterious.

A chat turn sends a prompt and gets a reply. The context is short and does not grow much.

An agent loop is recursive. Every step re-sends the accumulated context: the same files, the same tool outputs, the same instructions. A fifty-step task can re-read the same context fifty times. Consumption grows with task length in a way a single chat turn never does, which is why one long coding session can consume an allowance that would have covered a week of chat.

If you want to see where the allowance actually goes, the two levers that matter most are conversation length and model choice, in that order.

The four options when you hit the wall

1. Wait for the reset. Free, and correct if the task can wait. The clock is already running from your session start, so check the reset time before assuming it is five hours away.

2. Shrink the context. Start a fresh thread rather than continuing a long one. Summarise tool output instead of pasting it. Cap the number of steps a single agent task may take, so a runaway loop cannot drain the window in one go. This is the highest-leverage fix and it costs nothing.

3. Use usage credits if you have them. When credits are enabled and available, sessions continue past the included limit rather than pausing. You keep working, and you pay for the overage.

4. Move that workload to an API key with a different limit model. This is the option people underweight, because it changes the shape of the constraint rather than the size of it. A subscription caps a window of time. An API key meters tokens or requests.

Choosing between token-metered and request-metered APIs

Both are legitimate; they fail differently.

A token-metered API gives you a large ceiling and an unpredictable bill. The cost of a task is only knowable after it finishes, which makes budgeting retrospective and per-project attribution a reconstruction exercise.

A request-metered API bounds cost by the number of steps you allow. That converts budgeting from an accounting problem into a configuration decision, which is where it belongs if you are running agents rather than chatting.

For a coding agent that runs long tasks, the second model is usually the better fit. For occasional chat and short jobs, token metering is often cheaper.

Whichever you pick, check these before committing:

What happens exactly at the ceiling: a clean 429 with Retry-After, or a dropped stream? A mid-stream drop loses the step and can leave a half-applied edit on disk.
Are limits enforced per key or per account? Per-account limits let one runaway agent starve every other job.
Can you issue separate keys per client or environment, so attribution is a query rather than a reconciliation?

What I actually use

I run coding agents rather than chat, so the window model was the wrong shape for my workload and I moved that work to a request-metered gateway. The one I use is APIClaw — [OI]-compatible, priced per request rather than per token, and it took a base-URL change to adopt. If you stay on a subscription, the context-shrinking advice above is the part worth doing regardless.

Summary

The five-hour limit is a rolling window measured from your first message, weighted by conversation length, model, and attachments rather than a flat message count. Agents drain it fast because they re-send context every step. The fixes, in order of cost: shrink context, cap agent steps, use credits, or change the limit model entirely.

Rate limits, burst budgets, and why agent workloads hit ceilings chat never touches

APIClaw — Sun, 25 Oct 2026 18:36:10 +0000

Every "we hit a limit" story in an AI API account has the same shape: a ceiling that is generous for chat and hostile for agents. The difference is not traffic volume. It is the shape of the workload.

Chat is short and bursty, agents are long and recursive

A chat turn sends a prompt and gets an answer. The context is whatever the user typed. Token consumption is bounded by the length of the conversation, and the conversation is usually short.

An agent loop is different in a way that matters for budgeting. Every step re-sends the accumulated context. A fifty-step task re-reads the same files, the same tool outputs, the same instructions fifty times. Token consumption grows roughly with the square of task length in the worst case, because each step carries everything before it.

That is the mechanism behind the ceiling surprise. The account looked fine all month on chat traffic, then one long-running coding agent drained the quota in an afternoon.

What a ceiling actually does to an agent

The failure is not "request rejected." The failure is "session degrades."

When a token-metered API starts refusing calls mid-task, the agent does not roll back cleanly. It loses the step it was on. Depending on the framework, it either retries the same oversized context (making the problem worse), truncates history and loses coherence, or dies and leaves a half-applied refactor on disk. All three are worse than the request never having started.

A rate limit that returns a clean 429 with Retry-After is survivable. A mid-stream drop is not.

Budgeting as a design decision, not a post-mortem

Under token metering, the cost of a task is only knowable after it finishes. You find out what the run cost by reading the bill. That makes budgeting a retrospective exercise, and it makes per-client attribution a spreadsheet reconstruction problem.

Under a per-request allowance, the cost is bounded by the number of steps you permit. That is a number you choose in advance. It converts an accounting problem into a configuration decision, which is where it belongs.

A checklist for evaluating a gateway against agent workloads

Does it speak the [OI] schema, including streaming and tool calls, so your framework needs only a base-URL change?
Are request limits published per plan, or only token limits? Token-only limits are the ones that ambush you.
What happens exactly at the ceiling: clean 429 with Retry-After, or a dropped stream?
Can you issue separate keys per client or per environment, so attribution is a query rather than a reconciliation?
Is the limit enforced per key or per account? Per-account limits let one runaway agent starve every other job.

Practical mitigation, whichever pricing model you use

Cap the step count per task. Summarise context rather than re-sending it verbatim. Queue long jobs instead of firing them concurrently. Treat the ceiling as a design input rather than an operational surprise.

The setup notes for the gateway I use are in the APIClaw documentation — it is [OI]-compatible and priced per request rather than per token, which is what made the budgeting above a configuration decision instead of a monthly surprise.

Running coding agents on a flat-rate API instead of a token meter

APIClaw — Sun, 25 Oct 2026 18:25:41 +0000

An agent loop re-sends its context on every step, so token consumption grows with
task length in a way a single chat turn never does. When that growth meets a hard
hourly ceiling the session degrades rather than ending — usually mid-refactor, which
is the worst possible moment.

A per-request allowance fixes the failure mode, because the budget becomes a count
you can plan against before you start rather than a number you watch slide.

What to check before switching

Does the gateway speak the [OI] schema, including streaming and tool calls?
Are request limits published per plan, not just token limits?
Can you issue separate keys per client, so attribution is not a spreadsheet exercise?
What happens at the ceiling — a clean 429 with Retry-After, or a mid-stream drop?

Why flat-rate helps agents specifically

Chat workloads are bursty but short. Agent workloads are long and recursive: a
fifty-step task can re-read the same context fifty times. Under token metering the
cost of a task is only knowable after it finishes, which makes budgeting a
post-mortem exercise. Under a request allowance the cost is bounded by the number of
steps you allow, which is a design decision you make up front.

Setup

The gateway is [OI]-compatible, so most agent frameworks need only a base-URL
change. Setup notes per tool are in the APIClaw documentation.