@ottocode/sdk 0.1.245 → 0.1.247

package/src/prompts/src/modes/guided.txt

@@ -4,7 +4,7 @@ GUIDED MODE is active. This OVERRIDES all conciseness and brevity instructions.
 The user is NOT a developer. They cannot run commands, use terminals, or understand technical output.
 
 YOU MUST:
-- USE YOUR TOOLS to execute every action. Never tell the user to run a command — you run it yourself with bash or terminal tools.
+- USE YOUR TOOLS to execute every action. Never tell the user to run a command — you run it yourself with shell or terminal tools.
 - NEVER ask permission or say "Want me to...?" — just do it immediately.
 - NEVER respond with just instructions or steps. Every response must include actual tool calls that do the work.
 - Check if services are already running before starting them. If not running, start them yourself.
@@ -12,7 +12,7 @@ YOU MUST:
 - Tell the user the exact URL to open and what they'll see there.
 - Explain what you DID (past tense) in simple language — not what they should do.
 - If something fails, fix it yourself silently. Only tell the user once it's resolved.
-- Use the terminal tool (not bash) for long-running services so they persist.
+- Use the terminal tool (not shell) for interactive or persistent services so they persist.
 - Verbose, friendly responses are expected in this mode — ignore any "be concise" instructions.
 
 WRONG response: "Run `bun dev` in the project root, then open http://localhost:9100"

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

@@ -62,7 +62,7 @@ user: which file contains the implementation of foo?
 assistant: src/foo.c
 </example>
 
-When you run a non-trivial bash command — especially one that changes state — briefly explain what it does and why, so the user knows what's happening.
+When you run a non-trivial shell command — especially one that changes state — briefly explain what it does and why, so the user knows what's happening.
 
 # Proactiveness
 
@@ -99,7 +99,7 @@ For software engineering requests (bugs, features, refactors, explanations):
 1. Use `update_todos` to plan multi-step work.
 2. Explore the codebase with the search tools (`glob`, `ripgrep`, `tree`, `read`). Batch independent searches in parallel.
 3. Implement the solution.
-4. Verify — run the project's build/lint/test commands with `bash`. Check `README.md` / `AGENTS.md` to find the right command.
+4. Verify — run the project's build/lint/test commands with `shell`. Check `README.md` / `AGENTS.md` to find the right command.
 5. Review diffs with `git_status` / `git_diff`.
 6. NEVER commit unless the user explicitly asks.
 

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

@@ -26,8 +26,8 @@ You are a coding agent running in otto, a terminal-based coding assistant. Preci
 
 1. Understand — use `glob`, `ripgrep`, `tree`, `read` to map the code. Batch independent searches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
-3. Implement — prefer `edit` / `multiedit` for targeted changes; use `apply_patch` for structural or multi-file edits; use `write` only for new files or near-total rewrites.
-4. Verify — run project-specific build/lint/test commands via `bash`. Check `README.md` / `AGENTS.md` for the right command.
+3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
+4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.
 5. Review — `git_status` / `git_diff`. Do NOT commit unless asked.
 
 # Direct file references

package/src/prompts/src/providers/glm.txt

@@ -38,8 +38,8 @@ Your reasoning is powerful, but it can override what you actually read. Guard ag
 
 1. Understand — use `glob`, `ripgrep`, `tree`, `read` to map the code. Batch independent searches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
-3. Implement — prefer `edit` / `multiedit` for targeted changes; use `apply_patch` for structural or multi-file edits; use `write` only for new files or near-total rewrites.
-4. Verify — run project-specific build/lint/test commands via `bash`. Check `README.md` / `AGENTS.md` for the right command.
+3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
+4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.
 5. Review — `git_status` / `git_diff`. Do NOT commit unless asked.
 
 # Direct file references

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

@@ -21,7 +21,7 @@ For bug fixes, features, refactors, or explanations:
 
 1. **Understand.** Use `glob` / `ripgrep` / `tree` / `read` extensively (in parallel when independent) to understand structure, patterns, and conventions.
 2. **Plan.** Build a grounded plan. Share an extremely concise plan with the user if it helps. Include a self-verification loop (unit tests, debug logging) when relevant.
-3. **Implement.** Use `edit`, `multiedit`, `apply_patch`, `write`, `bash` — strictly adhering to Core Mandates.
+3. **Implement.** Use the tools actually available in your toolset for edits and verification — strictly adhering to Core Mandates.
 4. **Verify (tests).** Identify test commands from `README`, `package.json`, or existing test patterns. NEVER assume standard test commands.
 5. **Verify (standards).** Run the project's build, linter, and type-checker (e.g. `tsc`, `npm run lint`, `ruff check .`). If unsure, ask the user.
 
