Claude

Build me a personal chat client on the Anthropic API to replace my Claude Pro
subscription with per-token billing. Requirements:

- A local web app: Node + Express + better-sqlite3, streaming replies over SSE,
  a conversation sidebar, Markdown rendering with marked.
- Anthropic API key in .env; model picker with Sonnet as the default and Opus
  on demand; system prompt editable and saved per project.
- Projects: a project groups conversations and holds a few reference docs
  (plain text or PDF via pdf-parse) prepended as context for every chat inside
  it.
- Use prompt caching on the project docs to cut token costs, the API supports
  it directly.
- SQLite FTS5 search across all conversations; export any thread to Markdown.
- A cost meter per conversation plus a monthly total from the API usage fields,
  so the keep-paying-or-not decision is a number, not a feeling.
- Localhost only, no accounts, no telemetry.
- Out of scope: artifacts, mobile apps, and agent features. If the cost meter
  shows heavy use, flat-rate Pro or Max wins; include that comparison logic in
  the README.
- README: key setup, a link to current per-token prices, and state that the
  model is the product; this wrapper only changes how I pay for it.

# AGENTS.md — Build guide for Claude

## Project scope
Build a chat app using Anthropic API, with document upload, conversation storage, and optional project contexts.

Catalogue verdict: no. A Claude-like UI is trivial; the model, safety/reliability layer, long-context performance, artifacts/projects, and platform distribution are not.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- Anthropic API key
- hosted app
- file parsing
- storage
- optional vector search

## Stack and architecture
- A local web app: Node + Express + better-sqlite3, streaming replies over SSE, a conversation sidebar, Markdown rendering with marked.
- Model tasks, projects, schedules, dependencies, and completion events; store source IDs and timestamps for each.
- Interface for this AI assistant workflow: a local web page with input, progress, review, and export views.

## Security and data integrity
- If Anthropic API key is unavailable, keep the source record and show a recoverable error instead of a fabricated result.
- Keep API keys and OAuth secrets in .env; redact them from logs, generated files, and error responses.
- State the practical limit: frontier model.

## Agent implementation rules
- Project rule, data: Model tasks, projects, schedules, dependencies, and completion events; store source IDs and timestamps for each.
- Project rule, behavior: Projects: a project groups conversations and holds a few reference docs (plain text or PDF via pdf-parse) prepended as context for every chat inside it.
- Project rule, recovery: If Anthropic API key is unavailable, keep the source record and show a recoverable error instead of a fabricated result.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this AI assistant operation with sample or user-owned data: Projects: a project groups conversations and holds a few reference docs (plain text or PDF via pdf-parse) prepended as context for every chat inside it.
- Show a concrete result or export: SQLite FTS5 search across all conversations; export any thread to Markdown.
- State the practical limit: frontier model.

## Engineering roadmap
1. Phase 1, architecture and data: A local web app: Node + Express + better-sqlite3, streaming replies over SSE, a conversation sidebar, Markdown rendering with marked. Model tasks, projects, schedules, dependencies, and completion events; store source IDs and timestamps for each.
2. Phase 2, implement: Projects: a project groups conversations and holds a few reference docs (plain text or PDF via pdf-parse) prepended as context for every chat inside it.
3. Phase 3, implement: Build a chat app using Anthropic API, with document upload, conversation storage, and optional project contexts.
4. Phase 4, review and output: AI assistant for writing, reasoning, coding, and document work. SQLite FTS5 search across all conversations; export any thread to Markdown.
5. Phase 5, recovery and acceptance: If Anthropic API key is unavailable, keep the source record and show a recoverable error instead of a fabricated result. Verify this invariant with a saved fixture: An invalid input or interrupted operation must retain the source and show a recoverable state; exported records must reload with the same IDs. State the practical limit: frontier model.

## Paid-product capabilities outside this build
- frontier model
- long-context quality
- product surface
- mobile apps
- reliability
- continuous model upgrades

## Implementation prompt
Build me a personal chat client on the Anthropic API to replace my Claude Pro
subscription with per-token billing. Requirements:

- A local web app: Node + Express + better-sqlite3, streaming replies over SSE,
  a conversation sidebar, Markdown rendering with marked.
- Anthropic API key in .env; model picker with Sonnet as the default and Opus
  on demand; system prompt editable and saved per project.
- Projects: a project groups conversations and holds a few reference docs
  (plain text or PDF via pdf-parse) prepended as context for every chat inside
  it.
- Use prompt caching on the project docs to cut token costs, the API supports
  it directly.
- SQLite FTS5 search across all conversations; export any thread to Markdown.
- A cost meter per conversation plus a monthly total from the API usage fields,
  so the keep-paying-or-not decision is a number, not a feeling.
- Localhost only, no accounts, no telemetry.
- Out of scope: artifacts, mobile apps, and agent features. If the cost meter
  shows heavy use, flat-rate Pro or Max wins; include that comparison logic in
  the README.
- README: key setup, a link to current per-token prices, and state that the
  model is the product; this wrapper only changes how I pay for it.

## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.