65d30177ad
* feat(agent-core): record llm request trace in wire.jsonl Add three observability record types so every request sent to the model can be reconstructed from the wire log at the logical-request level: - llm.tools_snapshot: content-addressed snapshot of the top-level tools table as sent (post deferred-strip), written once per unique table - llm.request: one record per outbound request (retries, strict resends, and compaction rounds included) carrying the effective request params and hash links to the system prompt and tools snapshot - mcp.tools_discovered: the server's verbatim tools/list result plus the agent's gating (allow-list, collisions), deduplicated by content hash Observability records never feed state rebuild; replay only restores the write-dedup cursors. The records/types.ts contract now documents the two record classes explicitly (persisted is not the same as replayed). Recording happens at the single Agent.generate choke point. The LLMRequestLogFields side channel gains kind/projection/maxTokens/ droppedCount, chatWithRetry preserves caller-set fields, and compaction tags its requests. The vis wire view renders the new record kinds. * fix(agent-core): record the provider-clamped completion cap in the request trace The llm.request trace recorded the client-requested budget cap, but chat-completions providers tighten the actual wire value inside withMaxCompletionTokens (remaining-context sizing, transport ceilings, model-default resolution) — with the default budget the clamp is active on nearly every non-empty-context request, so the recorded value did not match what was sent. Providers now expose the effective cap they computed as a readonly maxCompletionTokens field on the clone, and the recorder reads it from the effective provider at the Agent.generate choke point. This replaces the side-channel recomputation, which is removed along with the appliedCompletionBudgetCap helper. * fix(agent-core): park pre-replay MCP discovery records and hash the collision outcome Two wire-hygiene fixes for the mcp.tools_discovered trace: Parking: the real Session ordering connects MCP servers concurrently with agent construction, so ToolManager can observe a connected server before agent.resume() has replayed the wire. Recording at that point bypassed the restored dedup cursor (duplicating a 1-50KB record on every resume) and appended a stray metadata record ahead of replay. AgentRecords now exposes a one-shot opened latch — set when replay completes (after the migration rewrite flushes) or when the first live record is logged — and ToolManager parks discoveries until then, re-running the dedup check at drain time. A frozen range-limited replay never opens; those agents are transient previews. Collision hashing: the dedup hash now covers the collision outcome, not just the raw list and allow-list. Collisions depend on which other servers hold a sanitized qualified name at registration time, so a server can re-register with identical tools but a flipped outcome; that gating change must produce a new record instead of being suppressed. * fix(agent-core): skip the request trace for pre-flight-aborted calls Mirror kosong generate()'s pre-flight abort check at the Agent.generate choke point: a call whose signal is already aborted never reaches the wire (generate throws before dispatching), so it must not leave an llm.request/llm.tools_snapshot trace or a diagnostic log line claiming a request was sent. Recording stays before dispatch for every call that passes the gate, preserving the crash-safety of the trace. * chore(agent-core): remove a leftover adaptive-thinking override hook The adaptiveThinkingOverride option was a temporary local hook explicitly marked for removal before commit. Nothing passes it, so resolution falls back to the alias-level adaptiveThinking value in all cases; drop the option and the dead indirection. * fix(kosong): derive the exposed completion cap from generation kwargs maxCompletionTokens was a field stored only by withMaxCompletionTokens, so caps that reach the wire through other paths were invisible to the request trace: with completion budgeting disabled via env, Anthropic still sends the constructor-resolved max_tokens (required by the Messages API), and constructor-level kwargs like OpenAILegacyOptions maxTokens were likewise unreported. Replace the stored field with a getter derived from each provider's generation kwargs — the single source the request body reads — covering constructor defaults, direct withGenerationKwargs configuration, and budget application in one place. Kimi mirrors its request-time legacy max_tokens alias normalization; openai-legacy reuses the same normalizeGenerationKwargs the request path uses. * feat(agent-core): add thinkingKeep passthrough for Kimi providers and update tests |
||
|---|---|---|
| .. | ||
| anthropic-preserved-thinking-by-default.md | ||
| config.json | ||
| fix-print-subagent-drain.md | ||
| fix-skills-dir-in-interactive-mode.md | ||
| hide-tool-result-system-notes.md | ||
| README.md | ||
| update-permission-mode-copy.md | ||
| wire-request-trace.md | ||
Changesets
This repository uses changesets to manage npm package versions and releases.
Package Publishing Strategy
This repository uses an independent, manually-selected publishing strategy. When generating a changeset, only select the publishable packages that this change actually affects. The repository's .changeset/config.json already filters out internal workspace packages via ignore, so only the publishable packages listed below should appear in the pnpm changeset prompt.
Current publishable packages:
| Package | Directory | Description |
|---|---|---|
@moonshot-ai/kimi-code |
apps/kimi-code |
CLI / TUI application — provides the kimi command after install |
@moonshot-ai/kimi-code-sdk |
packages/node-sdk |
Public TypeScript SDK |
All other workspace packages are private internal packages, are not published to npm, and are excluded via ignore in .changeset/config.json:
@moonshot-ai/acp-adapter@moonshot-ai/agent-core@moonshot-ai/kaos@moonshot-ai/kimi-code-oauth@moonshot-ai/kimi-telemetry@moonshot-ai/kimi-web@moonshot-ai/kosong@moonshot-ai/migration-legacy@moonshot-ai/protocol@moonshot-ai/server@moonshot-ai/server-e2e@moonshot-ai/vis@moonshot-ai/vis-server@moonshot-ai/vis-web
Version impact from internal dependencies must be judged manually. The published artifacts for CLI and SDK bundle internal workspace packages into the artifact itself; runtime dependencies of published packages must not include any @moonshot-ai/* internal workspace packages.
The repository's .changeset/config.json sets updateInternalDependencies: "patch". Because internal packages are not published, you still need to manually select all affected publishable packages in the changeset — do not rely solely on automatic dependency bumps to express user-visible changes.
Example scenarios:
| Change | Changeset selection |
|---|---|
Only modifies TUI behavior in @moonshot-ai/kimi-code |
Add patch / minor / major to @moonshot-ai/kimi-code |
| Only modifies internal packages, no user-visible change in SDK / CLI | Usually no changeset needed |
| Internal package fix changes the CLI user experience | Add a changeset to @moonshot-ai/kimi-code describing the user-visible fix |
| Internal package adds a new capability exposed by the SDK | Add a changeset to @moonshot-ai/kimi-code-sdk |
| SDK behavior change affects CLI user experience | Add changesets to both @moonshot-ai/kimi-code-sdk and @moonshot-ai/kimi-code |
| Provider abstraction change affects SDK / CLI | Add changesets to the affected @moonshot-ai/kimi-code-sdk and/or @moonshot-ai/kimi-code |
| Test-only, internal refactor, docs, or private debug tooling changes | Usually no changeset needed |
Bundled official plugin change under plugins/ (e.g. kimi-datasource) |
No changeset — the plugin is versioned via its own kimi.plugin.json / plugins/marketplace.json and shipped through the marketplace CDN, not the npm package |
Prerequisite: NPM Trusted Publishing (OIDC)
This repository uses npm's Trusted Publishing (OIDC-based) for publishing — no NPM_TOKEN is required.
Configuration steps
- Open each publishable package's page on the npm website, e.g.
https://www.npmjs.com/package/@moonshot-ai/kimi-code. - Go to Settings -> Publishing access.
- Find Automate publishing with GitHub Actions or Add trusted publisher.
- Click Add a new trusted publisher.
Fill in the following:
| Field | Value |
|---|---|
| GitHub Organization | MoonshotAI |
| GitHub Repository | kimi-code |
| GitHub Workflow | release.yml |
| Environment | leave empty |
Each publishable package needs its Trusted Publisher configured once. The current GitHub Actions workflow lives at .github/workflows/release.yml and already has id-token: write configured.
Development Workflow
1. Implement the feature or fix
Complete code, tests, and documentation changes as usual. A changeset is required when the change affects user-visible behavior, public API, dependency ranges, or release artifacts of a publishable package.
2. Generate a changeset
From the repository root:
pnpm changeset
Follow the prompts to choose:
- Which publishable packages this change affects;
- The version bump level:
patch: bug fixes, small changes, follow-up dependency updates;minor: backward-compatible new features;major: breaking changes;
- A user-facing description of the change.
The command creates a .changeset/*.md file that must be committed alongside the code.
3. Commit the changeset
git add .changeset/
git commit -m "chore: add changeset for package release"
git push
Commit messages must follow Conventional Commit style. Do not include any author/agent identity in the commit message.
4. CI generates the release PR
Once the changeset file is merged into main, .github/workflows/release.yml uses changesets/action@v1 to create or update a release PR.
The release PR runs:
pnpm changeset version: bumps publishable package versions and updates changelogs;- Deletes the consumed
.changeset/*.mdfiles; - Uses the title
[CI]: Release packages.
5. Merge the release PR
Once the release PR is merged into main, the same workflow runs:
pnpm install --frozen-lockfilepnpm buildpnpm changeset publish
The packages are then published via npm Trusted Publishing, and a GitHub Release is created.
Manual Publishing (Not Recommended)
Only publish manually when CI is unavailable. Before publishing manually, make sure you are logged into npm locally and using the Node.js and pnpm versions required by the repository.
pnpm run version
pnpm run publish
The underlying changesets commands are:
pnpm changeset version
pnpm changeset publish
The root-level pnpm run publish first runs typecheck, lint, sherif, test, build, and package lint, then runs changeset publish.
Notes
- Every PR that affects publishable-package behavior or public API should include a corresponding changeset.
- Changes under
plugins/(the bundled official plugins such askimi-datasource) do not need a changeset: each plugin carries its own version inkimi.plugin.jsonandplugins/marketplace.jsonand is distributed via the marketplace CDN, separately from the@moonshot-ai/kimi-codenpm package. - Changeset files must be committed to the repository — release PRs are only triggered after they're merged.
- Release PRs require human review and merge; they will not publish automatically.
- Do not add release changesets for private internal packages; only select
@moonshot-ai/kimi-codeand@moonshot-ai/kimi-code-sdk. - If a change in an underlying internal package alters user-visible behavior or public API of a publishable package, add a changeset to the affected publishable package. For example, when a bug fixed in
@moonshot-ai/agent-coreresolves an issue CLI users encounter, add a changeset to@moonshot-ai/kimi-codedescribing the user-visible fix. @moonshot-ai/kimi-codeis the official CLI package name; after a global install it provides thekimicommand.- Make sure each publishable package on npm has a Trusted Publisher configured.