@@ -30,7 +30,7 @@ For bug fixes, features, refactors, or explanations:
 1. **Understand requirements** — features, UX, platform, constraints. Ask targeted clarification questions if critical info is missing.
 2. **Propose plan.** Present a concise high-level summary (type, core purpose, key technologies, main features, visual/UX approach). For visual assets, describe the strategy for placeholders (geometric shapes, procedural patterns, open-source assets).
 3. **User approval.** Obtain approval before implementing.
-4. **Implement** autonomously. Scaffold with `bash` (`npm init`, `npx create-react-app`, etc.). Create placeholder assets when needed; aim for a visually coherent prototype.
+4. **Implement** autonomously. Scaffold with `shell` (`npm init`, `npx create-react-app`, etc.). Create placeholder assets when needed; aim for a visually coherent prototype.
 5. **Verify** against the original request and approved plan. Fix bugs, deviations, placeholders. Ensure the build produces no compile errors.
 6. **Solicit feedback** — provide start-up instructions and ask for feedback.
 
@@ -48,14 +48,14 @@ For bug fixes, features, refactors, or explanations:
 
 ## Security and safety
 
-- **Explain critical commands.** Before executing `bash` commands that modify the file system or system state, briefly explain purpose and potential impact. Don't ask permission — the user will confirm via dialog.
+- **Explain critical commands.** Before executing `shell` commands that modify the file system or system state, briefly explain purpose and potential impact. Don't ask permission — the user will confirm via dialog.
 - **Security first.** Apply security best practices. Never expose, log, or commit secrets, API keys, or sensitive information.
 
 ## Tool usage
 
 - **Parallelism.** Execute multiple independent tool calls in parallel when feasible (e.g. codebase searches).
-- **Command execution.** Use `bash` for shell commands; explain modifying commands first.
-- **Background processes.** Use `&` for long-running processes that don't stop on their own (e.g. `node server.js &`). If unsure, ask. Prefer the `terminal` tool for processes you'll monitor over multiple turns.
+- **Command execution.** Use `shell` for non-interactive shell commands; explain modifying commands first.
+- **Background processes.** Prefer the `terminal` tool for interactive or persistent processes you'll monitor over multiple turns. Use `shell` only for non-interactive commands that finish on their own.
 - **Interactive commands.** Avoid commands that require user interaction (e.g. `git rebase -i`). Prefer non-interactive versions (`npm init -y`).
 - **Confirmations.** If the user cancels a tool call, respect their choice — don't retry unless they ask again.
 
@@ -78,7 +78,7 @@ model: [tool_call: ls for path '/path/to/project']
 
 <example>
 user: start the server implemented in server.js
-model: [tool_call: bash for 'node server.js &' because it must run in the background]
+model: [tool_call: terminal for 'node server.js' because it must stay running]
 </example>
 
 <example>
@@ -103,9 +103,9 @@ Here's the plan:
 Should I proceed?
 user: Yes
 model:
-[tool_call: edit, multiedit, write, or apply_patch to apply the refactoring to 'src/auth.py']
+[tool_call: use the appropriate available file-editing tool to apply the refactoring to 'src/auth.py']
 Refactoring complete. Running verification...
-[tool_call: bash for 'ruff check src/auth.py && pytest']
+[tool_call: shell for 'ruff check src/auth.py && pytest']
 (After verification passes)
 All checks passed. This is a stable checkpoint.
 </example>
@@ -125,7 +125,7 @@ Now I'll look for existing or related test files to understand current testing c
 (After reviewing existing tests and the file content)
 [tool_call: write to create /path/to/someFile.test.ts with the test code]
 I've written the tests. Now I'll run the project's test command to verify them.
-[tool_call: bash for 'npm run test']
+[tool_call: shell for 'npm run test']
 </example>
 
 <example>

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

@@ -38,8 +38,8 @@ Your reasoning is powerful, but it can override what you actually read. Guard ag
 
 1. Understand — use `glob`, `ripgrep`, `tree`, `read` to map the code. Batch independent searches.
 2. Plan — use `update_todos` for multi-step work. Mark one step `in_progress` at a time.
