OpenCode's Free AI Models: How Are They Actually Making Money, and Are Paid APIs Still Worth It?

# PROMPT 1

You are a senior frontend engineer and 3D web graphics engineer working autonomously inside the current project directory.

Your job is to BUILD AND FINISH the application, not merely explain how to build it.

Inspect the existing project first. Reuse the current stack where sensible. Make reasonable engineering decisions yourself, implement the full feature, run the relevant checks/build, fix errors you encounter, and leave the project in a working state.

Do not stop after scaffolding.
add a .gitignore that excludes node_modules/, build output, caches, environment files, and generated assets.

# GOAL

Build a premium full-screen interactive **3D Gaming PC Hardware Explorer**.

The centerpiece is a complete desktop gaming PC that users can rotate, zoom, inspect, isolate, and progressively explode into its individual hardware components.

This is NOT a car, vehicle, ecommerce page, or generic dashboard.

The subject is PC hardware:

* Gaming PC chassis
* NVIDIA RTX-class graphics card
* Motherboard
* CPU
* CPU cooler / AIO
* RAM
* Power supply
* NVMe SSD / storage
* Case fans
* Radiator
* Side panels and structural case parts

The finished application should feel like a premium engineering teardown, interactive hardware museum exhibit, or technical product visualization.

# CORE EXPERIENCE

The browser should open directly into a dark, cinematic, full-screen 3D studio.

Initially show the gaming PC completely assembled.

The user must be able to:

1. Drag to orbit around the computer.
2. Scroll or pinch to zoom.
3. Click individual hardware components.
4. Hover components for subtle visual feedback.
5. View technical information about the selected component.
6. Isolate a selected component.
7. Reset the camera.
8. Enable or disable slow automatic rotation.
9. Toggle component labels.
10. Drag an **Explode slider from 0–100%**.
11. Instantly return to the assembled computer.
12. Instantly show the fully exploded computer.

The 3D scene should remain the focus of the application. UI controls should float over it rather than pushing the 3D view into a small card.

# EXPLODED VIEW

The exploded-view system is the most important feature.

At 0% the PC is fully assembled.

As the slider increases, components should separate according to realistic hardware disassembly directions.

Examples:

* Tempered-glass panel → sideways away from chassis
* GPU → outward from PCIe slot
* RAM → upward from DIMM slots
* CPU cooler → upward from CPU
* CPU → slightly upward from socket
* Motherboard → outward from motherboard tray
* PSU → outward from lower/rear compartment
* NVMe SSD → upward/outward from M.2 slot
* Radiator → away from its mounting location
* Fans → outward along their mounting axis

Every component must retain its original scale and generally retain its orientation.

Use deterministic interpolation between assembled and exploded transforms.

Do not use random movement or physics.

From roughly 0–70%, prioritize believable physical disassembly.

From roughly 70–100%, spread the hardware farther apart into a clean technical exploded layout so individual pieces are easy to understand and do not heavily overlap.

At 100%, it should immediately look like a complete gaming PC broken down into its internal hardware.

Button-triggered transitions such as Assemble or All Parts should animate smoothly with easing.

Dragging the slider itself should remain directly responsive to user input.

# 3D HARDWARE

Use Three.js.

If the project already contains suitable local GLB/GLTF assets, use them.

Otherwise create a convincing stylized gaming PC using Three.js geometry.

Do NOT leave the final scene as basic colored cubes.

The computer should include enough geometry and detail that each major part is visually recognizable.

## Chassis

Create a modern gaming tower with:

* metal frame
* front/top/rear panels
* transparent side panel
* motherboard tray
* PSU shroud
* ventilation
* fan mounting positions
* feet

The interior must remain clearly visible.

## GPU

Create a substantial modern RTX-class GPU.

It should visually read as a high-end graphics card.

Include:

* thick GPU body
* cooling shroud
* 2–3 fans
* visible fan blades
* heatsink/fins
* backplate
* PCIe edge/connector area
* power connector area

