Personal AI assistant

Problem

The prototype explores what happens around a model response: choosing bounded context, preserving execution state and deciding how interruptions should affect a conversation.

Its focus is a local, single-owner assistant rather than a deployed service with verified production access and billing.

Implemented approach

A submitted turn is checked against an enabled model profile, assembled context and budget admission before a fresh execution starts. Reusing a request identifier with the same content and profile replays the existing execution; changing either produces a conflict instead of silently starting another generation.

The documented execution contract persists output snapshots before delivery and keeps terminal outcomes for subsequent reads. The streaming path requests incremental model output and checks the response format, completion marker and output bounds before reporting completion.

Context selection retains recent turns and can create a deterministic extractive summary of older material, explicitly marked as lossy conversation data rather than policy. The assembled prompt must fit the configured character bound; an oversized latest turn is rejected rather than silently shortened.

Architecture in words

This is a simplified conceptual overview, not a guarantee of exact internal call ordering.

User turn → bounded context → budget admission → persistent execution → streamed output → stored outcome and replay.

Trade-offs

Bounded context and lost detail

Summarizing older turns leaves room for recent context, but extracted fragments can omit details that remain in the stored raw conversation. This keeps context construction bounded without claiming that the summary preserves every fact or matches a model-generated summary.

Conservative interruption handling

Conservative interruption handling avoids automatically rerunning a generation after restart, at the cost of leaving some interrupted work or usage reservations unresolved. That is not an exactly-once provider guarantee, and requesting Stop doesn't guarantee that remote billing stops.

Limits and current status

The assistant is not production-ready: production identity and access configuration, approved models and prices, remote acceptance and live billing remain unverified.

Retrieval providers, tools and uploads are not enabled in the documented chat contract.

Development tests are documented, including a test-only provider, but their existence isn't a claim that they passed in this review or validate a live model service.

Configured limits and cost controls describe intended execution boundaries, not observed savings, latency or a verified cloud deployment.