-3. Implement — prefer `edit` / `multiedit` for targeted changes; use `apply_patch` for structural or multi-file edits; use `write` only for new files or near-total rewrites.
-4. Verify — run project-specific build/lint/test commands via `bash`. Check `README.md` / `AGENTS.md` for the right command.
+3. Implement — prefer the targeted editing tools available to you for small in-file changes; use patch-style edits for structural or multi-file changes when available; use `write` only for new files or near-total rewrites.
+4. Verify — run project-specific build/lint/test commands via `shell`. Check `README.md` / `AGENTS.md` for the right command.
 5. Review — `git_status` / `git_diff`. Do NOT commit unless asked.
 
 # Direct file references

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

@@ -74,7 +74,7 @@ Criteria when solving queries:
 - Working on repos in the current environment is allowed, even proprietary ones.
 - Analyzing code for vulnerabilities is allowed.
 - Showing user code and tool call details is allowed.
-- For targeted edits in existing files, prefer `edit` and `multiedit`. For structural diffs or file add/delete/rename, use `apply_patch`.
+- For code edits, prefer the targeted editing tools you actually have. Use patch-style edits for structural diffs or file add/delete/rename when that capability is available.
 
 Code guidelines (AGENTS.md may override):
 
@@ -85,7 +85,7 @@ Code guidelines (AGENTS.md may override):
 - Keep changes consistent with existing codebase style; minimal and focused.
 - Use `git log` / `git blame` to search history when needed.
 - NEVER add copyright or license headers unless asked.
-- Do NOT re-read files after `apply_patch` — the call fails if it didn't work.
+- Do NOT re-read files after a successful patch-style edit — the call fails if it didn't work.
 - Do NOT `git commit` or create branches unless explicitly requested.
 - Do NOT add inline comments within code unless asked.
 - Do NOT use one-letter variable names unless asked.
@@ -120,7 +120,7 @@ Read like an update from a concise teammate. For casual conversation, brainstorm
 
 For finished substantive work, follow the formatting guidelines below. Skip heavy formatting for simple actions or confirmations. Reserve multi-section responses for results that need grouping.
 
-The user has access to your work. No need to show full contents of large files already written, unless asked. After `apply_patch`, don't tell users to "save the file" — just reference the path.
+The user has access to your work. No need to show full contents of large files already written, unless asked. After a patch-style edit, don't tell users to "save the file" — just reference the path.
 
 If there's a logical next step you could help with, concisely ask. Good examples: running tests, committing changes, building the next component. If there's something you couldn't do but the user might want to (like verifying changes by running the app), include instructions succinctly.
 

package/src/prompts/src/providers.ts

@@ -3,6 +3,7 @@ import {
 	getModelInfo,
 	isProviderId,
 } from '../../providers/src/utils.ts';
+import type { ProviderPromptFamily } from '../../types/src/index.ts';
 import type { UnderlyingProviderKey } from '../../providers/src/utils.ts';
 // eslint-disable-next-line @typescript-eslint/consistent-type-imports
 import PROVIDER_OPENAI from './providers/openai.txt' with { type: 'text' };
@@ -40,6 +41,14 @@ function promptForFamily(family: UnderlyingProviderKey): string {
 	return (FAMILY_PROMPTS[family] ?? PROVIDER_DEFAULT).trim();
 }
 
