token Management #7

New Issue

2026-07-05T20:58:06+02:00

froxxxy commented

2026-07-05 20:58:06 +02:00

hast du Zugriff auf die cursor api über secret CURSOR_API_KEY?
unabhängig davon, finde heraus ob du mein token quota (pro abo hab ich vermutlich) über die api auslesen kannst

@cursor 1. hast du Zugriff auf die cursor api über secret CURSOR_API_KEY? 2. unabhängig davon, finde heraus ob du mein token quota (pro abo hab ich vermutlich) über die api auslesen kannst

cursor commented

2026-07-05 20:59:21 +02:00

Ergebnis: Cursor API & Token-Quota

1. Zugriff auf `CURSOR_API_KEY`?

Ja — im Gitea-Actions-Workflow (.gitea/workflows/cursor.yml) wird das Repo-Secret CURSOR_API_KEY an den cursor-gitea-agent übergeben und steht mir in dieser Session als Umgebungsvariable zur Verfügung.

Empirischer Test (ohne Key-Wert zu loggen):

Endpoint	Ergebnis
`GET https://api.cursor.com/v1/me`	200 — Key gültig (Cloud Agents API)
`GET https://api.cursor.com/v1/models`	200
`GET https://api.cursor.com/v1/agents`	200
`GET https://api.cursor.com/teams/members`	401 — „Invalid Team API Key“
`POST https://api.cursor.com/teams/filtered-usage-events`	401 — „Invalid Team API Key“

Der Key ist ein User/Cloud-Agents-API-Key (apiKeyName: cursor-gitea-agent), kein Enterprise-Admin-API-Key (crsr_… mit Scope admin:*).

2. Token-Quota (Abo) über die API auslesen?

Kurz: Account-weites Abo-Quota — mit diesem Key nein. Es gibt dafür keine öffentliche User-API.

Was Cursor offiziell anbietet

API	Quota/Usage?	Voraussetzung
Cloud Agents API (`api.cursor.com/v1/*`)	Nur pro Agent/Run Token-Verbrauch (`GET /v1/agents/{id}/usage`), kein Kontingent-Stand	User API Key (wie hier)
Admin API	Usage-Events, Spend, Daily Usage, Spend-Limits	Enterprise + Admin API Key
Analytics API	Team-Metriken, Modell-Nutzung	Enterprise + Analytics API Key

Dokumentation: cursor.com/docs/api

Für Pro/Team/Ultra gibt es laut Cursor-Docs keinen dokumentierten Quota-Endpoint. Enterprise-Teams können z. B. POST /teams/filtered-usage-events nutzen (historische Events mit chargedCents, Tokens pro Request) — das ist Verbrauch, nicht unbedingt „X von Y übrig“.

Was der vorhandene Key kann

Agenten starten/verwalten (/v1/agents)
Token-Usage pro Cloud-Agent-Run abfragen (/v1/agents/{id}/usage)
Nicht: verbleibendes Monatskontingent, Fast-Request-Pool, Dollar-Allowance o. Ä.

Getestet: /v1/usage, /v1/quota, /v1/billing, /v1/account → alle 404 (existieren nicht).

Inoffizielle Alternativen (nicht für Bot/CI empfohlen)

Community-Tools (z. B. VS-Code-Extension „Cursor Usage Status“) nutzen undokumentierte Dashboard-Endpoints auf api2.cursor.sh (GetCurrentPeriodUsage, /auth/usage) mit Session-Cookie, nicht mit dem Gitea-API-Key. Brittle, ohne SLA, für Automatisierung ungeeignet.

Fazit & Optionen

Ziel	Machbar mit `CURSOR_API_KEY`?
Gitea-Issues → Cursor-Agent	✅ Ja (läuft bereits)
Token-Verbrauch einzelner Cloud-Agent-Runs	✅ Ja (`/v1/agents/{id}/usage`)
Abo-Quota „noch X % übrig“	❌ Nein (mit diesem Key-Typ)
Team-weites Usage/Billing-Dashboard	Nur mit Enterprise Admin API Key