A subtle RTX-style marking is fine, but do not depend on branding to make the model recognizable.

## Motherboard

Create an ATX-style motherboard with visible:

* PCB
* CPU socket
* four DIMM slots
* PCIe slot
* VRM heatsinks
* chipset heatsink
* M.2 area
* rear I/O
* smaller board details

## CPU

The CPU must be its own selectable and explodable component.

Show a metallic heat spreader, substrate, and CPU socket underneath it.

The CPU should become visible when the cooler separates.

## RAM

Create at least two separate RAM DIMMs with:

* PCB
* heat spreader
* contact edge
* correct positioning beside the CPU

## Cooling

Prefer a premium AIO setup:

* CPU pump/block
* tubes
* radiator
* multiple radiator fans

Use tube/curve geometry for coolant tubes if practical.

## PSU

Create a recognizable PSU with:

* metal enclosure
* fan or fan grille
* modular connector section

## Storage

Include at least one M.2 NVMe SSD mounted on the motherboard.

## Fans

Case and radiator fans should include frames, hubs, and multiple blades rather than simple flat discs.

# VISUAL STYLE

Create a dark technical studio.

Suggested visual direction:

* near-black background
* dark graphite floor
* subtle grid or engineering pattern
* low display platform beneath PC
* cool gray / blue-gray interface
* restrained RGB accents

Lighting should feel like premium product photography.

Use a combination of:

* neutral key light
* cool rim light
* soft environmental fill
* subtle warm accent light

Use appropriate materials for:

* painted metal
* brushed metal
* PCB
* black plastic
* glass
* copper/gold contacts
* rubber
* subtle emissive LEDs

Avoid excessive rainbow RGB.

Use ACES filmic tone mapping if appropriate.

Enable antialiasing and shadows while keeping performance reasonable.

# CAMERA AND CONTROLS

Use a PerspectiveCamera and OrbitControls.

Initial camera angle should show the complete PC from a flattering front-side three-quarter view.

Enable:

* damping
* sensible zoom limits
* limited polar angle
* slow optional auto-rotation

Implement controls for:

* zoom in
* zoom out
* reset camera
* toggle auto-rotate
* fullscreen where available

# COMPONENT SELECTION

Use Three.js raycasting.

Clicking visible hardware should:

1. Select the component.
2. Give it subtle visual emphasis.
3. Update/open the detail panel.
4. Keep camera controls usable.

Hovering a selectable component should provide subtle brightness/emissive feedback.

Do not trigger component selection after the user merely dragged the mouse to orbit.

Use a click-versus-drag movement threshold.

# COMPONENT DATA

Create a central typed data model for hardware information.

For example:

```ts
type HardwarePart = {
  id: string
  name: string
  category: string
  description: string
  principle: string
  specs: [string, string][]
}
```

Include meaningful entries for:

* Chassis
* Graphics Card
* Motherboard
* Processor
* CPU Cooling
* Memory
* Power Supply
* Storage
* Case Cooling

Use realistic illustrative specs.

Example GPU:

* Architecture: RTX-class
* VRAM: 16 GB
* Interface: PCIe x16
* Cooling: Triple fan

Example memory:

* Capacity: 32 GB
* Configuration: 2 × 16 GB
* Type: DDR5

Do not pretend procedural geometry represents an exact commercial model.

# UI LAYOUT

Keep the Three.js canvas full-screen.

All UI floats over it.

Use semi-transparent near-black panels with:

* subtle borders
* slight blur
* small corner radius
* compact typography
* blue-gray accents

Avoid generic oversized SaaS styling.

## Top left

Small technical plaque:

`HARDWARE LAB`

and below it:

`GAMING PC`

Use subtle uppercase typography with letter spacing.

## Left panel

Create a vertically centered **Components** panel.

Example list:

01 Chassis
02 Graphics Card
03 Motherboard
04 Processor
05 CPU Cooling
06 Memory
07 Power Supply
08 Storage
09 Case Cooling

Clicking a row selects that component.

Clearly indicate the selected row.

## Right detail panel