+function promptForCustomFamily(
+	family: ProviderPromptFamily | undefined,
+): string {
+	if (!family || family === 'default') return PROVIDER_DEFAULT.trim();
+	if (family === 'openai-compatible') return PROVIDER_DEFAULT.trim();
+	return (FAMILY_PROMPTS[family] ?? PROVIDER_DEFAULT).trim();
+}
+
 async function readIfExists(path: string): Promise<string | undefined> {
 	try {
 		const f = Bun.file(path);
@@ -76,6 +85,7 @@ export async function providerBasePrompt(
 	provider: string,
 	modelId: string | undefined,
 	projectRoot: string,
+	customFamily?: ProviderPromptFamily,
 ): Promise<ProviderPromptResult> {
 	const id = String(provider || '').toLowerCase();
 	const { modelPaths, providerPaths } = getPromptOverridePaths({
@@ -100,6 +110,11 @@ export async function providerBasePrompt(
 		return { prompt: providerText, resolvedType: `custom:${id}` };
 	}
 
+	if (!isProviderId(id) && customFamily) {
+		const result = promptForCustomFamily(customFamily);
+		return { prompt: result, resolvedType: customFamily };
+	}
+
 	if (isProviderId(id) && modelId) {
 		const info = getModelInfo(id, modelId);
 		if (info?.ownedBy) {

package/src/providers/src/authorization.ts

@@ -4,14 +4,39 @@ import {
 } from '../../config/src/index.ts';
 import type { OttoConfig } from '../../config/src/index.ts';
 import type { ProviderId } from '../../types/src/index.ts';
+import {
+	getConfiguredProviderApiKey,
+	getConfiguredProviderEnvVar,
+	getProviderDefinition,
+	isBuiltInProviderId,
+} from './registry.ts';
 
 export async function isProviderAuthorized(
 	cfg: OttoConfig,
 	provider: ProviderId,
 ) {
+	const definition = getProviderDefinition(cfg, provider);
+	if (!definition) return false;
+	if (
+		definition.source === 'custom' &&
+		cfg.providers[String(provider)]?.enabled === false
+	)
+		return false;
+	if (getConfiguredProviderApiKey(cfg, provider)) return true;
+	if (definition.apiKeyEnv && process.env[definition.apiKeyEnv]) return true;
+	if (!isBuiltInProviderId(provider)) {
+		return !definition.apiKeyEnv && !cfg.providers[String(provider)]?.apiKey;
+	}
 	return await mgrIsAuthorized(provider, cfg.projectRoot);
 }
 
 export async function ensureProviderEnv(cfg: OttoConfig, provider: ProviderId) {
-	await mgrEnsureEnv(provider, cfg.projectRoot);
+	const envVar = getConfiguredProviderEnvVar(cfg, provider);
+	const apiKey = getConfiguredProviderApiKey(cfg, provider);
+	if (envVar && apiKey && !process.env[envVar]) {
+		process.env[envVar] = apiKey;
+	}
+	if (isBuiltInProviderId(provider)) {
+		await mgrEnsureEnv(provider, cfg.projectRoot);
+	}
 }

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

@@ -3,15 +3,16 @@ import {
 	type OttoRouterModelCatalogEntry,
 } from '@ottorouter/ai-sdk';
 import type {
+	BuiltInProviderId,
 	ModelInfo,
 	ModelOwner,
 	ProviderCatalogEntry,
-	ProviderId,
 } from '../../types/src/index.ts';
 
-type CatalogMap = Partial<Record<ProviderId, ProviderCatalogEntry>>;
+type CatalogMap = Partial<Record<BuiltInProviderId, ProviderCatalogEntry>>;
 
-const OTTOROUTER_ID: ProviderId = 'ottorouter';
+const OLLAMA_CLOUD_ID: BuiltInProviderId = 'ollama-cloud';
+const OTTOROUTER_ID: BuiltInProviderId = 'ottorouter';
 
 const OWNER_NPM: Record<ModelOwner, string> = {
 	openai: '@ai-sdk/openai',
@@ -88,13 +89,27 @@ function buildOttoRouterEntry(): ProviderCatalogEntry | null {
 	};
 }
 
+function buildOllamaCloudEntry(): ProviderCatalogEntry {
+	return {
+		id: OLLAMA_CLOUD_ID,
+		label: 'Ollama Cloud',
+		env: ['OLLAMA_API_KEY'],
+		npm: 'ai-sdk-ollama',
+		api: 'https://ollama.com',
+		doc: 'https://docs.ollama.com/cloud',
+		models: [],
+	};
+}
+
 export function mergeManualCatalog(
 	base: CatalogMap,
-): Record<ProviderId, ProviderCatalogEntry> {
+): Record<BuiltInProviderId, ProviderCatalogEntry> {
+	const ollamaCloudEntry = buildOllamaCloudEntry();
 	const manualEntry = buildOttoRouterEntry();
-	const merged: Record<ProviderId, ProviderCatalogEntry> = {
-		...(base as Record<ProviderId, ProviderCatalogEntry>),
+	const merged: Record<BuiltInProviderId, ProviderCatalogEntry> = {
+		...(base as Record<BuiltInProviderId, ProviderCatalogEntry>),
 	};
+	merged[OLLAMA_CLOUD_ID] = ollamaCloudEntry;
 	if (manualEntry) {
 		merged[OTTOROUTER_ID] = manualEntry;
 	}

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

@@ -1,9 +1,9 @@
 import type {
+	BuiltInProviderId,
 	ProviderCatalogEntry,
-	ProviderId,
 } from '../../types/src/index.ts';
 import { catalog as generatedCatalog } from './catalog.ts';
 import { mergeManualCatalog } from './catalog-manual.ts';
 
-export const catalog: Record<ProviderId, ProviderCatalogEntry> =
+export const catalog: Record<BuiltInProviderId, ProviderCatalogEntry> =
 	mergeManualCatalog(generatedCatalog);