Wenn du Quota-Monitoring willst:

Enterprise + Admin API Key in Gitea als separates Secret (z. B. CURSOR_ADMIN_API_KEY) — dann Usage-Events/Spend auslesen.
Manuell: Cursor Dashboard → Usage/Billing.
Pro/Team: auf offizielle API warten oder inoffizielle Cookie-basierte Tools nur lokal am Rechner (nicht im CI).

Sag Bescheid, wenn ich z. B. ein kleines Script für Agent-Run-Usage oder Enterprise-Admin-Polling skizzieren soll.

## Ergebnis: Cursor API & Token-Quota ### 1. Zugriff auf `CURSOR_API_KEY`? **Ja** — im Gitea-Actions-Workflow (`.gitea/workflows/cursor.yml`) wird das Repo-Secret `CURSOR_API_KEY` an den `cursor-gitea-agent` übergeben und steht mir in dieser Session als Umgebungsvariable zur Verfügung. **Empirischer Test** (ohne Key-Wert zu loggen): | Endpoint | Ergebnis | |----------|----------| | `GET https://api.cursor.com/v1/me` | **200** — Key gültig (Cloud Agents API) | | `GET https://api.cursor.com/v1/models` | **200** | | `GET https://api.cursor.com/v1/agents` | **200** | | `GET https://api.cursor.com/teams/members` | **401** — *„Invalid Team API Key“* | | `POST https://api.cursor.com/teams/filtered-usage-events` | **401** — *„Invalid Team API Key“* | Der Key ist ein **User/Cloud-Agents-API-Key** (`apiKeyName`: `cursor-gitea-agent`), **kein** Enterprise-**Admin-API-Key** (`crsr_…` mit Scope `admin:*`). --- ### 2. Token-Quota (Abo) über die API auslesen? **Kurz: Account-weites Abo-Quota — mit diesem Key nein.** Es gibt dafür keine öffentliche User-API. #### Was Cursor offiziell anbietet | API | Quota/Usage? | Voraussetzung | |-----|--------------|---------------| | **Cloud Agents API** (`api.cursor.com/v1/*`) | Nur **pro Agent/Run** Token-Verbrauch (`GET /v1/agents/{id}/usage`), **kein** Kontingent-Stand | User API Key (wie hier) | | **Admin API** | Usage-Events, Spend, Daily Usage, Spend-Limits | **Enterprise** + Admin API Key | | **Analytics API** | Team-Metriken, Modell-Nutzung | **Enterprise** + Analytics API Key | Dokumentation: [cursor.com/docs/api](https://cursor.com/docs/api) Für **Pro/Team/Ultra** gibt es laut Cursor-Docs **keinen dokumentierten Quota-Endpoint**. Enterprise-Teams können z. B. `POST /teams/filtered-usage-events` nutzen (historische Events mit `chargedCents`, Tokens pro Request) — das ist **Verbrauch**, nicht unbedingt „X von Y übrig“. #### Was der vorhandene Key kann - Agenten starten/verwalten (`/v1/agents`) - **Token-Usage pro Cloud-Agent-Run** abfragen (`/v1/agents/{id}/usage`) - **Nicht:** verbleibendes Monatskontingent, Fast-Request-Pool, Dollar-Allowance o. Ä. Getestet: `/v1/usage`, `/v1/quota`, `/v1/billing`, `/v1/account` → alle **404** (existieren nicht). #### Inoffizielle Alternativen (nicht für Bot/CI empfohlen) Community-Tools (z. B. VS-Code-Extension „Cursor Usage Status“) nutzen **undokumentierte Dashboard-Endpoints** auf `api2.cursor.sh` (`GetCurrentPeriodUsage`, `/auth/usage`) mit **Session-Cookie**, nicht mit dem Gitea-API-Key. Brittle, ohne SLA, für Automatisierung ungeeignet. --- ### Fazit & Optionen | Ziel | Machbar mit `CURSOR_API_KEY`? | |------|-------------------------------| | Gitea-Issues → Cursor-Agent | ✅ Ja (läuft bereits) | | Token-Verbrauch einzelner Cloud-Agent-Runs | ✅ Ja (`/v1/agents/{id}/usage`) | | **Abo-Quota „noch X % übrig“** | ❌ Nein (mit diesem Key-Typ) | | Team-weites Usage/Billing-Dashboard | Nur mit **Enterprise Admin API Key** | **Wenn du Quota-Monitoring willst:** 1. **Enterprise + Admin API Key** in Gitea als separates Secret (z. B. `CURSOR_ADMIN_API_KEY`) — dann Usage-Events/Spend auslesen. 2. **Manuell:** Cursor Dashboard → Usage/Billing. 3. **Pro/Team:** auf offizielle API warten oder inoffizielle Cookie-basierte Tools nur lokal am Rechner (nicht im CI). Sag Bescheid, wenn ich z. B. ein kleines Script für Agent-Run-Usage oder Enterprise-Admin-Polling skizzieren soll.