Show:

* component category
* large component name
* Overview tab
* How it works tab
* description
* technical specification rows
* Isolate component button

When already isolated, change the button to:

`Show everything`

## Right vertical toolbar

Include compact icon controls for:

* components
* zoom in
* zoom out
* reset view
* auto rotate
* fullscreen
* help/about

Use Lucide React or an equivalent lightweight icon library if available.

# BOTTOM EXPLOSION CONTROL

Create a prominent floating control dock centered near the bottom.

Layout:

Left:

`Assemble`

Center:

`EXPLODE`

0–100 slider with numeric percentage.

Right:

`All Parts`

Then:

`Labels`

toggle.

Clicking Assemble should return explosion to 0 and cancel isolation.

Clicking All Parts should move explosion to 100 and cancel isolation.

The slider must manipulate the actual Three.js component transforms continuously.

# LABELS

When Labels is enabled, show compact screen-space labels attached to important components.

At minimum:

* GPU
* CPU
* Motherboard
* RAM
* Cooling
* PSU
* NVMe

Labels should follow their corresponding 3D positions as the camera moves.

Hide labels when the related component is not visible or is behind the camera.

# ISOLATION MODE

When a component is isolated:

* hide or strongly fade unrelated hardware
* keep selected hardware fully visible
* preserve camera orbit/zoom
* allow returning to the complete system

Do not permanently corrupt shared material or visibility state.

# RESPONSIVE DESIGN

Desktop at approximately 1920×1080 is the main target.

Still make the application usable on smaller screens.

On mobile/narrow layouts:

* collapse panels when necessary
* preserve a large visible 3D area
* move information panels toward bottom-sheet behavior
* enlarge touch targets
* keep the explode control usable
* support safe-area insets

Do not simply hide the functionality.

# PERFORMANCE

Keep high-frequency rendering logic inside Three.js rather than React state where possible.

Use refs appropriately.

Reuse geometries/materials where practical.

Cap renderer pixel ratio.

Clean up controls, listeners, renderer resources, materials, geometries, and DOM labels when unmounting.

Handle resize correctly.

# ERROR HANDLING

If WebGL cannot initialize, show a graceful error message instead of crashing.

Avoid console spam.

# PROJECT IMPLEMENTATION

Inspect the current project before changing architecture.

If React/Next/Vite/TypeScript already exists, build within it.

Preferred technologies:

* React
* TypeScript
* Three.js
* OrbitControls
* modern CSS
* Lucide React if icons are needed

Keep 3D scene logic reasonably separate from UI/data.

Do not add large unnecessary dependencies.

# QUALITY BAR

The final result should instantly communicate:

“This is a gaming PC exploded into its individual hardware.”

It should NOT look like:

* a beginner Three.js tutorial
* random boxes floating in space
* a tiny model inside a dashboard
* a generic PC shop
* unfinished scaffolding

Prioritize visual effort in this order:

1. GPU
2. Motherboard
3. CPU and cooling
4. RAM
5. Chassis
6. Fans/radiator
7. Exploded-view composition
8. Lighting/materials

Small geometry details such as vents, fan blades, heatsink fins, motherboard heatsinks, connectors, ports, DIMM slots, and GPU cooling details are strongly encouraged.

# VALIDATION

Before finishing:

1. Install only necessary dependencies.
2. Make the app run.
3. Run TypeScript checks if configured.
4. Run lint if configured.
5. Run the production build.
6. Fix errors you caused.
7. Verify the explosion slider changes actual 3D hardware transforms.
8. Verify clicking/selecting components.
9. Verify isolate/show-all.
10. Verify camera reset.
11. Verify labels.
12. Verify auto-rotate.
13. Verify the page remains usable at a narrow viewport.
14. Remove temporary debugging code.
15. Leave no TODO placeholders for core functionality.

If browser or screenshot automation is available, inspect the finished application visually and fix obvious layout or rendering problems.

Do not return a tutorial telling me what to implement.

Actually modify the project and complete the application.

