[Vitozhu04]

What

The agent skills now send the render the person receives through hyperframes cloud render -o <path> when npx hyperframes auth status shows a paid HyperFrames plan. Previews, snapshots and draft checks stay local; on Free the default stays local unless the person asks for cloud; a refused or failed cloud render falls back to a local one and the agent says why.

Why

Owner request (Wenbo): if the person has a HyperFrames subscription, render in the cloud. reverse-any-video already gates on a paid plan but rendered locally, and references/cloud.md described local vs cloud with no reference to the plan.

Billing evidence (experiment-framework main):

• The CLI's OAuth client (packages/cli/src/auth/config.ts:3,12) is a HyperFrames product client: heygen/core/constants/oauth_clients.py:6-7,29-31, so resolve_product returns HYPERFRAMES (heygen/core/constants/product.py:11-15), called from the render route at movio/api_service/app/controller/hyperframes_v3.py:134.
• create_render, movio/api_service/app/service/hyperframes_api_render.py:785-786: if product is Product.HYPERFRAMES and hyperframes_plan_paid_up(space_id): billing_mode = HF_PLAN_RENDER_BILLING_MODE, which hf_render_charge.py:22-23 defines as "A render by a payer holding a HyperFrames plan ... it is neither admitted nor charged." The workflow skips the deduction for it (heygen/temporal/workflow/product/hyperframe_render_streaming_workflow.py:381-383). Paid-up means Pro or Max active/trialing, or an internal plan (heygen/services/payments/hyperframes/plan_holds.py:24,69-81).
• Without a paid-up plan: a free-tier HeyGen space with no HF plan takes one of the free monthly API renders the MCP and CLI share (hyperframes_api_render.py:700-706,789-794); otherwise the render is admitted against and charged to the HF usage pool (:795-796, hf_render_charge.py:45-83), and a shortfall with no HF plan is refused hf_subscription_required (heygen/services/payments/hyperframes/usage_refusals.py:39-47).

Live dev check (CLI 0.8.223, HYPERFRAMES_ENV=dev, an account whose HF line reads Free on a paid HeyGen workspace): cloud render --quality draft on a 2 s composition uploaded the zip and was refused at submit, HTTP 402 ... code: hf_subscription_required; no render was created and auth status was unchanged. That is the HF route, not HeyGen OAuth billing.

How

• skills/hyperframes-cli/SKILL.md: loop step 5 names cloud render -o out.mp4 for the final on a paid plan; the "Render where" hosted row now reads "Paid-plan finals, hosted" (the entry was 37 B under its 7168 B budget, hence the terse wording).
• skills/hyperframes-cli/references/cloud.md: a "Final renders on a paid plan" paragraph with the rule, the Free default, the fallback, and two cloud limits the agent has to respect: the CLI sends no --fps unless given and the API defaults to 30, so pass the root's data-fps; a fractional rate or an aspect other than 16:9, 9:16 or 1:1 renders locally.
• skills/hyperframes-cli/references/preview-render.md: the "Where to render" line points paid-plan finals at cloud.md.
• skills/reverse-any-video/SKILL.md: the end check renders with cloud render --fps <data-fps> -o <out> and diffs that file; the 10-minute foreground / detached guidance is kept for the local fallback only.
• skills-manifest.json regenerated.

No prices or credit numbers added.

Test plan

• node scripts/check-core-skills.mjs: within budget (hyperframes-cli 7167/7168 B, reverse-any-video 5090/5120 B), commands and paths resolve
• bun scripts/lint-skills.ts: no issues
• bun packages/cli/scripts/gen-skills-manifest.ts --check: in sync
• oxfmt --check on the changed files
• Live check on a Pro account (pending the owner's subscribe step)

— wanbi

🤖 Generated with Claude Code

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 1 important · 0 nits · 2333617

Billing claims and the auth status strings check out (status.ts:275-308), and so do the CLI limits (integer --fps only, aspect auto-detected from 16:9/9:16/1:1). The gap is the command itself: as written, a paid user's final comes out at a different frame rate and lower quality than today's local delivery render. Details inline. Additive to @miguel-heygen's approval.

Scope

Read all 5 files at head. Checked packages/cli/src/commands/cloud/render.ts (fps default 30, quality default standard, aspect detection), auth/status.ts, render/plan.ts and engine/.../chunkEncoder.ts (standard = CRF 18, high = CRF 15; local looks = CRF 16). The Actions runs at the head are green, and check-core-skills passes locally. Not verified: a live paid-plan render.

— Genesis (for Wenbo)

[heygengenesis]

blocker: this is the command agents copy, and it has no --fps. cloud render defaults to 30 (cloud/render.ts:122) where local render uses the root's data-fps, so a 24 or 60 fps composition comes out at 30 on a paid plan. The step-5 ffprobe duration check still passes, so nothing catches it. The rule is only in cloud.md, which step 5 doesn't link to. Fix: cloud render --fps <data-fps> --quality high -o out.mp4 (see the quality note on cloud.md). The entry is at 7167/7168 B, so this needs a trim somewhere else, e.g. shorten the row rename at :63.

[heygengenesis]

important: the final used to be local --quality delivery (= high, CRF 15). cloud render defaults to standard (cloud/render.ts:123; the engine preset is CRF 18), so moving the final to the cloud quietly lowers its quality for exactly the users who pay. Spell out --quality high here alongside --fps. The reverse-any-video diff render can stay at the default.