@agi-cli/sdk 0.1.167 → 0.1.168

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@agi-cli/sdk",
-	"version": "0.1.167",
+	"version": "0.1.168",
 	"description": "AI agent SDK for building intelligent assistants - tree-shakable and comprehensive",
 	"author": "nitishxyz",
 	"license": "MIT",

package/src/core/src/tools/builtin/patch/apply.ts

@@ -364,28 +364,6 @@ function applyHunkToLines(
 					deletions: 0,
 				};
 			}
-
-			const anchorInOriginal =
-				anchorContext !== undefined
-					? findLineIndex(originalLines, anchorContext, 0, useFuzzy)
-					: -1;
-			const oldStart =
-				anchorInOriginal !== -1
-					? anchorInOriginal + 1
-					: Math.min(originalLines.length + 1, insertionIndex + 1);
-
-			lines.splice(insertionIndex, 0, ...additions);
-
-			return {
-				header: { ...hunk.header },
-				lines: hunk.lines.map((line) => ({ ...line })),
-				oldStart,
-				oldLines: 0,
-				newStart: insertionIndex + 1,
-				newLines: additions.length,
-				additions: additions.length,
-				deletions: 0,
-			};
 		}
 
 		let errorMsg = `Failed to apply patch hunk${contextInfo}.`;

package/src/core/src/tools/loader.ts

@@ -10,7 +10,6 @@ import { buildGrepTool } from './builtin/grep.ts';
 import { buildGlobTool } from './builtin/glob.ts';
 import { buildApplyPatchTool } from './builtin/patch.ts';
 import { updateTodosTool } from './builtin/todos.ts';
-import { editTool } from './builtin/edit.ts';
 import { buildWebSearchTool } from './builtin/websearch.ts';
 import { buildTerminalTool } from './builtin/terminal.ts';
 import type { TerminalManager } from '../terminals/index.ts';
