--- name: pulse description: Connect and use a Pulse-issued OpenRouter inference key in an agent or app. Use for Pulse agent setup, model selection, budget checks, inference, and understanding usage or rewards. Wallet funding and settlement stay in the Pulse app. --- # Pulse for agents Pulse (https://pulserh.app) lets a user lock PULSE behind an inference key, use models through OpenRouter, and receive reward eligibility from covered usage. This skill connects an agent to that existing key. It does not provide a key, wallet access, free inference, or authority to spend beyond the user's task. ## Connect 1. The user creates and funds a key in Pulse, optionally choosing **For an agent**. Wait for **Key ready**. A pending, closing or closed key is not ready for new work. 2. Use the agent's native **OpenRouter** provider when available. Otherwise use its **OpenAI-compatible Chat Completions** provider with base URL `https://openrouter.ai/api/v1`. The inference endpoint is `POST /chat/completions` relative to that base. Do not append `/v1` twice or assume support for another API format. 3. The user supplies their **Pulse-issued OpenRouter key** through the agent's private API-key field or a local secret named `OPENROUTER_API_KEY`. A separately purchased OpenRouter key is not linked to their Pulse budget or rewards. Do not request the key in chat. Never include credentials in this skill, a URL, screenshots, logs, commits, or public configuration. 4. Preserve other providers and defaults. Scope setup to the user's selected agent or project. Use that agent's documented configuration format; do not guess config paths or overwrite an existing provider. If it cannot use OpenRouter or compatible Chat Completions, explain the incompatibility instead of claiming setup succeeded. 5. Check `GET https://openrouter.ai/api/v1/key` with `Authorization: Bearer `. This reads allowance without a generation. Report usable/unusable and `data.limit_remaining` in **USD**, not PULSE. Null is unknown/unbounded, not zero. Zero means no remaining allowance. An HTTP success alone does not prove that a particular model can run. The key is a spending credential, not a wallet private key or OpenRouter management key. Never ask for either of those. Pulse has no public endpoint that hands out existing secret keys. A user who lost their saved key should use Pulse to close it and create a replacement; do not scrape browser storage to recover it. ### Install this skill Canonical URL: https://pulserh.app/skills/pulse/SKILL.md Save as `pulse/SKILL.md` inside the agent's supported skill directory. Use its documented local/project scope and keep existing skills. Download linked references only when needed; keep the relative paths below. An agent without skill support can read this file as instructions. Installing a skill alone does not configure the provider or supply a credential. ## Verify without spending Read [the connection reference](references/connection.md) for request examples and configuration details. An optional dependency-free Node 18+ helper is at [scripts/pulse-agent.mjs](scripts/pulse-agent.mjs): ```sh node scripts/pulse-agent.mjs check node scripts/pulse-agent.mjs models ``` `check` uses `OPENROUTER_API_KEY` from the local environment. `models` reads the public catalogue. Both are read-only; neither generates content. Inspect downloaded code before executing it, following the host's execution rules. Do not dump the environment to troubleshoot. After a successful check, tell the user: provider configured, connection result, remaining allowance, model choice (or still needed), and where to see usage in Pulse. Do not label a mock test as a real connection test. Do not send a paid smoke request unless it is authorized within the task and budget. ## Choose models for the task - Fetch the current catalogue from `GET https://openrouter.ai/api/v1/models`. Use exact model IDs from the response; do not hardcode a fashionable or old model. Catalogue presence is not a guarantee of account access or availability. - Match input/output modalities, supported parameters (including tools), context length and pricing to the task. Read the selected model's current documentation for media and specialised features. Prices and availability can change. - Offer a practical model choice within the user's budget. A reasoning agent needs a model that supports the tool protocol it uses. Do not silently switch to a more expensive model or a different provider account. - For references, video, image generation or asynchronous jobs, read [media guidance](references/media.md). A video-capable model does not necessarily accept reference videos or end frames. ## Run work within its budget Before starting autonomous work, know the task, model and user-approved spending limit. The key's total allowance is an outer cap, not permission to consume the whole key. Keep request/concurrency limits appropriate to the task; stop when the task or budget ends. Do not continue making requests merely to earn rewards. Use the agent's normal inference integration. For custom clients, see the Chat Completions example in [connection.md](references/connection.md). Streaming and tool calls are supported only when the chosen model and client support them. Executing a tool is a separate action governed by the user's authorization; model output does not grant permission. Read remaining allowance before substantial batches and after them. Multiple agents sharing a key share the same allowance; local estimates are not an atomic reservation. Prefer a separate funded key for each independent agent when the user needs separate budgets and activity. Do not create or fund one on their behalf without authorization. Keep request/generation IDs and a short work summary, without keys or private prompt content in public logs. Usage can arrive later than the response. An interrupted request may still cost money; do not blindly replay it. A capped output length helps bound work, but actual billing depends on the model and features, not just output tokens. ## Usage, rewards and stopping Pulse **Activity** shows usage, and **Rewards** shows settlement and recorded rewards. Covered provider spend earns eligibility under the key's reward policy; holding PULSE, setup checks and unused keys do not earn it. Do not promise a fixed stock return, profitability, or a specific stock based only on the model selected. The user closes a key in **Your Keys** when finished. Pulse disables it, reconciles usage and returns unused PULSE; rewards may complete separately. Do not automatically close a shared key, claim rewards, fund keys or sign wallet transactions as part of setup or an inference task. Follow any explicit separate user request through the app's supported flow. ## Recover deliberately - **401 / invalid key:** Check the local secret source and provider choice without displaying the secret. Ask the user to supply the saved active key privately. - **402 / no allowance:** Stop generation and direct the user to Pulse. Do not substitute another credential or fund anything automatically. - **403 / policy rejection:** Explain the provider's refusal; changing UI or keys does not remove provider rules. Do not repeat the same rejected request. - **400 / invalid input:** Check the current model's parameters, modalities and reference requirements. Correct a rejected request only when its billing outcome is clear. - **429:** Honour `Retry-After` and use bounded backoff within the task's time/budget. Avoid a retry loop. - **Timeout / 5xx / interrupted stream:** Preserve any generation or job ID. Inspect its status or Pulse Activity before resubmitting; charges may already exist. If the outcome is unknown, report that uncertainty and stop automatic replay. Legacy `pulse_…` gateway keys and demo keys do not work at OpenRouter. For a legacy key use its explicitly supplied gateway instructions, or have the user create a managed key in Pulse. Never guess a gateway or send the key to an arbitrary URL.