Skip to navigation
Build with Mythos

Building and editing

View as Markdown

A Build creates the first working version of a project. An edit starts from the current version and changes it. Both use the same basic loop: describe an outcome, follow progress, inspect the delivered result, and decide what to do next.

Build the first version

Start with the purpose, audience, page structure, and visual direction. You do not need to prescribe every implementation detail.

Build a one-page website for North Slope, a neighborhood coffee roaster.
Include a hero, featured beans, wholesale information, opening hours,
and contact details. Use a warm, minimal visual style.

A useful first prompt tells Mythos what must be true in the result. Anything you leave open becomes a design decision Mythos can make for you.

Follow the delivery loop

1

Send one coherent request

Ask for a result you can review together. Your saved Build limit applies automatically; manage it in account settings or Project settings. A focused page or feature is easier to verify than unrelated changes.

2

Watch progress in the conversation

The progress card shows that the run is active. Keep the workspace open and avoid sending the same request again while it is still working. Screenshots captured during a Build or edit appear in the gallery as work progresses and remain visible after you reload the conversation.

3

Wait for verification

Mythos checks the candidate app before delivery. The current working Preview stays available until the new result is ready.

4

Inspect the delivered result

Use Preview on the result card to inspect the delivered version in the workspace. Test the visible behavior, links, forms, and responsive layout that matter to your request. Choose Preview from the assistant message’s More actions (…) menu to open the generated site in a new browser tab. Details is available on both the card and the menu. The menu also provides Copy response and shows recorded credit usage and measured duration when available.

5

Continue with a focused edit

Name the exact area and the outcome you want. The edit starts from the current project, so you do not need to restate everything that already works. Review your next request in the composer, then choose Send.

Write edits that are easy to verify

Prefer a bounded change:

In the featured beans section, add three roast cards with a tasting note
and price for each. Keep the existing palette and spacing.

Avoid requests such as “make everything better.” If several areas need work, group changes only when they serve one outcome, then inspect that outcome before moving on.

Describe what you see when something is broken: name the page, viewport, action, and visible failure. “The pricing cards overlap the footer on mobile” is more useful than “the layout is wrong.”

Questions and approvals during a Build

A Build can pause for a decision, a connection, or permission to act on a connected account. Read the card and check the account, destination, and proposed action before continuing. Answer a missing question in the conversation rather than starting the same request again.

For an external action with an uncertain result, check the connected service before asking Mythos to repeat it. See Connect your tools.

Delivered and failed results

  • Delivered: the result card appears, the new version becomes current, and Preview can load it.
  • Failed before delivery: the last delivered source remains current. A platform failure normally returns the reserved credits.
  • Paused at the credit limit: review the budget card and explicitly raise the limit to continue the same saved Build, or stop it. The last delivered Preview stays available.
  • Stopped after AI work begins: work already consumed is charged within the accepted limit, subject to the minimum; unused credits return. If delivery may already have started, billing can remain pending while Mythos reconciles the outcome.

If a request fails once, read the message, check the credit balance, and remove ambiguity or split an oversized task before trying again. Repeated failures belong in Troubleshooting, not an unchanged retry loop.

If a delivered edit is simply the wrong direction, open Version history, preview the earlier result, and revert to it before continuing.

When to use Plan instead

Choose Plan mode when the request has unresolved product decisions, multiple possible flows, or important data requirements. Plan keeps the conversation read-only until you approve an editable draft. Choose Build when the outcome is already clear.

Continue from here