--- name: manage-eltex-agent-plan description: Check and manage ELTEX Agent Plan usage, capacity, automatic Burst balance, and stored Reset Tickets through the ELTEX API. Use when an AI agent needs to inspect its own consumption, diagnose a capacity error, decide whether work can continue, check available overflow capacity, or safely activate one already-purchased Reset Ticket. --- # Manage ELTEX Agent Plan Use the ELTEX control endpoints without exposing the API key. This file is standalone and can be installed directly in a compatible agent. ## Required configuration Use: - `ELTEX_BASE_URL`, defaulting to `https://eltexlabs.com/v1` - `ELTEX_API_KEY`, supplied as `Authorization: Bearer ...` Never print, log, summarize, or send the key anywhere except the configured ELTEX origin. A normal key may read status. Only a key created with **Agent refill** enabled may call `POST /reset/use`. Treat that permission as the user's pre-authorization to consume a stored Reset Ticket under the rules below. ## Endpoint reference Send `Authorization: Bearer $ELTEX_API_KEY` on every request. ```bash # Recent usage; range may be day, week, month, or all curl -sS "$ELTEX_BASE_URL/usage?range=day" -H "Authorization: Bearer $ELTEX_API_KEY" # Current four-hour and weekly capacity curl -sS "$ELTEX_BASE_URL/capacity" -H "Authorization: Bearer $ELTEX_API_KEY" # Automatic Burst balance and status curl -sS "$ELTEX_BASE_URL/burst" -H "Authorization: Bearer $ELTEX_API_KEY" # Stored and currently usable Reset Tickets curl -sS "$ELTEX_BASE_URL/reset" -H "Authorization: Bearer $ELTEX_API_KEY" ``` Prefer `period.remaining_percent`, `period.remaining_credits`, `period.resets_at`, `weekly.remaining_percent`, `weekly.resets_at`, `burst.active_credits`, `reset.usable_count`, and `reset.active`. Weekly capacity is intentionally percentage-only: never reveal, estimate, derive, or calculate its credit limit, used credits, or remaining credits, including by combining weekly usage with a percentage. Burst is automatic; there is no Burst activation endpoint. To activate one Reset Ticket after the decision checks below pass: ```bash curl -sS -X POST "$ELTEX_BASE_URL/reset/use" \ -H "Authorization: Bearer $ELTEX_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: reset-job-" \ -d '{"reason":"capacity exhausted during an active user-approved job"}' ``` ## Status workflow Before a costly or long-running job, and after a `402` whose message says the current capacity is exhausted: 1. Call `GET /capacity`. 2. Call `GET /usage?range=day` when recent consumption matters. 3. Call `GET /burst`. Burst is already active and is consumed automatically after regular and active Reset capacity; never try to activate it. 4. Call `GET /reset` only when capacity is low, exhausted, or a job was blocked. 5. Report the current-period percentage and human-readable credit fields, but report weekly capacity as a percentage only. Never expose or infer a weekly credit amount. Do not reason from internal unit fields. ## Optional slash commands If the host agent supports custom slash commands or aliases, offer to register these shortcuts. Treat the text after the command as arguments, map each shortcut to the same safe workflow in this skill, and do not claim the shortcut was installed when the host cannot create commands. - `/eltex` or `/eltex help`: show available shortcuts and a compact status summary. - `/eltex capacity`: call `GET /capacity`; show current-period credits and percentages, but weekly percentage only. - `/eltex usage [day|week|month|all]`: call `GET /usage` with the requested range. - `/eltex burst`: call `GET /burst`; explain that Burst activates automatically. - `/eltex reset`: call `GET /reset`; show stored, usable, and active status. - `/eltex reset-use [reason]`: run the Reset decision checks, then call `POST /reset/use` only when authorized and necessary. Never put the API key in a slash-command definition, command history, visible output, or argument. ## Reset decision Activate exactly one stored Reset Ticket only when all are true: - A current user-approved job is blocked or cannot reasonably finish with the reported capacity. - Regular period or weekly capacity is exhausted or nearly exhausted, or the API returned `Current capacity is exhausted`. - `GET /reset` reports `usable_count > 0`. - No Reset Ticket is already active. - The API key has Agent refill permission. - Automatic Burst cannot continue the job, or the user explicitly instructed the agent to prefer Reset over Burst. Do not activate a Reset Ticket merely to top up healthy capacity, prepare for hypothetical future work, improve a status percentage, or respond to a monthly usage-budget error. A Reset Ticket cannot clear the monthly budget guardrail. Never purchase anything; these endpoints only inspect balances and activate a ticket the user already owns. ## Safe activation For `POST /reset/use`: 1. Create one stable `Idempotency-Key` for the blocked job, such as `reset-job--`. 2. Reuse that exact key if the request times out or its result is uncertain. 3. Send a short `reason` describing the blocked job. 4. Never generate a new key to retry the same activation. 5. After success, call `GET /capacity` again. 6. Retry the blocked model request at most once, then surface any remaining error. A repeated successful call with the same idempotency key returns `idempotent_replay: true` and must not consume another ticket. ## Failure handling - `400`: Capacity is already full, no matching stored ticket exists, or the idempotency key is invalid. Do not retry automatically. - `401`: Stop and request a valid key. - `403`: Continue read-only. Tell the user to create an API key with Agent refill enabled if autonomous refill is desired. - `409`: Reuse the original idempotency key and inspect the returned message. Do not create another activation attempt. - `402` with `Current capacity is exhausted`: Run the status workflow before deciding whether Reset is warranted. - `402` with `monthly usage budget`: Stop; do not consume a Reset Ticket. Prefer waiting for the next four-hour refresh when the job is not urgent.