Kimi K3 returns reasoning_content and requires the complete assistant message in preserved-thinking multi-turn and tool-call flows.
A content-only log cannot show the exact assistant state that the application needed to submit on the next turn.
They do not establish what sensitive material appears in every deployment, how third-party SDKs persist it, or how another provider interprets it.
A chat interface teaches developers to see an assistant message as the text placed on screen. Tool-using systems already make that view incomplete: a message can also contain structured calls, identifiers, and control data. Kimi K3 makes the boundary explicit. The provider’s repository says a preserved-thinking exchange depends on a field that is not the ordinary visible answer.
That does not settle what the field means philosophically, whether it exposes a universal chain of thought, or whether it should be displayed to a user. Those claims are outside the checked record. The narrower engineering fact is enough: the field exists in the response, and the next request may be invalid without it.
This issue therefore reads reasoning_content as protocol state. That term describes its operational role, not an entitlement to inspect, publish, analyze, or retain it forever. A transport requirement and a data-governance decision are different questions. A robust application has to answer both.
The release record separates model scale from the message contract
Kimi Code’s official release notes date Kimi K3 to 16 July 2026. They describe 2.8 trillion total parameters, native visual understanding, context up to one million tokens, and low, high, and max thinking-effort levels. Kimi’s official product history gives the same release date and says full weights became available on 27 July 2026. source ↓
These are provider descriptions, not independent measurements by China AI Desk. The scale, context, and visual claims explain the product envelope; they do not prove quality, throughput, cost, or reliability in any particular workload. Nor do they explain the protocol consequence at the center of this issue. That consequence appears in the repository’s usage contract.
The distinction matters because a team can test model quality and still ship a broken conversation layer. A response may look correct in a single turn while the application silently discards state needed by the second turn. Evaluation of the model and validation of the message transport are separate gates.
The complete assistant message is the unit of continuity
MoonshotAI’s official Kimi K3 repository says the model always has thinking enabled and returns reasoning_content. The top-level reasoning_effort request field accepts low, high, and max, with max as the default. For multi-turn conversations and tool calls, the repository instructs clients to pass the complete assistant message back to messages as-is, including reasoning_content and tool_calls, rather than retaining only content. source ↓
“As-is” closes off a common shortcut. An adapter cannot assume that the text shown to the user is the whole assistant message, then reconstruct a new object from role and content. That reconstruction may be visually equivalent and protocol-incomplete.
The same applies to tool loops. The assistant message that requested a tool, the tool call identifiers, the returned reasoning field, and the later tool result form a linked transition. Dropping one structured field changes the state presented back to the model. The application has not merely hidden a display element; it has edited the conversation envelope.
This makes schema preservation part of model integration. Serialization, database mapping, queue payloads, workflow resumptions, retries, and SDK-to-SDK handoffs all need to preserve the fields that the provider marks as required. A typed object accepted at ingress can still be damaged by a narrower internal record before the next request leaves the system.
The error reference turns the rule into an observable failure
Kimi Code’s official error reference documents HTTP 400 for an assistant tool-call message that is missing reasoning_content while thinking is enabled. Its prescribed fix is to add the field to the assistant message in tool calls. source ↓
The 400 boundary is useful because it makes a state-loss bug testable. A team does not need to infer protocol failure from a vague decline in answer quality. It can construct a multi-turn tool fixture, preserve the returned assistant object, remove the field in a negative case, and assert the documented rejection path.
Production monitoring should preserve that distinction. A 400 caused by a missing field is not a model-capability failure and not a reason to retry the same malformed body. It is an adapter or persistence defect. Classifying it correctly keeps automatic retries from multiplying a deterministic error while the real state-loss path remains unfixed.
A content-only log can be readable and still be incomplete
If an application records only prompts, visible assistant text, tool results, and final output, it may have a useful product transcript. It does not have the exact execution record for this protocol. It cannot prove which complete assistant object was returned, which fields survived persistence, or what was sent on the continuation request.
That inference does not require every analytics system to store raw reasoning_content. The live conversation buffer needs the bytes required for the next call. A restricted execution record may instead bind the provider, model, message schema, field-presence checks, request identifier, tool-call identifiers, timestamps, and hashes. A product transcript may contain only user-visible text and approved tool outcomes. Those three stores serve different purposes and should not inherit access from one another by convenience.
Replay changes the requirement. A system that promises exact replay, resume after failure, or forensic reconstruction needs the original protocol state for the period in which that promise applies. A hash can prove later that bytes changed; it cannot supply bytes the API needs. Retention duration, encryption, operator access, and deletion therefore belong in the design of the replay feature, not in an after-the-fact logging policy.
The clean boundary is purpose-limited state: keep the complete message where continuity requires it, for as long as continuity requires it; emit narrower receipts and visible transcripts elsewhere. “Log everything” and “drop the hidden field” are both crude answers to a typed-state problem.
Redaction must preserve the state machine it edits
A generic redaction layer often works by allowlist: retain role, content, perhaps tool_calls, and delete unknown keys. Against Kimi K3’s documented contract, that default can turn a valid assistant response into an invalid continuation. The redactor has changed behavior even if no visible sentence changed.
The opposite default is not safe reasoning either. Blindly copying the field into every log, data warehouse, trace vendor, debugging attachment, and support export enlarges the number of systems that handle it. That is an architectural inference about data surface, not evidence that the field contains secrets or regulated data in every deployment. The checked documents do not characterize its contents across workloads.
A provider-aware policy should decide separately whether a field is required for transport, permitted in short-lived replay state, represented only by metadata in an execution receipt, or excluded from analytics and support views. When a transformation is required, the system should either preserve a valid provider envelope or deliberately end continuity and start a new conversation. Silent partial replay is the dangerous middle.
Access paths deserve the same precision. Engineers may need to know that reasoning_content was present and round-tripped without needing to read it. Field-presence assertions, byte counts, keyed hashes, and negative fixtures can diagnose many failures while keeping raw state behind a smaller operational boundary.
A provider field is not a universal interchange format
The official sources establish Kimi K3’s contract. They do not establish that another model provider uses the same field name, accepts the same message object, assigns the same semantics, or permits the same replay behavior. Treating reasoning_content as a universal schema would replace one lossy adapter with another.
A multi-provider system should preserve the native response at the provider boundary and map only well-defined capabilities into an internal model. The mapping needs an escape hatch for provider-specific state that must round-trip unchanged. Switching providers should begin a new compatible state lineage unless a tested adapter proves otherwise; renaming a field is not proof of semantic portability.
The same uncertainty applies to third-party SDKs and gateways. The checked pages do not say which libraries retain the complete assistant message, which serializers discard unknown fields, how tracing products capture the payload, or what any intermediary stores. Those are empirical integration questions. A team must inspect and test the exact versions in its path.
What teams should prove before Kimi K3 carries a tool workflow
The following gates are editorial consequences of the checked protocol, not claims that MoonshotAI prescribes a particular storage architecture:
- 01Round-trip the native assistant object.
Capture the API response without narrowing it, pass the complete assistant message into the next multi-turn and tool-call request, and assert that
reasoning_contentandtool_callssurvive every serializer. - 02Build the documented negative case.
Remove the required reasoning field from an assistant tool-call message in an isolated fixture and verify that monitoring classifies the resulting 400 as malformed protocol state rather than a transient model error.
- 03Separate state from observability.
Keep continuity state in a restricted, purpose-limited store. Emit field-presence, identifiers, hashes, and approved visible content to broader traces only where those records are sufficient.
- 04Audit every intermediary.
Test the exact SDK, gateway, queue, database, workflow engine, retry path, and trace exporter. Unknown-field stripping and hand-built message reconstruction should fail acceptance.
- 05Make provider transitions explicit.
Version the native schema and adapter. Start a new conversation state when changing to a provider whose replay contract has not been shown compatible.
The response object carries visible content, reasoning state, and any structured tool calls.
The next request receives the assistant message without lossy reconstruction or silent field deletion.
Execution receipts and analytics receive only the state their declared purpose and acceptance tests require.
What the checked record does not establish
The four official sources do not establish what sensitive material may appear in reasoning_content for every prompt or deployment; whether a particular third-party SDK, gateway, or trace service stores or drops it; MoonshotAI’s provider-side retention policy for the field; compatibility with another vendor’s reasoning or tool-call representation; or a universal interpretation of internal model reasoning. They also do not prove a privacy breach, secret leakage, regulatory violation, or guaranteed performance. None is inferred here.
Limit
This issue reads the official MoonshotAI repository and Kimi product documentation as checked on 31 July 2026. China AI Desk did not call the Kimi API, inspect provider infrastructure, test a third-party SDK, measure model performance, or observe the contents of a production reasoning_content field. Storage, replay, redaction, and adapter controls described here are editorial engineering recommendations, not statements of Kimi policy or legal advice.
What would change this assessment
An official retention and data-handling specification for reasoning state; versioned SDK guarantees that preserve native assistant objects; a documented provider-neutral interchange contract; evidence that a supported continuation path no longer requires the field; or reproducible integration tests showing how gateways, queues, resumable workflows, and tracing systems handle the complete message.
An assistant message is no longer only what the user can read. In this contract, it is also what the next request must remember.