Kompl v0.2.0 — multi-provider + visibility + hardening

[tuirk]

Kompl v0.2.0 is out. Three themes:

Multi-provider LLM. DeepSeek V4 Pro is now a second selectable compile/chat backend alongside Gemini 2.5. Per-session model lock means Settings changes don't hot-swap an in-flight compile. DeepSeek handles long/dense sources (academic PDFs, surveys) more reliably — Gemini's structured-output truncation pathology is documented in issue #7 with DeepSeek as the documented workaround.

Compile-pipeline visibility & recovery. Live per-step X/Y progress on the compile UI for extract, draft, match, crossref, commit, and all three ingest steps. Stranded-source recovery — when an extract fails partway through a session, retry now actually re-attempts the source instead of silently no-op'ing. The time-estimate footer shows a range rather than a single pessimistic value. YouTube ingest fully rewritten on top of youtube-transcript-api + YouTube Data API v3 — no more silent chrome-HTML fallback when a video lacks a transcript; those URLs route to Saved Links.

Security pass. SSRF + path-traversal + log-forging hardening; Scorecard-flagged dependencies pinned; the main branch ruleset closes the required-status-checks sub-gap. MCP server picks up GHSA fixes for hono and ip-address.

Also: paste-text connector for raw notes; parallel extract step (concurrency 4); 36h startup hook subsumes the always-on lint cron; deployment-mode toggle removed in favour of single-mode personal-computer.

Migration. migrate.py walks schema v20 → v23 idempotently on boot. New optional YOUTUBE_API_KEY env var; without it, YouTube URLs route to Saved Links.

Full release notes: https://github.com/tuirk/Kompl/releases/tag/v0.2.0
CHANGELOG: https://github.com/tuirk/Kompl/blob/main/CHANGELOG.md

[richardchen874-sys]

This is a strong v0.2.0 update. The per-session model lock is especially important for compile pipelines, because changing models mid-run can make debugging output quality almost impossible.

I also like the DeepSeek V4 Pro addition as a workaround for Gemini structured-output truncation. For long academic PDFs and surveys, the useful metric is not just “which model is smarter”, but which backend can reliably finish the whole pipeline without truncating, silently dropping sections, or forcing expensive retries.

For multi-step workflows like extract → draft → match → crossref → commit, I’d probably track provider behavior per stage:

• truncation rate
• retry rate
• cost per successfully compiled source
• latency per pipeline step
• structured-output validity
• failure recovery after partial extract
• whether one model is better for dense extraction while another is better for drafting

That would make multi-provider selection much more practical than choosing one global default model.

Nice work on adding pipeline visibility and stranded-source recovery. Those are exactly the kind of details that make long-running LLM workflows feel production-ready instead of fragile.

[tuirk]

@richardchen874-sys thanks, this is a really good idea.

Your per-stage metrics list (truncation, retries, cost per successful compile, latency, structured-output validity, stage-specific strengths) topped with a dashboard would help users make a data-informed decision. It would also complement the day-spend limit setting, 5$ is default based on my heavy test usage with Gemini bug and with Deepsek v4 Pro discounted price becoming permanent it's not even needed for most cases.

I'll open an enhancement issue for this and will see how I can prioritize it in an upcoming sprint. Will link back here, thanks again

Tracked in #144.

[richardchen874-sys]

Thanks, glad it was useful.

A dashboard would be a great fit here because the decision is not always “Gemini vs DeepSeek globally,” but which backend behaves better at each stage of the compile pipeline.

For example, one model might be better at dense extraction, another at drafting, and another may simply be cheaper because it avoids truncation-driven retries.

If you add this later, I think the most useful view would be something like:

• provider + model per stage
• successful vs failed stage runs
• retry count
• truncation / invalid structured-output rate
• latency per stage
• estimated cost per stage
• cost per successfully compiled source
• stage where fallback was triggered

That would make the day-spend limit much more actionable, because users could see whether the cost is coming from extraction, retries, truncation, or long drafting runs.

Really nice to see this tracked in #144. Kompl is moving in a strong direction for long-running academic / research LLM workflows.