froxxxy commented

2026-07-05 21:10:28 +02:00

@cursor andere frage: wird agents.md jedesmal gelesen? geht mir darum, dem run infos mitzugeben, z.b. "timeout ist 5 minuten, versuche vorher fertig zu werden"

cursor commented

2026-07-05 21:11:23 +02:00

AGENTS.md — wird es jedes Mal gelesen?

Kurz: nicht automatisch vollständig. Es kommt auf den Kanal an.

Was tatsächlich passiert

Kanal	AGENTS.md im Kontext?	Rest (SOUL, BOUNDARIES, …)?
Cursor IDE (lokal)	Nur wenn als Workspace Rule / `.cursor/rules` eingebunden — sonst muss der Agent die Datei selbst lesen	Laut `AGENTS.md` Tier 1/2: Agent soll bei substanziellen Tasks `SOUL.md` + `BOUNDARIES.md` (Tier 1) bzw. den Rest (Tier 2) lesen — kein Garantie-Auto-Load
`@cursor` Gitea-Bot (dieser Run)	In dieser Session: ja, als Workspace Rule injiziert (`always_applied_workspace_rules`)	Nein automatisch — nur was im Issue/Kommentar steht + was der Agent aktiv aus dem Checkout liest

In AGENTS.md steht explizit: „Cursor does not auto-load context.“ — die Tier-1/2-Reads sind Betriebsanweisung an den Agent, kein technisches Pre-Loading aller Dateien.

Run-spezifische Infos mitgeben (z. B. Timeout)

Priorität laut AGENTS.md: Explizite Chat-/Issue-Anweisung schlägt alles (inkl. AGENTS.md).

Methode	Wann nutzen	Beispiel
1. Issue-Kommentar / Issue-Body	Pro Run, sofort wirksam	`@cursor … Timeout: 5 Min — vorher fertig werden, lieber kleiner Scope als halbfertig.`
2. `agent_timeout` im Workflow	Hartes Limit (Abbruch)	Bereits in `.gitea/workflows/cursor.yml`: `agent_timeout: 5m`
3. `SOUL.md` → Agent Quick Start	Projektweite Defaults für Bot-Runs	z. B. „Bot-Runs: max. 5 min, kein Refactor, nur antworten wenn Frage“
4. `AGENTS.md`	Globale Agent-Policy	eher für dauerhafte Regeln, nicht pro Run

Empfehlung für dein Timeout-Beispiel:

Hart: agent_timeout im Workflow (läuft schon mit 5m).
Weich (Verhalten): Direkt im @cursor-Kommentar — das ist die zuverlässigste Stelle, weil es immer im Prompt landet (siehe CONTEXT_INFORMATION → comment.body / issue.body).
Projekt-Default: Kurzer Block in SOUL.md unter Agent Quick Start, falls jeder Bot-Run das wissen soll.

AGENTS.md allein ist kein guter Kanal für einmalige Run-Parameter — zu unsicher, ob und wann voll gelesen wird, und zu global.

