Kimi PhD-level tutorial

PhD-level · step 1 of 7

How it works under the hood

General background (not a vendor claim): AI assistants are built on large models that turn your input into tokens and predict likely output, sampling from a probability distribution. Everything they 'remember' in a session lives in a finite context window. Tools such as web search, file reading or code execution add facts the model didn't have; without them, it answers from training data, which can be out of date.

Why this step matters: Knowing it predicts text rather than looks facts up explains why it can be fluent and wrong at once.

PhD-level · step 2 of 7

API and automation

Moonshot AI offers its Kimi models to developers on a separate platform with its own pricing. We did not verify the API price list on Oct 30, 2026, so check the official developer pages before building on it.

Why this step matters: Automation repeats mistakes at scale, so you need to know exactly what is run and what is checked.

PhD-level · step 3 of 7

Evaluation methodology

Define success criteria and a way to test against them before tuning prompts. That applies to every bot.

1. Write a rubric: correctness, sourcing, format, refusal behaviour.
2. Build a golden set of 20–50 inputs with reference answers.
3. Score blind, ideally with two reviewers; compare pairs (A vs B) rather than absolute scores.
4. Run each item 3 times; outputs are non-deterministic.
5. Track regressions after any model or prompt change.

Why this step matters: Without a fixed test set, 'better' just means 'felt better'. Scores let you compare prompts and models fairly.

PhD-level · step 4 of 7

Advanced prompting and agents

• Prompt chaining: one job per call, checked between calls.
• Few-shot examples: show 2–3 input/output pairs in the format you want.
• Tool use: keep tools narrow and require approval for anything that sends, buys or deletes.
• Protocols like the Model Context Protocol (modelcontextprotocol.io) standardise how assistants connect to tools and data.

Why this step matters: The same model gives much better answers to a specific prompt. This is the cheapest improvement you can make.

PhD-level · step 5 of 7

Failure modes in depth

• Long summaries that blend two sections. Ask for page numbers.
• Agents that take a confident wrong turn early. Review the plan.
• Credit-hungry runs on big files. Test on a sample first.
• Prompt injection: instructions hidden in a web page or file can steer the model. Treat fetched content as data, not commands.
• Sycophancy: it may agree with a wrong premise. Ask it to argue the other side.

Why this step matters: Knowing how it typically fails tells you where to look when you review its work.

PhD-level · step 6 of 7

Reliability engineering

• Validate structured output against a schema; retry on failure.
• Log inputs, outputs, model and settings so you can reproduce results.
• Make tool actions idempotent and reversible where possible.
• Put a human approval step in front of anything external.

Why this step matters: Retries, fallbacks and logged runs turn an occasionally-right tool into one you can depend on.

PhD-level · step 7 of 7

Reading list (official)

• Kimi membership pricing: Plus, Pro, Max, Ultra prices; shared credit pool; no rollover; Kimi Code 5-hour limit; Goal Mode and Kimi Claw on Pro

Why this step matters: Official docs change; going to the source beats any summary, including this one.