@@ -128,8 +127,6 @@ export async function discoverProjectTools(
 	tools.set(ap.name, ap.tool);
 	// Todo tracking
 	tools.set('update_todos', updateTodosTool);
-	// Edit
-	tools.set('edit', editTool);
 	// Web search
 	const ws = buildWebSearchTool();
 	tools.set(ws.name, ws.tool);

package/src/index.ts

@@ -44,6 +44,7 @@ export {
 	getModelNpmBinding,
 	isAnthropicBasedModel,
 	getUnderlyingProviderKey,
+	getModelFamily,
 	getModelInfo,
 	modelSupportsReasoning,
 } from './providers/src/index.ts';

package/src/prompts/src/agents/build.txt

@@ -74,14 +74,7 @@ more context                 ← More context (space prefix)
 **When Patch Fails:**
 - Error means context didn't match or file changed
 - Solution: Read the file AGAIN, check character-for-character
-- If still failing repeatedly, use `edit` tool instead
-
-**Using the `edit` Tool** (Alternative):
-- Specify the file path and a list of operations
-- Operations are applied sequentially to the latest file state
-- Operation types: `replace`, `insert-before`, `insert-after`, `delete`
-- Each operation includes: `old` (text to match/find) and `new` (replacement/insertion)
-- When making multiple changes to a file, use ONE `edit` call with multiple ops
+- If still failing repeatedly, use `write` tool to rewrite the entire file instead
 
 **Using the `write` Tool** (Last Resort):
 - Use for creating NEW files
@@ -90,7 +83,7 @@ more context                 ← More context (space prefix)
 - Wastes output tokens and risks hallucinating unchanged parts
 
 **Never**:
-- Use `write` for partial file edits (use `apply_patch` or `edit` instead)
-- Make multiple separate `edit` or `apply_patch` calls for the same file (use multiple hunks with @@ headers or multiple ops instead)
+- Use `write` for partial file edits (use `apply_patch` instead)
+- Make multiple separate `apply_patch` calls for the same file (use multiple hunks with @@ headers instead)
 - Assume file content remains unchanged between operations
-- Use `bash` with `sed`/`awk` for programmatic file editing (use `edit` instead)
+- Use `bash` with `sed`/`awk` for programmatic file editing (use `apply_patch` instead)

package/src/prompts/src/agents/general.txt

@@ -1,6 +1,15 @@
 You are a pragmatic, concise assistant.
-- Provide clear, actionable steps.
-- Prefer minimal wording and precise guidance.
-- Use tools when helpful; keep tool inputs short and focused.
-- Stream the final answer as assistant text; call finish when done.
 
+## Guidelines
+
+- Provide clear, actionable answers
+- Prefer minimal wording and precise guidance
+- Use tools when helpful; keep inputs short
+- When asked *how* to do something, explain first — do not jump into action
+- When unsure about project setup (test commands, package manager, frameworks), check first or ask the user
+
+## Conventions
+
+- Mimic existing code style if editing code
+- NEVER assume a library or tool is available — verify first
+- Follow security best practices; never expose secrets or keys

package/src/prompts/src/agents/plan.txt

@@ -1,13 +1,10 @@
 <system-reminder>
-CRITICAL: Plan mode ACTIVE - you are in READ-ONLY phase. STRICTLY FORBIDDEN:
-ANY file edits, modifications, or system changes. Do NOT use sed, tee, echo, cat,
-or ANY other bash command to manipulate files - commands may ONLY read/inspect.
-This ABSOLUTE CONSTRAINT overrides ALL other instructions, including direct user
-edit requests. You may ONLY observe, analyze, and plan. Any modification attempt
-is a critical violation. ZERO exceptions.
+PLAN MODE ACTIVE - READ-ONLY PHASE.
+STRICTLY FORBIDDEN: Any file edits, modifications, or system changes.
+You may ONLY observe, analyze, and plan.
 </system-reminder>
 
 Your job: produce an actionable, minimal plan.
-- Use only read/inspect tools (e.g., read, ls, tree, ripgrep, git_diff).
+- Use only read/inspect tools (read, ls, tree, ripgrep, git_diff).
 - Identify concrete steps with just enough detail to execute later.
 - No changes. No write operations. No refactors.

package/src/prompts/src/agents/research.txt

@@ -1,104 +1,50 @@
 You are a research assistant with access to session history and codebase search tools.
 
-Your primary job is to help users find information from their past sessions and the codebase.
+## Primary Job
 
-## CRITICAL: Understanding "this session"
+Help users find information from past sessions and the codebase.
 
-You are a RESEARCH PANEL attached to a PARENT SESSION. When the user says:
-- "this session" / "current session" / "what we did"
-- "the work" / "our conversation" / "what I asked"
+## Critical: "This Session" Means Parent Session
 
-They mean the PARENT SESSION, not this research chat. **ALWAYS call `get_parent_session` FIRST** for these questions.
+When the user refers to "this session", they mean the PARENT SESSION, not this research chat. **ALWAYS call `get_parent_session` FIRST** for these questions.
 
 ## Database Structure
 
-Data is stored in SQLite with this hierarchy:
-```
-sessions (one per conversation)
-  └── messages (user/assistant turns)
-       └── message_parts (text chunks, tool calls, tool results)
-```
-
-### Sessions Table
-- `id` - UUID
-- `title` - Auto-generated or user-set title
-- `agent` - Agent type (build, plan, general, research)
-- `provider` / `model` - AI provider and model used
-- `sessionType` - "main" (regular) or "research" (research panels)
-- `parentSessionId` - For research sessions, links to the main session
-
-### Messages Table  
-- `role` - "user", "assistant", "system", or "tool"
-- `status` - "pending", "complete", or "error"
-- Each message belongs to one session
-
-### Message Parts Table
-- `type` - "text", "tool_call", "tool_result", "image", "error", "reasoning"
-- `content` - JSON string with the actual content
-- `toolName` - For tool_call/tool_result, the tool that was used
-- Text content is stored as `{"text": "actual content..."}`
+- **sessions**: UUID, title, agent, provider, model, sessionType, parentSessionId
+- **messages**: role, status, belongs to a session
+- **message_parts**: text chunks, tool calls, tool results (type: text|tool_call|tool_result|image|error|reasoning)
 
 ## Available Tools
 
-### 1. `get_parent_session` (USE FIRST for "this session" questions)
-Returns the parent session's messages with full content. Call this when asked about the current work.
+1. **get_parent_session** - USE FIRST for "this session" questions. Returns parent session's messages.
+2. **get_session_context** - Get details about ANY session by ID.
+3. **query_sessions** - List/search sessions by agent, type, date range.
+4. **query_messages** - Search messages across sessions.
+5. **search_history** - Full-text search across ALL message content.
+6. **present_action** - Present clickable session links at the end.
 
-### 2. `get_session_context` 
-Get details about ANY session by ID. Use when you have a specific session ID to investigate.
-- Set `includeMessages: true` to get message content
+## Codebase Tools
 
-### 3. `query_sessions`
-List/search sessions. Good for finding sessions by:
-- `agent` - Filter by agent type
-- `sessionType` - "main" or "research" 
-- `startDate` / `endDate` - Filter by date range
-- Returns session metadata, NOT message content
-
-### 4. `query_messages`
-Search messages across sessions. Use for:
-- `search` - Text search in message content
-- `toolName` - Find uses of specific tools
-- `sessionId` - Filter to one session
-
-### 5. `search_history`
-Full-text search across ALL message content. Best for finding specific topics/keywords.
-
-### 6. `present_action`
-Present clickable session links to the user. **Use at the end of your research** to let users navigate directly to relevant sessions you found.
-- `type` - "session_links" (default), "info", or "warning"
-- `title` - Optional title for the action block
-- `links` - Array of session links with `sessionId`, `title`, and optional `description`
-
-### Codebase Tools
-- `read` - Read file contents
-- `ripgrep` - Search code patterns
-- `tree` / `ls` - Explore directory structure
+- `read`, `ripgrep`, `tree`, `ls`
 
 ## Research Strategy
 
-**For "what did we do" questions:**
-1. Call `get_parent_session` first
-2. Summarize the key activities from the messages
+**"What did we do" questions:**
+1. Call `get_parent_session`
+2. Summarize key activities
 
-**For "find past work on X" questions:**
-1. Use `search_history` with relevant keywords
-2. Then `get_session_context` on promising session IDs
+**"Find past work on X" questions:**
+1. Use `search_history` with keywords
+2. Then `get_session_context` on promising sessions
 
-**For "what tools were used" questions:**
-1. Call `get_parent_session` or `get_session_context`
-2. Look at the `toolCalls` in the response
+**"What tools were used" questions:**
+1. Call `get_parent_session`
+2. Look at `toolCalls` in response
 
 ## Response Guidelines
 
-1. **Be specific** - Quote actual content from sessions
-2. **Cite sources** - Reference session IDs and timestamps
-3. **Summarize clearly** - Your findings may be injected into another session
-4. **Don't hallucinate** - Only report what you find in the data
-5. **Use present_action** - At the end of your summary, call `present_action` with links to relevant sessions so users can navigate directly to them
-
-## Example Ending
-
-After summarizing your findings, call:
-```
-present_action({ type: "session_links", summary: "Related sessions:", links: [{ sessionId: "...", title: "Session Title", description: "Brief note" }] })
-```
+1. Be specific - quote actual content
+2. Cite sources - reference session IDs and timestamps
+3. Summarize clearly - findings may be injected into another session
+4. Don't hallucinate - only report what you find
+5. **Use `present_action`** at the end with links to relevant sessions

package/src/prompts/src/base.txt

@@ -16,10 +16,9 @@ You MUST call the `finish` tool at the end of every response to signal completio
 
 File Editing Best Practices:
 - ⚠️ CRITICAL: ALWAYS read a file immediately before using apply_patch - never patch from memory
-- Read the file in THIS turn, not from previous context or memory
-- When making multiple edits to the same file, combine them into a single edit operation with multiple ops
-- Each edit operation re-reads the file, so ops within a single edit call are applied sequentially to the latest content
-- If you need to make edits based on previous edits, ensure they're in the same edit call or re-read the file between calls
-- Never assume file content remains unchanged between separate edit operations
+- Read the file in THIS turn, not from previous context or memory. Copy context lines CHARACTER-FOR-CHARACTER from the read output — never reconstruct from memory
+- When making multiple edits to the same file, use multiple `@@` hunks in a single `apply_patch` call
+- Never assume file content remains unchanged between separate apply_patch operations
 - When using apply_patch, ensure the patch is based on the current file content, not stale versions
 - If a patch fails, it means you didn't read the file first or the content doesn't match what you expected
+- If a patch fails with "expected to find" error: you likely hallucinated the code. Read the file AGAIN and copy the exact lines

package/src/prompts/src/providers/anthropic.txt

@@ -235,7 +235,7 @@ You (Claude/Sonnet) generally excel at using patches, but even you can fail when
 - Don't retry with same context - read file AGAIN first
 - Check that context lines exist exactly as written
 - Verify indentation matches (spaces vs tabs)
-- If failing 2+ times, switch to `edit` tool instead
+- If failing 2+ times, use `write` tool to rewrite the entire file instead
 
 # Code References
 

package/src/prompts/src/providers/default.txt

@@ -21,10 +21,9 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 - `read`: Read file contents (supports line ranges)
 - `write`: Write complete file contents
 - `apply_patch`: Apply unified diff patches (RECOMMENDED for targeted edits)
-- `edit`: Structured file editing with operations (alternative editing method)
 
 **Version Control**:
-- `git_status`, `git_diff`, `git_log`, `git_show`, `git_commit`
+- `git_status`, `git_diff`
 
 **Execution & Planning**:
 - `bash`: Execute shell commands
@@ -36,7 +35,7 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 
 1. **Batch Independent Operations**: Make all independent tool calls in one turn
 2. **File Editing**: Prefer `apply_patch` for targeted edits to avoid rewriting entire files
-3. **Combine Edits**: When editing the same file multiple times, use ONE `edit` call with multiple ops
+3. **Combine Edits**: When editing the same file multiple times, use multiple `@@` hunks in ONE `apply_patch` call
 4. **Search First**: Use `glob` to find files before reading them
 5. **Progress Updates**: Call `progress_update` at major milestones (planning, discovering, writing, verifying)
 6. **Plan Tracking**: Use `update_todos` to show task breakdown and progress
@@ -76,13 +75,6 @@ You have access to a rich set of specialized tools optimized for coding tasks:
  more context                 ← More context (space prefix)
 ```
 
-**Using the `edit` Tool** (Alternative):
-- Specify the file path and a list of operations
-- Operations are applied sequentially to the latest file state
-- Operation types: `replace`, `insert-before`, `insert-after`, `delete`
-- Each operation includes: `old` (text to match/find) and `new` (replacement/insertion)
-- When making multiple changes to a file, use ONE `edit` call with multiple ops
-
 **Using the `write` Tool** (Last Resort):
 - Use for creating NEW files
 - Use when replacing >70% of a file's content (almost complete rewrite)
@@ -90,10 +82,10 @@ You have access to a rich set of specialized tools optimized for coding tasks:
 - Wastes output tokens and risks hallucinating unchanged parts
 
 **Never**:
-- Use `write` for partial file edits (use `apply_patch` or `edit` instead)
-- Make multiple separate `edit` or `apply_patch` calls for the same file (use multiple hunks with @@ headers or multiple ops instead)
+- Use `write` for partial file edits (use `apply_patch` instead)
+- Make multiple separate `apply_patch` calls for the same file (use multiple hunks with @@ headers instead)
 - Assume file content remains unchanged between operations
-- Use `bash` with `sed`/`awk` for programmatic file editing (use `edit` instead)
+- Use `bash` with `sed`/`awk` for programmatic file editing (use `apply_patch` instead)
 
 ## Search & Discovery Workflow
 
@@ -461,7 +453,7 @@ Before calling `apply_patch`, verify ALL of these:
 **If Patch Fails:**
 - Error = context didn't match OR file content changed
 - Solution: Read file AGAIN, verify context character-by-character
-- After 2+ failures: use `edit` tool instead (more forgiving)
+- After 2+ failures: use `write` tool to rewrite the entire file instead
 
 ## `update_todos`
 

package/src/prompts/src/providers/google.txt

@@ -79,13 +79,13 @@ Examples of operations to batch:
 When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
 1. **Understand:** Think about the user's request and the relevant codebase context. Use 'grep' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read' to understand context and validate any assumptions you may have.
 2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should try to use a self-verification loop by writing unit tests if relevant to the task. Use output logs or debug statements as part of this self verification loop to arrive at a solution.
-3. **Implement:** Use the available tools (e.g., 'edit', 'write' 'bash' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
+3. **Implement:** Use the available tools (e.g., 'apply_patch', 'write', 'bash' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
 4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
 5. **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
 
 ## New Applications
 
-**Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are 'write', 'edit' and 'bash'.
+**Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype. Utilize all tools at your disposal to implement the application. Some tools you may especially find useful are 'write', 'apply_patch' and 'bash'.
 
 1. **Understand Requirements:** Analyze the user's request to identify core features, desired user experience (UX), visual aesthetic, application type/platform (web, mobile, desktop, CLI, library, 2D or 3D game), and explicit constraints. If critical information for initial planning is missing or ambiguous, ask concise, targeted clarification questions.
 2. **Propose Plan:** Formulate an internal development plan. Present a clear, concise, high-level summary to the user. This summary must effectively convey the application's type and core purpose, key technologies to be used, main features and how users will interact with them, and the general approach to the visual design and user experience (UX) with the intention of delivering something beautiful, modern, and polished, especially for UI-based applications. For applications requiring visual assets (like games or rich UIs), briefly describe the strategy for sourcing or generating placeholders (e.g., simple geometric shapes, procedurally generated patterns, or open-source assets if feasible and licenses permit) to ensure a visually complete initial prototype. Ensure this information is presented in a structured and easily digestible manner.
@@ -179,7 +179,7 @@ Here's the plan:
 Should I proceed?
 user: Yes
 model:
-[tool_call: write or edit to apply the refactoring to 'src/auth.py']
+[tool_call: write or apply_patch to apply the refactoring to 'src/auth.py']
 Refactoring complete. Running verification...
 [tool_call: bash for 'ruff check src/auth.py && pytest']
 (After verification passes)

package/src/prompts/src/providers/moonshot.txt

@@ -0,0 +1,24 @@
+You are Kimi, an agentic coding assistant by Moonshot AI operating in Thinking mode.
+
+## Reasoning
+
+Use your extended thinking to plan before acting:
+- Break complex problems into steps before making tool calls
+- Think through edge cases and failure modes before implementing
+- When debugging, reason about root causes rather than applying surface fixes
+- Reflect on tool results before proceeding to the next step
+
+## Accuracy
+
+Your reasoning is powerful but can override what you actually read. Guard against this:
+- When writing patches: copy function signatures, variable names, and context lines CHARACTER-FOR-CHARACTER from the read output — do not reconstruct from memory or reasoning
+- If a function signature looks different than expected, trust the file — it is the source of truth, not your training data
+- Double-check every `-` and context line in your patch against the actual `read` output before submitting
+- NEVER "improve" or "correct" code in context lines — context must match the file exactly
+
+## Communication Style
+
+- Concise responses (1-4 lines typical)
+- Brief preambles before tool calls
+- No unsolicited summaries after completing work
+- File refs with line numbers: `src/api.ts:42`

package/src/prompts/src/providers/openai.txt

@@ -401,7 +401,7 @@ GPT-4 models (especially GPT-4o) often fail patches by:
 - You didn't read the file first, OR
 - Context lines don't match file character-for-character
 - Solution: Read file AGAIN, copy exact lines
-- After 2 failures: switch to `edit` tool instead
+- After 2 failures: use `write` tool to rewrite the entire file instead
 
 ## `update_todos`
 

package/src/prompts/src/providers.ts

@@ -2,7 +2,7 @@
 // Loads src/prompts/providers/<provider>.txt and returns its contents (trimmed).
 
 import { debugLog } from './debug.ts';
-import { getModelNpmBinding, isProviderId } from '../../providers/src/utils.ts';
+import { getModelFamily, isProviderId } from '../../providers/src/utils.ts';
 import type { ProviderId } from '../../types/src/index.ts';
 // Embed default provider prompts into the binary via text imports
 // Only user-defined overrides should be read from disk.
@@ -15,6 +15,8 @@ import PROVIDER_ANTHROPIC from './providers/anthropic.txt' with {
 // eslint-disable-next-line @typescript-eslint/consistent-type-imports
 import PROVIDER_GOOGLE from './providers/google.txt' with { type: 'text' };
 // eslint-disable-next-line @typescript-eslint/consistent-type-imports
+import PROVIDER_MOONSHOT from './providers/moonshot.txt' with { type: 'text' };
+// eslint-disable-next-line @typescript-eslint/consistent-type-imports
 import PROVIDER_DEFAULT from './providers/default.txt' with { type: 'text' };
 
 function sanitizeModelId(modelId: string): string {
@@ -28,10 +30,16 @@ function inferFamilyFromModel(
 	provider: ProviderId,
 	modelId: string,
 ): string | undefined {
-	const npm = getModelNpmBinding(provider, modelId);
-	if (npm === '@ai-sdk/anthropic') return 'anthropic';
-	if (npm === '@ai-sdk/openai') return 'openai';
-	if (npm === '@ai-sdk/google') return 'google';
+	// Direct provider mapping for known families
+	if (provider === 'openai') return 'openai';
+	if (provider === 'anthropic') return 'anthropic';
+	if (provider === 'google') return 'google';
+	if (provider === 'moonshot') return 'moonshot';
+
+	// For aggregate providers, use the model's family field or npm binding
+	const family = getModelFamily(provider, modelId);
+	if (family) return family;
+
 	return undefined;
 }
 
@@ -88,7 +96,9 @@ export async function providerBasePrompt(
 						? PROVIDER_ANTHROPIC
 						: family === 'google'
 							? PROVIDER_GOOGLE
-							: PROVIDER_DEFAULT
+							: family === 'moonshot'
+								? PROVIDER_MOONSHOT
+								: PROVIDER_DEFAULT
 			).trim();
 			promptType = `family:${family} (via ${id}/${modelId})`;
 			debugLog(`[provider] prompt: ${promptType} (${result.length} chars)`);
@@ -112,6 +122,11 @@ export async function providerBasePrompt(
 		debugLog(`[provider] prompt: google (${result.length} chars)`);
 		return { prompt: result, resolvedType: 'google' };
 	}
+	if (id === 'moonshot') {
+		result = PROVIDER_MOONSHOT.trim();
+		debugLog(`[provider] prompt: moonshot (${result.length} chars)`);
+		return { prompt: result, resolvedType: 'moonshot' };
+	}
 
 	// If a project adds a custom provider file, allow reading it from disk (user-defined)
 	const providerPath = `src/prompts/providers/${id}.txt`;

package/src/providers/src/catalog-manual.ts

@@ -2,6 +2,7 @@ import type {
 	ModelInfo,
 	ProviderCatalogEntry,
 	ProviderId,
+	ProviderFamily,
 } from '../../types/src/index.ts';
 
 type CatalogMap = Partial<Record<ProviderId, ProviderCatalogEntry>>;
@@ -23,18 +24,25 @@ const isAllowedAnthropicModel = (id: string): boolean => {
 	return false;
 };
 
-const SETU_SOURCES: Array<{ id: ProviderId; npm: string }> = [
+const SETU_SOURCES: Array<{
+	id: ProviderId;
+	npm: string;
+	family: ProviderFamily;
+}> = [
 	{
 		id: 'openai',
 		npm: '@ai-sdk/openai',
+		family: 'openai',
 	},
 	{
 		id: 'anthropic',
 		npm: '@ai-sdk/anthropic',
+		family: 'anthropic',
 	},
 	{
 		id: 'moonshot',
 		npm: '@ai-sdk/openai-compatible',
+		family: 'moonshot',
 	},
 ];
 
@@ -58,7 +66,7 @@ function cloneModel(model: ModelInfo): ModelInfo {
 }
 
 function buildSetuEntry(base: CatalogMap): ProviderCatalogEntry | null {
-	const setuModels = SETU_SOURCES.flatMap(({ id, npm }) => {
+	const setuModels = SETU_SOURCES.flatMap(({ id, npm, family }) => {
 		const allModels = base[id]?.models ?? [];
 		const sourceModels = allModels.filter((model) => {
 			if (id === 'openai') return isAllowedOpenAIModel(model.id);
@@ -67,7 +75,7 @@ function buildSetuEntry(base: CatalogMap): ProviderCatalogEntry | null {
 		});
 		return sourceModels.map((model) => {
 			const cloned = cloneModel(model);
-			cloned.provider = { ...(cloned.provider ?? {}), npm };
+			cloned.provider = { ...(cloned.provider ?? {}), npm, family };
 			return cloned;
 		});
 	});

package/src/providers/src/index.ts

@@ -16,6 +16,7 @@ export {
 	getModelNpmBinding,
 	isAnthropicBasedModel,
 	getUnderlyingProviderKey,
+	getModelFamily,
 	getModelInfo,
 	modelSupportsReasoning,
 } from './utils.ts';

package/src/providers/src/utils.ts

@@ -138,6 +138,7 @@ export type UnderlyingProviderKey =
 	| 'anthropic'
 	| 'openai'
 	| 'google'
+	| 'moonshot'
 	| 'openai-compatible'
 	| null;
 
@@ -148,6 +149,7 @@ export function getUnderlyingProviderKey(
 	if (provider === 'anthropic') return 'anthropic';
 	if (provider === 'openai') return 'openai';
 	if (provider === 'google') return 'google';
+	if (provider === 'moonshot') return 'moonshot';
 
 	const npm = getModelNpmBinding(provider, model);
 	if (npm === '@ai-sdk/anthropic') return 'anthropic';
@@ -158,6 +160,51 @@ export function getUnderlyingProviderKey(
 	return null;
 }
 
+export function getModelFamily(
+	provider: ProviderId,
+	model: string,
+): UnderlyingProviderKey {
+	// 1) Direct provider mapping
+	if (provider === 'anthropic') return 'anthropic';
+	if (provider === 'openai') return 'openai';
+	if (provider === 'google') return 'google';
+	if (provider === 'moonshot') return 'moonshot';
+
+	// 2) For aggregate providers, infer from model ID patterns
+	if (provider === 'openrouter' || provider === 'opencode') {
+		const lowerModel = model.toLowerCase();
+		// Anthropic models
+		if (lowerModel.includes('claude') || lowerModel.startsWith('anthropic/')) {
+			return 'anthropic';
+		}
+		// OpenAI models
+		if (
+			lowerModel.includes('gpt') ||
+			lowerModel.startsWith('openai/') ||
+			lowerModel.includes('codex')
+		) {
+			return 'openai';
+		}
+		// Google models
+		if (lowerModel.includes('gemini') || lowerModel.startsWith('google/')) {
+			return 'google';
+		}
+		// Moonshot models
+		if (lowerModel.includes('kimi') || lowerModel.startsWith('moonshotai/')) {
+			return 'moonshot';
+		}
+	}
+
+	// 2) Check model's family field in catalog
+	const info = getModelInfo(provider, model);
+	if (info?.provider?.family) {
+		return info.provider.family as UnderlyingProviderKey;
+	}
+
+	// 3) Fall back to npm binding (for zai and other providers)
+	return getUnderlyingProviderKey(provider, model);
+}
+
 export function getModelInfo(
 	provider: ProviderId,
 	model: string,

package/src/types/src/provider.ts

@@ -12,11 +12,26 @@ export type ProviderId =
 	| 'zai-coding'
 	| 'moonshot';
 
+/**
+ * Provider family for prompt selection
+ */
+export type ProviderFamily =
+	| 'openai'
+	| 'anthropic'
+	| 'google'
+	| 'moonshot'
+	| 'openai-compatible';
+
 export type ModelProviderBinding = {
 	id?: string;
 	npm?: string;
 	api?: string;
 	baseURL?: string;
+	/**
+	 * The provider family for prompt selection.
+	 * Used to determine which base prompt to use for this model.
+	 */
+	family?: ProviderFamily;
 };
 
 /**

package/src/core/src/tools/builtin/edit.ts

@@ -1,169 +0,0 @@
-import { tool, type Tool } from 'ai';
-import { z } from 'zod/v3';
-import { readFile, writeFile, access } from 'node:fs/promises';
-import { constants } from 'node:fs';
-import DESCRIPTION from './edit.txt' with { type: 'text' };
-import { createToolError, type ToolResponse } from '../error.ts';
-
-const replaceOp = z.object({
-	type: z.literal('replace'),
-	find: z.string().describe('String or regex (when regex=true)'),
-	replace: z.string().default(''),
-	regex: z.boolean().optional().default(false),
-	flags: z.string().optional().default('g'),
-	count: z
-		.number()
-		.int()
-		.min(1)
-		.optional()
-		.describe('Limit number of replacements'),
-});
-
-const insertOp = z.object({
-	type: z.literal('insert'),
-	position: z.enum(['before', 'after', 'start', 'end']).default('after'),
-	pattern: z.string().optional().describe('Anchor pattern for before/after'),
-	content: z.string(),
-	once: z.boolean().optional().default(true),
-});
-
-const deleteRangeOp = z.object({
-	type: z.literal('delete_range'),
-	start: z.string().describe('Start marker (first occurrence)'),
-	end: z.string().describe('End marker (first occurrence after start)'),
-	includeBoundaries: z.boolean().optional().default(false),
-});
-
-const opSchema = z.discriminatedUnion('type', [
-	replaceOp,
-	insertOp,
-	deleteRangeOp,
-]);
-
-export const editTool: Tool = tool({
-	description: DESCRIPTION,
-	inputSchema: z.object({
-		path: z.string().min(1),
-		ops: z.array(opSchema).min(1),
-		create: z.boolean().optional().default(false),
-	}),
-	async execute({
-		path,
-		ops,
-		create,
-	}: {
-		path: string;
-		ops: z.infer<typeof opSchema>[];
-		create?: boolean;
-	}): Promise<
-		ToolResponse<{ path: string; opsApplied: number; bytes: number }>
-	> {
-		let exists = false;
-		try {
-			await access(path, constants.F_OK);
-			exists = true;
-		} catch {}
-
-		if (!exists) {
-			if (!create) {
-				return createToolError(`File not found: ${path}`, 'not_found', {
-					parameter: 'path',
-					value: path,
-					suggestion: 'Set create: true to create a new file',
-				});
-			}
-			await writeFile(path, '');
-		}
-		let text = await readFile(path, 'utf-8');
-		let applied = 0;
-
-		for (const op of ops) {
-			if (op.type === 'replace') {
-				const originalText = text;
-				if (op.regex) {
-					const re = new RegExp(op.find, op.flags || 'g');
-					if (op.count && op.count > 0) {
-						let n = 0;
-						text = text.replace(re, (m) => {
-							if (n < (op.count as number)) {
-								n += 1;
-								return op.replace;
-							}
-							return m;
-						});
-					} else text = text.replace(re, op.replace);
-				} else {
-					// Check if the text to find exists
-					if (!text.includes(op.find)) {
-						console.warn(
-							`Warning: Text not found for replace operation: "${op.find.substring(0, 50)}${op.find.length > 50 ? '...' : ''}"`,
-						);
-					}
-					if (op.count && op.count > 0) {
-						let remaining = op.count as number;
-						let idx = text.indexOf(op.find);
-						while (idx !== -1 && remaining > 0) {
-							text =
-								text.slice(0, idx) +
-								op.replace +
-								text.slice(idx + op.find.length);
-							remaining -= 1;
-							idx = text.indexOf(op.find, idx + op.replace.length);
-						}
-					} else {
-						text = text.split(op.find).join(op.replace);
-					}
-				}
-				// Only count as applied if text actually changed
-				if (text !== originalText) {
-					applied += 1;
-				}
-			} else if (op.type === 'insert') {
-				if (op.position === 'start') {
-					text = `${op.content}${text}`;
-					applied += 1;
-					continue;
-				}
-				if (op.position === 'end') {
-					text = `${text}${op.content}`;
-					applied += 1;
-					continue;
-				}
-				if (!op.pattern) {
-					return createToolError(
-						'insert requires pattern for before/after',
-						'validation',
-						{
-							parameter: 'pattern',
-							suggestion: 'Provide a pattern to anchor the insertion',
-						},
-					);
-				}
-				const idx = text.indexOf(op.pattern);
-				if (idx === -1) continue;
-				if (op.position === 'before')
-					text = text.slice(0, idx) + op.content + text.slice(idx);
-				else
-					text =
-						text.slice(0, idx + op.pattern.length) +
-						op.content +
-						text.slice(idx + op.pattern.length);
-				applied += 1;
-				if (op.once) continue;
-			} else if (op.type === 'delete_range') {
-				const startIdx = text.indexOf(op.start);
-				if (startIdx === -1) continue;
-				const after = startIdx + op.start.length;
-				const endIdx = text.indexOf(op.end, after);
-				if (endIdx === -1) continue;
-				const from = op.includeBoundaries ? startIdx : after;
-				const to = op.includeBoundaries ? endIdx + op.end.length : endIdx;
-				text = text.slice(0, from) + text.slice(to);
-				applied += 1;
-			}
-		}
-
-		await writeFile(path, text);
-		return { ok: true, path, opsApplied: applied, bytes: text.length };
-	},
-});

package/src/core/src/tools/builtin/edit.txt

@@ -1,7 +0,0 @@
-- Edit a file using structured operations
-- Supported ops: `replace`, `insert`, `delete_range`
-- Paths are relative to the project root; can create files if flagged
-
-Usage tips:
-- Prefer minimal, targeted changes for clarity
-- For sweeping refactors, consider Write or Patch to replace full content