When finished, respond only with a concise summary containing:

* what you implemented
* important files changed
* checks/build commands run
* any genuine remaining limitation

# PROMPT 2

Act as an expert front-end developer. Create a complete single-page portfolio website for a Personal Trainer / Fitness Coach in one self-contained HTML file (inline CSS + vanilla JS only). No external libraries or frameworks.

Style direction:
- Minimalist, premium, and modern
- Dark gray (#1a1a1a or similar) background, white text, soft blue accents
- Clean typography, generous whitespace, subtle shadows and rounded corners
- Smooth scroll and refined hover states
- Fully responsive (mobile-first)

Required sections:

1. Sticky navbar
   - Logo/name on the left
   - Links: Home, About, Programs, Contact
   - Subtle background blur or solid dark when scrolled

2. Hero section
   - Large name + short title (e.g. “Personal Trainer & Performance Coach”)
   - Two buttons: “View My Programs” (smooth scrolls to Programs) and “More About Me” (smooth scrolls to About)
   - Clean, impactful layout with good vertical rhythm

3. About section
   - Left: placeholder photo area (styled as a professional headshot box with subtle border/shadow)
   - Right: short, professional fitness biography (3–4 sentences)
   - Balanced two-column layout on desktop, stacked on mobile

4. Programs section
   - 3–4 cards in a responsive grid
   - Each card has: SVG icon or simple badge, title, short description, and two buttons:
     - “Book Session” → smooth scrolls to Contact
     - “Learn More” → prefills the contact form message with the program name
   - Cards should feel elevated and interactive on hover

5. Skills section
   - Horizontal or grid list of skills with simple icons:
     Strength Training, Mobility, HBT, Nutrition, Rehab/Prehab, Online Coaching

6. Contact section
   - Clean form: Name, Email, Message, Send button
   - “Learn More” buttons from Programs should prefill the Message field
   - Simple success feedback after “sending” (no real backend needed)

7. Footer
   - Social links: Instagram, YouTube, LinkedIn (use simple icons or text)
   - Copyright line

Extra requirements:
- Smooth scrolling for all internal links
- Subtle fade-in or slide-up animations on scroll (vanilla JS only)
- Excellent mobile experience
- High visual polish : it should look like a real paid portfolio, not a template

# PROMPT 3

Using the installed HyperFrames skill, create an editorial motion-graphics video explaining TimesFM-3.

SOURCE
https://research.google/blog/timesfm-3-a-zero-shot-foundation-model-for-multivariate-forecasting/

Read the article before building. Use it as the factual source and visual reference. Create original HTML/CSS and inline SVG graphics that explain its concepts.

DELIVERABLE
- Canvas: exactly 1080 × 700 pixels.
- Frame rate: 30 fps.
- Duration: exactly 1,120 frames, or 37⅓ seconds.
- Eight scenes in the sequence below.
- Silent video: no narration, music, or sound effects.
- Editable HyperFrames project, working Studio preview, and final MP4 after preview approval.

WORKFLOW
Read the HyperFrames router first and follow the appropriate workflow for an article-based explainer with original diagrams.

Treat this as a complete creative brief. Make routine design and implementation decisions autonomously and proceed through the full eight-scene build. Keep a concise BRIEF.md and STORYBOARD.md.

Scaffold a dedicated project directory with the HyperFrames CLI. Keep its generated configuration and version pins. Use the installed CLI’s supported commands and consult its help when necessary.

Search the HyperFrames catalog for suitable chart, diagram, typography, and transition primitives before creating equivalents by hand. Adapt useful primitives to this editorial style.

VISUAL DIRECTION
Match the Google Research article’s clean editorial character:
- White background: #ffffff.
- Main text: #202124.
- Light-gray rules and structure: #dadce0.
- Blue: #4285f4.
- Red: #ea4335.
- Yellow: #fbbc04.
- Green: #34a853.

Use an available Google Sans–style geometric sans font. Prefer locally bundled Inter with a system sans fallback. Define local font files with @font-face and wait for fonts before measuring text.

Keep typography dominant, diagrams precise, and layouts airy. Use a consistent grid and approximately 48-pixel outer margins. Favor short labels, clear hierarchy, and generous spacing. Main explanatory text must remain readable at the final 1080 × 700 size.

Use near-black for small text; use the accent colors primarily for diagrams, paths, highlights, and larger display elements. Maintain readable contrast.

Recreate diagrams as editable SVGs. Download any necessary assets during setup and reference them locally. Use accurate GitHub and Hugging Face SVG icons from a reliable source. Do not fabricate a Google product logo.

HYPERFRAMES IMPLEMENTATION
- Build a main composition containing eight scene sub-compositions.
- Use explicit data-composition-id, data-width, data-height, and a static root data-duration.
- Derive scene starts and durations from the frame boundaries below using frame / 30. Avoid accumulated timing errors from rounded seconds.
- The standalone index.html root belongs directly in the body.
- Follow HyperFrames’ documented template structure for sub-compositions, including styles and scripts in the correct location.
- Keep IDs unique throughout the assembled composition.
- Register exactly one paused GSAP timeline per composition at window.__timelines[compositionId], after its tweens are fully built.
- Let HyperFrames assemble and seek the child timelines.
- Declare scene and clip timing explicitly. Organize Studio tracks consistently by element type.
- Animate inner visual wrappers. Let HyperFrames control timed clip visibility.
- Use flex/grid for layout and GSAP transforms and opacity for most motion. Avoid conflicting CSS and GSAP transforms.

Every frame must be reproducible when seeking directly to that time:
- No animation driven by wall-clock time, timers, or independent playback loops.
- No unseeded randomness.
- No required network requests during rendering.
- Precompute chart data and geometry.
- Keep charts and diagrams faithful when seeking backward or jumping between scenes.

MOTION LANGUAGE
Use restrained, technically precise motion:
- Short staggered text reveals.
- SVG line drawing and mask reveals.
- Smooth chart interpolation.
- Gentle spring-like easing for selected entrances.
- Subtle fades, translation, and scale changes.
- Consistent timing across similar elements.

Prioritize one main visual action at a time. Give completed charts and key statements a readable hold. Use spring-like motion sparingly; chart values and uncertainty bands should settle without distracting oscillation.

Transitions must fit inside the scene allocations. Do not extend the runtime or shorten the stated scene slots. Use continuous visual handoffs where helpful.

SCENE TIMING
Frame ranges below include the start and exclude the end.

Scene 1: frames 0–120       / 120 frames
Scene 2: frames 120–270     / 150 frames
Scene 3: frames 270–430     / 160 frames
Scene 4: frames 430–560     / 130 frames
Scene 5: frames 560–700     / 140 frames
Scene 6: frames 700–820     / 120 frames
Scene 7: frames 820–1000    / 180 frames
Scene 8: frames 1000–1120   / 120 frames

SCENE 1 : RESEARCH LAUNCH
Create a minimal Google Research–style article header.

On the left:
- Oversized title: “TimesFM-3”.
- Subtitle: “Zero-shot multivariate forecasting”.
- Small gray attribution: “Google Research · 2026”.

Reveal the title and subtitle in a deliberate sequence.

On the right, animate a compact architecture sketch:
input time-series charts → colored patch blocks → attention grid → forecast output.

Keep the sketch legible and subordinate to the title.

SCENE 2 : MODEL AT A GLANCE
Create a centered model overview with three clear statements:
- “330M parameters”
- “1T+ training time points”
- “Zero-shot”
  Supporting label: “No task-specific fine-tuning”

Draw thin blue, red, yellow, and green time-series traces behind the overview without interfering with the text.

Finish with:
“Multiple targets. Past covariates. Known future signals.”

SCENE 3 : FROM ONE SERIES TO MANY
Use a split-screen comparison.

Left:
“Single-series forecasting”
Show one red historical sales series extending into a forecast without promotion or cross-series information.

Right:
“TimesFM-3 · Multivariate”
Show related sales, historical foot traffic, planned promotions, and weather forecasts informing a blue sales forecast.

Distinguish:
- Multiple targets: related series forecast together.
- Past covariates: information available historically.
- Past–future covariates: signals known for the forecast period.

Use concise labels and a clear visual flow. Charts are illustrative, not measured benchmark results.

SCENE 4 : ALTERNATING ATTENTION
Create a simplified native SVG architecture diagram.

Group incoming observations into patches of 32 time steps, then arrange their tokens in a two-dimensional grid:
- Horizontal axis: time.
- Vertical axis: series.

Animate:
1. Causal temporal attention horizontally in blue, using only permitted past positions.
2. Full variate attention vertically in green at a given time position.

Highlight lookahead information from known future covariates in yellow. Make clear that these are known external signals, not leaked future target values.

Bottom caption:
“Time patterns + cross-series relationships”

SCENE 5 : ONE FORWARD PASS
Place observed context on the left and masked future target patches on the right.

Keep known future covariates visibly available beneath the forecast horizon.

A controlled blue sweep passes through the model and reveals all future target patches together.

Transform the forecast into nine quantile curves:
10th, 20th, 30th, 40th, 50th, 60th, 70th, 80th, and 90th percentiles.

Use light shading between curves and a strong median line. Keep the quantiles ordered so they never cross.

Display:
“10th–90th percentile forecasts”

Supporting statements:
“One forward pass”
“No iterative decoding”
“Probabilistic uncertainty”

SCENE 6 : PROMOTION FORECAST
Recreate the article’s illustrative ice-cream sales example as an original SVG chart.

Show:
- Historical sales and a clearly marked forecast boundary.
- A red univariate forecast following the regular weekly pattern.
- Amber promotion blocks aligned with scheduled promotion days.
- A blue multivariate forecast responding to those promotions.

Annotate an illustrative “~20% promotion-day lift”, consistent with the article. Do not present this as a universal performance guarantee.

Keep axes minimal. Include a small “Illustrative example” label.

SCENE 7 : BENCHMARK LEAD
Introduce three editorial benchmark cards in sequence:
- GIFT-Eval
- FEV-Bench
- TIME

Show TimesFM-3 leading among the pretrained foundation models evaluated in the article, covering both point and probabilistic forecasting.

Include comparison labels for:
- TimesFM-2.5
- Chronos-2
- Toto 2.0

Use a qualitative ranking treatment or faithfully sourced ranks. Do not invent scores, bar lengths, competitor ordering, or numerical improvements.

Final statement:
“Best average rank across all three benchmarks”

Keep the qualification visible:
“Among evaluated pretrained foundation models”

SCENE 8 : EXPLORE TIMESFM-3
Large headline:
“Forecast together”

Animate four colored time-series lines converging toward a blue forecast region.

Reveal accurate GitHub and Hugging Face icons with:
“Available now”

Add:
“Also available in BigQuery”

Final destination:
“github.com/google-research/timesfm”

Finish with a restrained four-color underline and:
“What would you forecast?”

Hold the final composition long enough to read.

QUALITY AND HANDOFF
1. Run lint during development after meaningful structural changes.
2. Run hyperframes check as the final validation gate; it already includes lint.
3. Fix persistent runtime, missing-resource, layout, and contrast findings.
4. Capture and visually inspect every scene midpoint, plus scene boundaries and the final frame. Check text fit, SVG rendering, mounting, and direct seeking.
5. Verify the full timeline covers exactly 1,120 frames at 30 fps without blank gaps.
6. Start the complete Studio preview, verify it responds, and provide its actual project URL. If other previews are running, use an available port.
7. Leave the preview running for review and request final approval before encoding.
8. After approval, render the MP4 using the installed CLI’s delivery quality setting.
9. Verify the output with ffprobe: 1080 × 700, 30 fps, 1,120 frames, approximately 37.333 seconds. Inspect representative frames from the encoded file.
10. Deliver the editable project path, preview URL, and final MP4 path.