feat: add project identification to request tracking

[zenprocess]

Summary

• Extracts project name from Claude API requests to tag each proxied request with its originating project
• Uses a 3-tier extraction strategy: x-project header > system prompt path pattern > system prompt heading
• Adds project column to requests table with migration guard and performance index
• Fully backward-compatible — project defaults to null for existing requests

Motivation

When ccflare proxies traffic from multiple Claude Code projects across multiple machines, there's no way to tell which project generated which request. This makes per-project analytics, cost tracking, and session correlation impossible.

Changes

File	Change
packages/types/src/api.ts	Add project to RequestMeta
packages/types/src/request.ts	Add project to RequestRow, Request, RequestResponse + mappers
packages/proxy/src/post-processor.worker.ts	Add extractProjectFromRequest(), wire through handleStart/handleEnd
packages/database/src/repositories/request.repository.ts	Add project to RequestData, saveMeta(), save()
packages/database/src/database-operations.ts	Thread project param through facade methods
packages/database/src/migrations.ts	ALTER TABLE ADD COLUMN project TEXT
packages/database/src/performance-indexes.ts	Add idx_requests_project_timestamp

Test plan

• Build passes: bun run build
• Start server, make a Claude API call from a project with CLAUDE.md
• Verify project column populated: sqlite3 ccflare.db "SELECT id, project FROM requests LIMIT 5"
• Verify x-project header override: curl -H "x-project: test" ...
• Verify null project for requests without system prompt

🤖 Generated with Claude Code

[zenprocess]

Context: Why project tracking matters

This PR was born from a real production need — we run ccflare as shared infrastructure proxying Claude API traffic across multiple accounts, machines, and projects. Without project tagging, analytics showed aggregate token usage but couldn't answer basic questions like:

• "Which project is burning the most cache tokens?"
• "Is the rate limiting happening because of project A dispatch or project B?"
• "What's the cost per project per day?"

The bigger picture: ccflare + Afterburn

Project tracking unlocks a powerful integration with Afterburn — a tool that mines Claude Code session history to find recurring friction patterns, successful approaches, and skill gaps.

The pipeline:

ccflare (proxies all Claude API traffic, tags by project)
    │
    └─→ Afterburn (hourly scheduled workflow)
            ├─ Fetches ccflare's request history grouped by project
            ├─ Reconstructs conversation sessions from request/response bodies
            ├─ Runs friction/patterns/gaps analysis passes
            └─ Publishes findings to a dashboard

What this enables that neither tool can do alone:

• Cross-machine pattern detection — the same correction happening on multiple machines = systemic issue, not a one-off
• Cost-of-friction quantification — ccflare has token counts per request, afterburn knows which requests were retries. Multiply = dollar cost of each recurring mistake
• Per-project skill evolution — afterburn's CCAR loop benchmarks skills against historical correction rates, now segmented by project

ccflare's project column is the join key that makes all of this work. Without it, the afterburn pipeline can only analyze sessions from one machine at a time (via local JSONL files). With it, ccflare becomes the single aggregation point for cross-machine Claude intelligence.

Happy to share more details if useful for the project roadmap.

[tombii]

Hi @zenprocess,
Might I shamelessly suggest my fork: https://github.com/tombii/better-ccflare
It supports API keys so that each project can get its own API key. Metrics are displayed per API key and the API key used is also visible per request.
Best regards,
Tom