Praktisches Template für Issue-Kommentare

@cursor
**Run:** timeout 5m — lieber früh mit Kurzfassung abbrechen als überziehen.
**Scope:** nur Frage beantworten, keine Commits.

<deine eigentliche Aufgabe>

Wenn du willst, kann ich in SOUL.md einen festen „Gitea-Bot Run Defaults“-Abschnitt ergänzen (z. B. Timeout-Hinweis + Scope-Disziplin).

## AGENTS.md — wird es jedes Mal gelesen? **Kurz: nicht automatisch vollständig.** Es kommt auf den Kanal an. ### Was tatsächlich passiert | Kanal | AGENTS.md im Kontext? | Rest (SOUL, BOUNDARIES, …)? | |-------|------------------------|-----------------------------| | **Cursor IDE** (lokal) | Nur wenn als **Workspace Rule** / `.cursor/rules` eingebunden — sonst muss der Agent die Datei selbst lesen | Laut `AGENTS.md` **Tier 1/2**: Agent *soll* bei substanziellen Tasks `SOUL.md` + `BOUNDARIES.md` (Tier 1) bzw. den Rest (Tier 2) lesen — **kein Garantie-Auto-Load** | | **`@cursor` Gitea-Bot** (dieser Run) | In dieser Session: **ja**, als Workspace Rule injiziert (`always_applied_workspace_rules`) | **Nein** automatisch — nur was im Issue/Kommentar steht + was der Agent aktiv aus dem Checkout liest | In `AGENTS.md` steht explizit: *„Cursor does not auto-load context.“* — die Tier-1/2-Reads sind **Betriebsanweisung an den Agent**, kein technisches Pre-Loading aller Dateien. --- ### Run-spezifische Infos mitgeben (z. B. Timeout) **Priorität laut `AGENTS.md`:** Explizite Chat-/Issue-Anweisung schlägt alles (inkl. AGENTS.md). | Methode | Wann nutzen | Beispiel | |---------|-------------|----------| | **1. Issue-Kommentar / Issue-Body** | Pro Run, sofort wirksam | `@cursor … Timeout: 5 Min — vorher fertig werden, lieber kleiner Scope als halbfertig.` | | **2. `agent_timeout` im Workflow** | Hartes Limit (Abbruch) | Bereits in `.gitea/workflows/cursor.yml`: `agent_timeout: 5m` | | **3. `SOUL.md` → Agent Quick Start** | Projektweite Defaults für Bot-Runs | z. B. „Bot-Runs: max. 5 min, kein Refactor, nur antworten wenn Frage“ | | **4. `AGENTS.md`** | Globale Agent-Policy | eher für dauerhafte Regeln, nicht pro Run | **Empfehlung für dein Timeout-Beispiel:** - **Hart:** `agent_timeout` im Workflow (läuft schon mit `5m`). - **Weich (Verhalten):** Direkt im `@cursor`-Kommentar — das ist die zuverlässigste Stelle, weil es **immer** im Prompt landet (siehe `CONTEXT_INFORMATION` → `comment.body` / `issue.body`). - **Projekt-Default:** Kurzer Block in `SOUL.md` unter *Agent Quick Start*, falls jeder Bot-Run das wissen soll. AGENTS.md allein ist **kein guter Kanal für einmalige Run-Parameter** — zu unsicher, ob und wann voll gelesen wird, und zu global. --- ### Praktisches Template für Issue-Kommentare ```text @cursor **Run:** timeout 5m — lieber früh mit Kurzfassung abbrechen als überziehen. **Scope:** nur Frage beantworten, keine Commits. <deine eigentliche Aufgabe> ``` Wenn du willst, kann ich in `SOUL.md` einen festen „Gitea-Bot Run Defaults“-Abschnitt ergänzen (z. B. Timeout-Hinweis + Scope-Disziplin).

froxxxy closed this issue

2026-07-08 08:47:03 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: froxxxy/playground#7

token Management #7