Personal site data sources

Summary

Noa already has strong raw material for a personal “devtools portfolio”: a live GitHub profile README (AsterisMono/AsterisMono), a digital garden/blog at herbarium.requiem.garden, recent repos/PRs on GitHub, and a cloud agent orchestrator (herdr-wrapper / DIY Cursor Projects–style fleet on always-on machines) for overnight agent status — not laptop-local Herdr alone. Token usage is the hard section: Cursor’s documented usage APIs are Team/Enterprise Admin (and Org) APIs, not a public individual “token dashboard API”; self-serve users realistically use dashboard CSV export and/or optional unofficial local scrapers. Cloud Agents have a real public beta API (GET /v1/agents, run status, per-agent usage). Recommended shape: static/ISR site for README + posts + public GitHub activity, plus a small private “pulse” backend (or local-first dashboard) for Herdr status and any token series you choose to publish in anonymized form.

1. README

Design / UX patterns

Profile README as About: treat USERNAME/USERNAME README as the source of truth; personal site /about or hero fetches and renders it (common Next.js + next-mdx-remote pattern).
Live /readme page: dedicated route that always shows the current GitHub profile README (example open-source: sametcn99/personal-website).
Pinned “featured” cards under the README body (Noa’s README already lists flake, mimosa, aster, reverie, herbarium).
Keep GitHub-flavored markdown (tables, task lists, relative links) via remark-gfm; strip or sandbox raw HTML if rendering untrusted MD.

Data sources

Source	How	Notes
Profile README	`https://raw.githubusercontent.com/AsterisMono/AsterisMono/main/README.md` or GitHub Contents API	Public, no auth
Profile metadata	`GET /users/AsterisMono`	bio, blog URL, avatar, public_repos
Pinned repos	GraphQL `user.pinnedItems` (needs token) or hardcode from README links	REST has no clean “pinned” list without scraping

Noa today: Profile README exists and is strong (“Immutable foundations…”). Blog field points to herbarium.requiem.garden. Public identity: GitHub AsterisMono, name Noa Virellia.

Auth / rate limits / privacy

Unauthenticated REST: ~60 req/h; authenticated PAT/App: 5,000 req/h.
Raw GitHub CDN is fine for build-time or ISR (revalidate every few minutes–hours).
Privacy: README is public by definition; don’t pull private bio fields.

2. Posts

Design / UX patterns

