Kimi gave a 3T model a million-token desk. Keep the work trace

THE SIGNAL IN ONE SENTENCE

A million-token desk sounds luxurious. You can spread out a codebase, a stack of financial filings, screenshots, tool results, instructions, old mistakes and half a dozen plans without immediately knocking something onto the floor. Kimi K3.1 Pro is built for that kind of sprawling work. Moonshot AI introduced the model on October 24 as the first release in its K3.1 series and its most capable 3T-class model so far. It keeps a one-million-token context window, accepts visual material and is aimed at coding, 3D creation, financial research and other jobs that require an agent to keep working through many steps. The standard API costs two dollars per million input tokens and ten dollars per million output tokens. A Highspeed version uses the same context window and, according to Kimi, runs roughly two to three times faster at four dollars per million input tokens and twenty dollars per million output tokens. Both versions are available through Kimi's products and API. The company says full model weights will follow by November 4. That last detail matters. Kimi calls K3.1 Pro an open-weight model, but the weights were not available on publication day. The service is available now. The downloadable artifact is a promised future event. Those are two different states and should be labelled that way. The plain signal is this: keep the work trace beside the score. A benchmark can tell you that a model completed a defined set of tasks under a defined setup. A work trace tells you how it moved from request to result, which tools it called, what evidence it used, where it failed, how often it retried, what a person repaired and what the entire run cost. Long-context agents make that trace more important, not less. Kimi reports 65.7 percent on Terminal-Bench 4.0, a benchmark of coding work performed in constrained terminal environments. It places that result just below Claude Opus 5.5 at 66.4 percent and above GPT-6 Astra at 58.2 percent. It also reports 61.2 percent on Kimi Code Bench 3.0 Long-horizon, up from 55.95 percent for Kimi K3. That second benchmark is internal, and Kimi says it measures multi-step execution, tool use and end-to-end problem solving across engineering domains. Those numbers justify a closer look. They do not pick a model for your team. Even Kimi's footnotes show why. Different models can be tested with different agent harnesses. Some results come from official leaderboards, some from other companies' reports and some from Kimi's own runs. Some tasks use a maximum reasoning setting. Some rely on judge models. Some comparisons use subsets of larger benchmarks. Kimi notes cases where external models retrieved reference answers online and assigns zeroes to those runs. This is not evidence that the evaluation is useless. It is evidence that the harness is part of the product. An agent benchmark is never only a model exam. It is a model plus instructions, tools, permissions, time limits, retry rules, context management, judge, environment and stopping condition. Change any of those and the result can move. A model that looks excellent inside one coding harness may struggle inside another because tool descriptions, file access, terminal behavior or error recovery are different. The work trace makes those hidden decisions inspectable. Start with the job contract. Write down the task, success condition, prohibited actions, allowed tools, data boundaries, time budget and spending limit. If the model is asked to fix software, define which tests must pass and which files it may change. If it is asked to analyze financial records, define which filings count as authoritative and which calculations a person must independently check. Then lock the identity of the run. Record the exact model ID, service date, reasoning setting, temperature, tool versions, system instructions and context-management policy. Kimi's API names are listed as kimi-k3.1-pro and kimi-k3.1-pro-highspeed. A receipt that merely says Kimi is not enough. Products change quickly, and the same name can point to different behavior after an update. Capture the trajectory without turning it into a surveillance swamp. Log each tool call, the reason it was allowed, the result returned and the action taken next. Preserve references to source files and tests. Store sensitive inputs under a retention policy instead of dumping every secret into a permanent analytics lake. Where full content cannot be retained, keep hashes, identifiers, timestamps and structured summaries sufficient to reconstruct what happened. Count the whole run. Token price is a useful ingredient. It is not the recipe total. A long agent job may use cached context, web search, code execution, storage, image processing, retries, judge calls and human review. It may fail halfway and start again. It may produce an answer that looks finished but requires three hours of repair. Those costs belong beside the API bill. For each completed task, report input tokens, output tokens, cache reads and writes, number of model calls, tool calls, retries, elapsed time, human minutes, failed attempts and final verified outcome. If the faster model tier costs twice as much per input and output token, compare the saved time with the real price of the job. Faster is valuable when latency blocks work. It is expensive decoration when the result sits in a queue overnight. Kimi's own examples make the case for outcome-level evidence. The company describes a long-horizon experiment in which K3.1 Pro worked on a simulated human walking controller. Across 167 missions and 420 reviews, the system reportedly analyzed results, corrected problems and improved the simulation until the digital human walked for 11.2 seconds. When reward adjustments did not fix arm motion, Kimi says the model probed the simulator, found 36 errors in shoulder-muscle calculations and retrained the controller. That is a vivid agent story. It is also a vendor-run demonstration. A useful public trace would show the starting code, task instructions, allowed tools, sequence of changes, failed branches, test protocol, review method, compute used and the final artifact. Without that material, readers can understand the claim but cannot reproduce the job. Financial work needs an even stricter receipt. Kimi reports a score of 64.4 on OfficeQA Pro v2, which tests analysis across financial documents with retrieval, cross-document checks and numerical reasoning. It also says a targeted internal evaluation reduced claim-level hallucinations on difficult prompts compared with Kimi K3. The company explicitly warns that its stress-test error rates do not represent everyday use. That caution belongs in large type. A lower hallucination rate does not turn a model into an auditor, adviser or source of record. A system can cite the wrong period, mix currencies, overlook a restatement, use a stale filing or build a correct formula on an incorrect assumption. Long context can let it see more pages. It does not guarantee that it selected the right sentence or carried the right number forward. Teams testing financial work should require cell-level or claim-level provenance. Every figure should link to a document, page and reporting period. Every generated spreadsheet formula should be inspectable. Material assumptions should be named. A person with the relevant responsibility should review the output before money, disclosure or compliance decisions move. The model's cyber section deserves the same precision. Kimi says it removed cyber-related material from parts of training before the planned open-weight release. On its internal xdev-bench-hard test, a checkpoint without those risk-reduction measures solved 90.5 percent of the selected vulnerability tasks at pass@3, while the release model reached 81.0 percent. Kimi argues that the difference shows the intervention reduced offensive capability while preserving general coding usefulness. That is an unusually concrete description of a safety tradeoff. It is still based on an internal benchmark and a comparison designed by the model maker. Independent researchers should test whether the reduction persists across other exploit tasks, languages, codebases and agent harnesses. They should also measure defensive utility: patch quality, false alarms, reproducer quality, time to remediation and whether suggested fixes create new vulnerabilities. The November 4 weight release will open another evaluation lane if it arrives as promised. Weights let independent teams inspect and run the model on infrastructure they control. They do not automatically reveal the training data, reinforcement-learning environments or complete development process. They also do not make a 3T-class system convenient to host. The API page describes the family as 3T-class. The previous K3 model is listed at 2.8 trillion total parameters. A mixture-of-experts architecture activates only a portion of the network for each token, which can reduce computation compared with using every parameter every time. Storage, memory, networking and serving remain serious engineering work. When the weights arrive, deployment guides should publish tested hardware, memory use, quantization, runtime versions, throughput, latency, power, context limits and task-quality changes. Open access needs an operating receipt too. There is a simple way for a team to start before touching production. Choose twenty to fifty jobs from real work, including failures and ugly edge cases. Remove or safely reproduce sensitive data. Run the same job contract across the candidate models. Give every model equivalent tools and a clear stopping rule. Repeat each task enough times to expose instability. Score the finished work, not the confidence of the answer. Did the code pass the tests? Did the financial claim point to the correct filing? Did the 3D asset meet the dimensions? Did the agent stay inside its permissions? How much repair did a person perform? Could another evaluator reconstruct the result from the trace? Then publish the failures inside the team. The most useful agent log is not a victory reel. It is a map of the places where the model lost an instruction, ignored a tool error, repeated an expensive step, cited a source it did not read or declared success before the test passed. K3.1 Pro may turn out to be a strong model for long, tool-heavy work. Its price reduction and one-million-token context make serious experiments easier to justify. The public benchmark table and detailed footnotes are a better start than a launch built from adjectives alone. The next step is to make the work inspectable. Give the agent a large desk. Then keep the receipt for everything it puts there, everything it removes and everything a human has to fix before the result becomes real.