What causes "HTTP ${response.status} from ${tagsUrl}" in can1357/oh-my-pi?

Verify the Ollama server is running and `curl http:// :11434/api/tags` returns 200 with a models JSON list.

HTTP ${response.status} from ${tagsUrl}

Error message

HTTP ${response.status} from ${tagsUrl}

What it means

discoverOllamaModels probes a local/remote Ollama server's `GET /api/tags` endpoint to enumerate installed models. When the HTTP response is not ok (any non-2xx status), it throws `Error("HTTP <status> from <tagsUrl>")` because the model list cannot be read. The library treats any non-ok status as fatal for discovery rather than parsing an error body.

Source

Thrown at packages/coding-agent/src/config/model-discovery.ts:485

		return null;
	}
}

export async function discoverOllamaModels(
	providerConfig: DiscoveryProviderConfig,
	ctx: DiscoveryContext,
): Promise<Model<Api>[]> {
	const endpoint = normalizeOllamaBaseUrl(providerConfig.baseUrl);
	const tagsUrl = `${endpoint}/api/tags`;
	const headers = { ...(providerConfig.headers ?? {}) };
	const customTimeoutMs = providerConfig.discovery.timeoutMs;
	const payload = await withTimeoutSignal(discoveryProbeTimeoutMs(endpoint, 250, customTimeoutMs), async signal => {
		const response = await ctx.fetch(tagsUrl, {
			headers,
			signal,
		});
		if (!response.ok) {
			throw new Error(`HTTP ${response.status} from ${tagsUrl}`);
		}
		return (await response.json()) as { models?: Array<{ name?: string; model?: string }> };
	});
	const entries = (payload.models ?? []).flatMap(item => {
		const id = item.model || item.name;
		return id ? [{ id, name: item.name || id }] : [];
	});
	const metadataById = new Map(
		await Promise.all(
			entries.map(
				async entry =>
					[
						entry.id,
						await discoverOllamaModelMetadata(ctx, endpoint, entry.id, headers, customTimeoutMs),
					] as const,
			),
		),
	);

View on GitHub (pinned to 9690622007)

Solutions

Verify the Ollama server is running and `curl http://<host>:11434/api/tags` returns 200 with a models JSON list.
Correct the provider baseUrl in the models config so it points at the Ollama root (e.g. http://localhost:11434), not another OpenAI-compatible server.
If behind a proxy, ensure /api/* is forwarded to Ollama and no auth middleware blocks the request; add needed headers to the provider config.
Raise or adjust discovery.timeoutMs only after confirming the status is not caused by a slow cold-start; then retry discovery.

Example fix

// before: baseUrl points at an OpenAI-compatible server without /api/tags
{ "provider": "ollama", "baseUrl": "http://localhost:8080/v1", "discovery": { "type": "ollama" } }
// after: point at the Ollama root
{ "provider": "ollama", "baseUrl": "http://localhost:11434", "discovery": { "type": "ollama" } }

Defensive patterns

Strategy: try-catch

Validate before calling

const res = await fetch(`${baseUrl.replace(/\/$/, '')}/api/tags`);
if (!res.ok) throw new Error(`Ollama unreachable: HTTP ${res.status} from ${baseUrl}/api/tags`);

Type guard

function isOllamaTagsPayload(v: unknown): v is { models?: Array<{ name?: string; model?: string }> } {
  return typeof v === "object" && v !== null && ("models" in v ? Array.isArray((v as any).models) : true);
}

Try / catch

try {
  const models = await discoverOllamaModels(cfg, ctx);
} catch (err) {
  if (err instanceof Error && /^HTTP \d+ from /.test(err.message)) {
    const status = Number(err.message.match(/HTTP (\d+)/)?.[1]);
    logger.warn("Ollama discovery failed", { status, baseUrl: cfg.baseUrl });
    return staticFallbackModels;
  }
  throw err;
}

Prevention

Health-check /api/tags with curl before wiring discovery into config.
Point the provider baseUrl at the Ollama root (default http://localhost:11434), not another server.
Audit any reverse proxy so /api/* reaches Ollama without auth interference.
Catch and log discovery errors with the status so failures degrade to a static model list.

When it happens

Trigger: Calling discoverOllamaModels (via discoverModelsByProviderType with discovery.type pointing at an Ollama baseUrl) when the Ollama server answers /api/tags with 404 (wrong path/older Ollama behind a proxy stripping /api), 403 (auth/proxy blocked), 500 (Ollama internal error), or 502/503 (reverse proxy up but Ollama down).

Common situations: Ollama not actually running on the configured port; a reverse proxy (nginx/caddy) forwarding to the wrong upstream; OLLAMA_ORIGINS/CORS proxies returning 403; corporate proxy intercepting localhost traffic; pointing baseUrl at something that is not Ollama (e.g. an LM Studio or vLLM endpoint that lacks /api/tags).

Related errors

AI-assisted analysis of can1357/oh-my-pi@9690622007 (2026-08-31). Data as JSON: /api/errors/3baf32ef2546faa1. Report an issue: GitHub.