MD/MDX blog in-repo (content/posts/*.mdx + frontmatter: title, date, tags, summary).
Digital garden: evergreen notes + graph/backlinks (Quartz, Obsidian Digital Garden plugin, Onvu-style garden + portfolio).
Hybrid: garden for thinking-out-loud; dated posts for announcements; Digests/ as research feed (this note’s home).
List UI: chronological index + tag chips; RSS/Atom; optional /llms.txt for agent-readable summaries (minifolio pattern).

Data sources

Source	Fit for Noa	Caveats
Obsidian vault → publish	High — Digests already under vault; herbarium is the public garden	Need an explicit publish pipeline (Quartz / Digital Garden plugin / custom MDX sync). Don’t publish private Digests by default.
In-repo MDX	Best for a new personal-site monorepo	Manual dual-write vs herbarium unless synced
GitHub Issues/Discussions as posts	Possible CMS	Ugly UX; better as “changelog” than essays
SSG: Astro / Next / Hugo / Quartz	All viable	Match stack to who maintains the site

Noa today: herbarium.requiem.garden already positions as knowledge base / blog / digital garden. Vault path for Digests: Digests/ in Noa’s local vault. Repo AsterisMono/obsidian-agent suggests agent tooling around Obsidian (recent PRs Sep 2026).

Auth / rate limits / privacy

Prefer opt-in frontmatter (publish: true) or a public/ folder so Digests and private notes never ship.
If syncing Obsidian → Git, review for secrets, medical notes, unreleased work.

3. Token usage activity

Design / UX patterns

Sparkline / stacked bar: tokens or “activity units” by day; optional model mix pie.
Public vs private: most people keep $ amounts private; publish anonymized daily totals or a qualitative “busy / quiet” heatmap.
Separate IDE/agent usage (Cursor) from API usage (OpenAI) — different products, different units.

Realistic data sources (documented)

Cursor — Team / Enterprise (documented)

Official Admin API (Basic auth with Admin API key as username):

POST https://api.cursor.com/teams/daily-usage-data — per-user/day IDE metrics (tabs, chat/composer/agent requests, lines, mostUsedModel). Rate limit ~20 rpm/team; date range ≤30 days/call. Poll ≤1/hour recommended.
POST https://api.cursor.com/teams/filtered-usage-events — event-level tokens (inputTokens, outputTokens, cache tokens), chargedCents, conversationId, optional cloudAgentId. ~60 rpm/team.
POST https://api.cursor.com/teams/spend — billing-cycle spend.
Org counterparts under /organizations/... for multi-team orgs.

Plain fact: These are team/org admin surfaces, not a documented public API for every individual Pro user.

Cursor — Individual / self-serve

Dashboard Usage page + CSV export (documented in product/help discussions): usable for personal charts; included usage may show as “Included” rather than $.
As of mid-2026 forum reports, self-serve Usage UI/CSV leaned token-oriented; dollar fields on some dashboard endpoints were zeroed for self-serve — treat $ as unreliable unless Admin/Enterprise reconciliation applies.
No official individual “Usage API / CLI” as a supported product feature (feature requests exist; Admin API is the supported automation path for teams).
Unofficial tools (e.g. scraping dashboard session cookies or reading local Cursor DBs) exist in the wild — unsupported, brittle, privacy-sensitive; do not build the personal-site project on them unless Noa explicitly accepts that risk.

Cursor Cloud Agents (usable for agent token slices)

GET https://api.cursor.com/v1/agents/{id}/usage — per-run input/output/cache/total tokens (public beta Cloud Agents API; user or service API key). Good for “what my cloud agents burned,” not full IDE Tab usage.

OpenAI

Completions usage: GET https://api.openai.com/v1/organization/usage/completions (Admin key).
Costs: GET https://api.openai.com/v1/organization/costs.
Needs org admin key; bucketed by day (and group_by model/project/etc.).

GitHub Copilot

Org/enterprise Copilot usage metrics REST (policy must enable metrics). 2026 AI Credits (ai_credits_used) are coarse per-user/day — not model/repo breakdown. Irrelevant unless Noa uses Copilot at org scope.

Auth / rate limits / privacy

Never put Admin/API keys in the static site; ingest server-side or offline into a public JSON with aggregated numbers only.
Anonymize: drop emails, conversation IDs, repo names, prompt text; publish daily sums or percentiles.
Rate limits and 30-day Admin windows imply a warehouse/cron, not live browser calls.

4. Agent running status

Design / UX patterns

Status board: columns or dots for working / blocked / idle / done (Herdr’s model).
Public site usually shows a sanitized pulse (“2 agents working”) not live terminal output (secrets risk).
Private “mission control” can embed richer boards (herdr-portal web big-screen).

Data sources

Primary: cloud orchestrator (herdr-wrapper / DIY Cursor Projects) — use this for the site

Per project direction (Todey / Noa): agent running status on the personal site should reflect overnight fleet work from Noa’s cloud agent orchestrator, not agents that only live on the laptop while it is open.

Treat the stack as layers:

Orchestrator (product intent ≈ Cursor Projects) — coordinator plans/delegates long-running work, keeps shared context, can run without the laptop. Cursor’s own Projects is the commercial version (cursor.com/blog/projects); Noa’s herdr-wrapper is the DIY / self-hosted analogue to watch.
Runtime (Herdr) — Herdr is the multi-agent terminal workspace under many DIY fleets. CLI + local socket JSON API on the machine where the fleet runs (ideally always-on / cloud VM, not the laptop):
- herdr agent list / herdr agent get <target> — states idle | working | blocked | done | unknown
- herdr status / herdr api schema — health + protocol
- Integrations: Cursor Agent CLI (herdr integration install cursor), Claude, Codex, etc.
Sibling DIY orchestrators worth studying for patterns (not necessarily adopt): orchestratr (Herdr-based), herdr-factory (PR factory on Herdr worktrees), herdr-outpost (remote dashboard + Cloudflare Tunnel relay).

Site implication: the pulse worker must talk to wherever herdr-wrapper / the fleet Herdr socket lives (cloud host), so status stays true overnight after asymmetry sleeps. Laptop-local ~/.herdr on asymmetry is secondary / optional for “am I coding right now,” not the public overnight board.

Noa today: home layout historically includes .herdr / .herdr-projects on asymmetry, but local inspection was blocked this run (desktop app offline). Confirm herdr-wrapper deploy host, socket path, and redaction policy when online.

Feeding a personal site: daemon or cron on the fleet host reads orchestrator/Herdr status → writes redacted status.json (counts by state, maybe agent nicknames) to object storage or a private API. Optional: herdr-outpost-style relay for a private mission-control UI. Do not expose raw Herdr sockets or transcripts publicly.

Cursor Cloud Agents / Projects API (complement, if used)

Official Projects: cloud coordinator + subscriptions (Slack/schedules/PRs); Agents Window.
Cloud Agents API (public beta): GET https://api.cursor.com/v1/agents (ACTIVE | IDLE | ARCHIVED); run status endpoints; UI cursor.com/agents.
Use if Noa also runs Cursor-hosted cloud agents; still keep DIY fleet as the primary overnight signal per project brief.

Other

vibecode-dash / Atlas / herdr-portal — private mission control patterns; publish only through a redaction gate.

Auth / rate limits / privacy

Herdr socket is local-trust; treat agent transcripts as secret.
Cloud Agents API keys are account-scoped; rotate; never ship to browser.
Public status should omit prompts, paths, and pane contents.

5. Recent works

Design / UX patterns

Cards: repo name, one-line description, language, last push, stars.
Activity feed: merged PRs + releases + “shipped this week.”
Contribution heatmap (GitHub calendar) as ambient signal.
Changelog / RSS from releases (atom feed per repo).

Data sources

Source	Endpoint / method	Notes
Recent repos	`GET /users/AsterisMono/repos?sort=pushed`	Public
Search	`GET /search/repositories?q=user:AsterisMono`	Sorted by updated
PRs authored	`GET /search/issues?q=author:AsterisMono+is:pr`	Cross-repo (incl. nixpkgs)
Events	`GET /users/AsterisMono/events/public`	Push, PR, etc.; short retention
Releases	`GET /repos/{owner}/{repo}/releases`	Per featured repo
Commits	`GET /repos/{o}/{r}/commits?author=AsterisMono`	Noise; prefer PRs for “works”

Snapshot (research time, UTC→interpret as recent activity):

Repos updated: flake, obsidian-agent, xpipe-vault, recital, nori-template, waybar-toys, reverie, …
Recent PRs: obsidian-agent #5/#1; flake #24/#23; NixOS/nixpkgs #556040 (letos), etc.

GraphQL can fetch pinned repos + contribution calendar in one query with a PAT.

Auth / rate limits / privacy

Prefer public endpoints for the public site.
Filter out private fork noise and abandoned toys via allowlist (featured list from README).
Don’t show private org PRs unless intentionally.

Combined open-source patterns (activity dashboards)

Worth studying for UX, not necessarily forking wholesale:

vibecode-dash — local-first: Claude/Codex sessions + GitHub + Obsidian → SQLite on localhost.
Atlas (thebenignhacker/atlas) — portfolio map + activity feed; optional unified public/private snapshots.
minifolio — live GitHub APIs + /events stream + /llms.txt.
Onvu — portfolio + digital garden (Next).
sametcn99/personal-website — MDX blog + live GitHub README route.
herdr-portal — agent kanban over Herdr (private mission control).

Recommended architecture sketch

                    ┌─────────────────────────────┐
  GitHub public ───►│  Build / ISR (Vercel etc.)  │──► Public site
  Profile README    │  - / (README + featured)    │     herbarium link-out
  Issues/PRs/repos  │  - /posts (MDX or garden)   │     or embed garden
  herbarium / MDX   │  - /works (PR+repo cards)   │
                    └─────────────▲───────────────┘
                                  │ optional public JSON
                    ┌─────────────┴───────────────┐
  Fleet host (cloud)│  Private pulse worker       │
  herdr-wrapper /   │  - overnight agent fleet    │
  Herdr socket      │  - redact → status.json     │
  (+ Cloud Agents)  │  - optional token aggregates│
  CSV / Admin API   │  - never expose sockets/keys│
                    └─────────────────────────────┘

Phased delivery for personal-site:

Public static: README sync + works feed + link to herbarium (or import selected posts).
Private pulse: Herdr status + Cloud Agents list for Noa-only view (auth gate).
Token panel: start with manual/CSV → SQLite; upgrade to Admin API only if on Team/Enterprise; publish only anonymized series if desired.

Open questions

Agent status source of truth: herdr-wrapper / DIY fleet host (overnight) confirmed; exact host URL/socket and public redaction fields still TBD. / decisions for Noa & Todey

Is personal-site a new surface, or an upgrade path for herbarium? Dual sites vs one garden+dashboard.
Which posts are in-scope? Digests only, herbarium notes with publish: true, or greenfield MDX?
Cursor plan tier? Individual CSV-only vs Team Admin API availability changes the token section completely.
How public should agent status be? Dot counts vs named agents vs private-only.
Herdr on asymmetry: confirm .herdr / .herdr-projects contents and whether a bridge daemon is acceptable always-on.
Anonymization bar for tokens: publish nothing / daily totals / model mix without $ / full private dashboard only.
Featured works allowlist: stick to README featured list or auto-include all pushed repos?

Blockers from this research pass

Machine asymmetry was disconnected; could not ls .herdr*, run herdr, or verify Digests folder on-disk before write. Digest write attempted via machine Shell when reconnecting; if still offline, content was staged on the research box.

Key links

GitHub profile: https://github.com/AsterisMono
Profile README raw: https://raw.githubusercontent.com/AsterisMono/AsterisMono/main/README.md
Herbarium: https://herbarium.requiem.garden/
Cursor Admin API: https://cursor.com/docs/account/teams/admin-api
Cursor Cloud Agents API: https://cursor.com/docs/cloud-agent/api/endpoints
Cursor Cloud Agents product: https://cursor.com/docs/cloud-agent
OpenAI usage cookbook: https://developers.openai.com/cookbook/examples/completions_usage_api
GitHub Copilot usage metrics: https://docs.github.com/rest/copilot/copilot-usage-metrics
Herdr CLI: https://herdr.dev/docs/cli-reference/
Herdr agents: https://herdr.dev/docs/agents/
Herdr configuration: https://herdr.dev/docs/configuration/
herdr-portal: https://github.com/loofare/herdr-portal
Profile README sync pattern: https://mikebifulco.com/posts/next-js-github-bio-about-page
vibecode-dash: https://www.npmjs.com/package/vibecode-dash
Atlas: https://github.com/thebenignhacker/atlas
minifolio: https://github.com/sheraff/minifolio
Onvu: https://github.com/y9vad9/onvu
Quartz + Obsidian garden: https://notes.hamatti.org/technology/building-a-digital-garden-with-obsidian-and-quartz