Cohere Command's max_tokens Default and Output Ceiling

Cohere does not document a default value for max_tokens on the Chat API. Omit it and generation is bounded by the model’s own output ceiling and by the model deciding to stop — which are two different limits, only one of which you can raise.

There is no documented default

The Chat API reference describes max_tokens as the maximum number of tokens the model will generate as part of the response, and notes that setting a low value may produce incomplete generations. It does not state a value that applies when the field is absent, and that absence is the honest answer to the question in the title.

What actually bounds an unset request is a stack of three limits, and knowing which one you are hitting decides what to change:

• The model stopping on its own. Command emits an end-of-turn token when the answer is done. In practice this is what ends the overwhelming majority of requests, and it is why omitting max_tokens feels safe in development.
• The model’s output ceiling. A hard per-model cap you cannot exceed with any value of max_tokens.
• The context window. Input plus output share it, so an enormous prompt reduces the room left to answer in.

The per-model ceiling

Cohere publishes the maximum output length per model. At the time of writing, the Command family reads:

model                    max output tokens   context length
command-a-03-2025                 8,192          256,000
command-r-plus-08-2024            4,096          128,000
command-r-08-2024                 4,096          128,000
command-r7b-12-2024               4,096          128,000

Those come from Cohere’s models documentation. Two things stand out. The ceilings are small relative to the context windows — Command R+ can read thirty times more than it can write — and they are not proportional: quadrupling the context window on Command A only doubled the output. Long-context models are built to consume, not to produce, and any workload whose output is the long part is fighting the design. See the context window and output limit in more detail.

Detecting that you hit it

Reaching the limit is not an error. The response arrives with HTTP 200, the text stops mid-sentence, and the only signal is the finish reason:

{
  "text": "The three regions with the highest late-delivery rate in July were Utrecht, which recorded 4.1% against a target of 2%, Rotterdam, which",
  "finish_reason": "MAX_TOKENS",
  "meta": {"billed_units": {"input_tokens": 1204, "output_tokens": 4096}}
}

In v1 the field is finish_reason on the response; in v2 it is finish_reason on the message, and on a streamed response it arrives in the final message-end event. Anything downstream that parses, stores or displays the text should check it first. This is especially acute with JSON output, where truncation produces invalid JSON and the parse error sends you looking for a bug in the schema that is not there.

Worth noting that a truncated answer is often a good answer that ran out of room, which makes it more dangerous than an obviously broken one. The first four thousand tokens are coherent, well-formed and plausible; only the ending is missing. A summarisation pipeline that stores such a response, or a UI that renders it without a marker, has published a document whose conclusion is absent and whose prose gives no indication of it.

Setting a value on purpose

The argument for always setting it is cost control and predictability: with no value, a single request can consume the full ceiling, and a pathological loop — a model repeating itself — costs the maximum every time until something stops it.

The argument against setting it too tightly is that max_tokens is a guillotine and not a style instruction. The model does not plan a shorter answer to fit; it writes the answer it was going to write and gets cut. If you want brevity, ask for it in the preamble and set max_tokens above what a good answer needs, as a safety net rather than as the mechanism. A reasonable pattern: measure the token length of good answers on your own traffic, set the cap at roughly double the p99, and alert on MAX_TOKENS rather than treating it as normal.

Working around the ceiling

When the output you need is genuinely longer than the ceiling, there is no parameter that helps. The work has to be split, and there are three ways to split it that behave very differently.

• Split the input. Translating or summarising a long document is naturally per-section: run one request per chapter and concatenate. Each request has its own full output budget, the requests are independent so they can run concurrently, and the failure of one does not cost you the others. This is the right answer whenever the task decomposes over the input, and it is the case people most often fail to notice they are in.
• Continue the generation. When the output does not decompose — a single continuous piece of writing — you can send the truncated text back as an assistant turn and ask for the continuation. It works, and it costs: the whole prompt plus everything generated so far is re-read and re-billed on every continuation, so a four-part answer pays for its own earlier parts three extra times. Seams are also visible; the model will often repeat a sentence or restate context across the join.
• Ask for structure instead of prose. A great many “the answer was cut off” problems are really requests for an enumeration — every clause, every finding, every row — where the right shape is one request per item, or a request that returns identifiers you then expand individually. This is more requests and less total output than one long generation, and it fails item by item rather than all at once.

The general rule that falls out: prefer splitting the input over continuing the output, because independent requests parallelise, retry cleanly, and do not re-bill their own history. Continuation is the fallback for genuinely continuous prose, and it is worth knowing that it is the expensive option before you build a pipeline on it.

What it does to your bill

Cohere bills output tokens generated, not the ceiling you set, so a high max_tokens with short answers costs nothing extra. There is no reservation and no charge for headroom. The meta.billed_units object on every response reports input_tokens and output_tokens as billed, which is the number to log rather than anything you counted yourself.

The one case where the cap does save money is the pathological one, and it is worth being precise about how much: a truncated response is billed for every token generated up to the cut. Truncation does not refund the 4,096 tokens it took to get there. That is an argument for catching runaway generations with a sensible ceiling, and an argument against treating truncation as a routine outcome you tolerate.