K3 prompts differently: reasoning is always on, the 1M window means you paste sources instead of summaries, and a stable prompt prefix cuts input cost 90% via caching. These templates bake that in.
Unofficial tool. Not affiliated with Moonshot AI or Kimi. Prices and scores are gathered from public sources and may lag official changes.
Plan and execute a change across a large codebase
Leave fields blank to keep the sensible defaults. The output updates live.
You are a senior software engineer working inside a large repository. The full relevant source is provided below — use your 1M-token context to read it completely before proposing anything. ## Task Refactor the code as described. ## Constraints Preserve existing behavior. Keep the public API stable. ## Method 1. First map every file and call site the change touches. List them with one-line reasons. 2. Propose the migration order that keeps the repo compiling at every step. 3. Then produce the edits file by file, as unified diffs. 4. After the diffs, list the specific tests or commands I should run to verify each step, and what failure would indicate. Do not summarize files you were given — read them. If something you need is missing from the context, name the exact file path you expect instead of guessing its contents. [PASTE REPO FILES BELOW THIS LINE]
Copy, paste, replace the bracketed parts. Each one leans on something K3 is specifically good at.
I've pasted an unfamiliar codebase below. Give me the 20-minute onboarding a good tech lead would: (1) what the system does in two sentences, (2) the 5 files that matter most and why, (3) the request/data flow for the main use case, end to end with file:line references, (4) the three most dangerous areas to modify and what makes them dangerous, (5) what's clearly missing or fragile. Read everything first — with your context window there's no excuse to sample.
Review the diff below as a staff engineer who will be paged when this breaks. For each issue: severity (blocker/major/nit), the exact line, why it fails in production (not style preference), and a concrete fix. Then a verdict: approve, approve-with-nits, or request-changes — and the single most important change if I only fix one thing. Do not pad the review; three real issues beat ten nits.
You have shell access. Task: [DESCRIBE TASK]. Work in small verified steps: after every command, read the actual output before deciding the next command — never assume success. If output contradicts your expectation, diagnose before proceeding. When done, run an independent verification (different command than the one that did the work) proving the task succeeded, and show me that output.
Question: [YOUR QUESTION]. First argue the strongest honest case FOR, with sources. Then the strongest honest case AGAINST, with sources — same effort, same rigor. Only after both: your verdict, what evidence would change it, and which of the two cases required more strain to construct (that asymmetry is data). Do not hedge into 'it depends' — commit, with stated confidence.
Claim to check: [PASTE CLAIM]. Trace it to its origin: who said it first, in what context, based on what data. Rate it: true / true-but-misleading / false / unverifiable — and if misleading, state precisely what the accurate version would say. Show the chain from origin to the viral form and where distortion crept in. Primary sources only for the verdict.
Attached: a screenshot of broken UI plus the relevant component code. Compare what the code SHOULD render against what the screenshot SHOWS, element by element. List every discrepancy, then work backwards from the most severe one to the exact line of code responsible. If the bug can't be in the code shown, name the file you'd need next — don't guess at invisible code.
Attached is a photo of our whiteboard session. Transcribe everything legible, mark illegible parts as [unreadable] rather than guessing, then reconstruct it into a structured spec: goals, proposed architecture (as a mermaid diagram), open questions, and decisions that appear settled. Flag anything where the whiteboard is ambiguous and both readings would matter.
Rewrite the draft below to be clearer and 30% shorter — but keep my voice. Before editing, name three specific voice markers you observe in my draft (sentence rhythm, word choice, etc.) and preserve them. Show the result, then a change log of what you cut and why. If a cut loses real meaning rather than padding, keep the passage and flag it instead.
Three things. K3 always reasons — you don't need 'think step by step', but you should give it verification criteria to reason against. It has a real 1M-token context — paste whole repos and documents instead of summaries, and tell it explicitly not to skim. And cache pricing rewards a byte-stable prompt prefix: keep system prompts fixed and put changing data at the end of the message.
For agents and repeated workloads, yes — and keep it stable. Moonshot bills cache-hit input at $0.30 per 1M versus $3.00 fresh, so an unchanged system-prompt prefix cuts its cost ~90% after the first call. Anything that varies per request (timestamps, user names, retrieved data) belongs at the end of the user message, not in the system prompt.
No. K3's reasoning is always on and reasoning_effort only accepts max — asking it to think step by step mostly adds output tokens you pay $15/1M for. Spend your prompt budget on constraints, evidence, and definitions of done instead.
Say so explicitly and demand verbatim quotes with locations for every claim, plus a completeness check at the end. The long-doc template on this page does exactly that. Moonshot reports strong 1M-token recall, but models of every family drift toward summarizing unless the prompt makes exact reading the contract.
Yes — every prompt here works in the NottoAI chat. Sign in free, pick Kimi K3 from the model switcher, and paste. No Moonshot account or card needed.
Kimi K3 Toolkit
Sign in to NottoAI, pick Kimi K3 from the model switcher, and paste. No Moonshot key, no card.
No credit card required · 100 free credits included