Skip to main content
Here are the answers to the most frequently asked questions about AutoCoder.cc. For more detailed guides and step-by-step tutorials, please explore the Features section in the left navigation menu. If you still cannot find what you are looking for, feel free to contact our support team at support@autocoder.cc.

General and onboarding

Yes. AutoCoder.cc is specially built for users without programming or technical expertise. Just describe your requirements in natural language, and the platform will automatically generate complete full-stack applications, including the user interface, backend logic, and databases.
AutoCoder.cc is a cloud-based web tool that requires no local installation. For an optimal building experience, we recommend using a desktop browser on Windows, macOS, or Linux. You may also use tablets or smartphones for lightweight editing and quick adjustments.
Absolutely. AutoCoder.cc supports multilingual input. You can describe your project needs or chat with the AI in your preferred language, and the system will accurately understand and fulfill your requests.
This may be caused by network instability or high AI computing load. You can try refreshing the page or regenerating the project. If the problem persists, please contact our support team at support@autocoder.cc with your registered email and a screenshot of the error.

Building and editing

You can refine it in two ways:
  1. Chat Modification: Use natural language to tell the AI to add pages or adjust the structure.
  2. Visual Editor: Click the Edit button to enter editing mode, where you can directly edit text, replace images, or adjust colors on the page.
For more details, refer to the Build guide.
Yes. AutoCoder.cc supports version rollback. Every save will be recorded in Version History, allowing you to revert your project to any earlier version at any time.
Currently not supported. The platform only supports one‑way code export: you can download cloud‑generated code to your local device, but you cannot import manually modified local code back into the platform.

Deployment and hosting

Yes. All users, including Free plan users, will automatically receive an *.autocoder.cc Subdomain for public access when publishing a project.
After upgrading to the Standard or Pro plan, select Custom Domain in the publish dialog, enter your domain name, and configure a CNAME record pointing to AutoCoder.cc through your domain registrar. Once DNS verification is complete, upload your SSL certificate to finish the setup.For more details, refer to the Deploy and Hosting guide.
No. Unpublishing only disables public access to your project. All project drafts and data are securely stored in the In Progress tab of your Workspace.For more details, refer to the Workspace guide.
Currently, direct publishing to app stores is not supported. The platform only generates and allows you to download Android APK packages for local installation and testing. You will need to independently handle iOS .ipa package generation, as well as all compliance review and submission processes for official release on app stores.

Billing, credits and refunds

If you have any questions regarding this section, please contact support@autocoder.cc!
Plan Comparison
  • Free: Ideal for exploring AutoCoder and building lightweight prototypes. Includes static single-page demos, backend project support, basic storage, unlimited private projects, and unlimited edits.
  • Standard: Designed for creators building complete, production-ready applications. Includes a standard credit allowance, custom domain support, enhanced storage and performance, full multi-page projects, login and payment integrations, dedicated customer support, role switching, and project downloads.
  • Pro: Built for professional teams and advanced full-stack development. Includes a higher credit allowance, unlimited full-stack projects, expanded domain capabilities, premium features, priority support, domain purchasing, unlimited subdomains, project downloads, and exclusive credit top-up offers.
Tip: You can earn extra free credits by completing missions in the top right corner. For more details, refer to the Earn credits guide.
No. Plan credits are valid for one calendar month from the date of purchase. Unused credits will expire at the end of each billing cycle to support sustainable platform operation and encourage consistent creation. To keep using credits, you may renew or purchase your desired plan again.
After upgrading, the system will use credits from your new plan first. Once your new plan credits are used up, you may continue to apply any remaining valid credits from your previous plan, provided they are still within their 30‑day validity period.
The platform applies the following refund and compensation policy:
  1. Refunds: Full or partial refunds are available only if you purchased directly through AutoCoder.cc, submitted your request within 7 days of purchase, and have not used any credits or paid services. Used services and credits are not eligible for monetary refunds.
  2. Credit compensation: If project generation fails entirely due to system bugs or platform errors, monetary refunds will not be issued. However, you may contact support@autocoder.cc with error screenshots and usage details. After verification, we will fully refund the credits consumed due to the error.
Our platform currently operates on a “one-time payment (monthly quota)” model. There is no auto‑renewal function, so no recurring charges will be made without your authorization. You do not need to manually cancel any subscription.

Source code export and ownership

The exported package contains a complete full‑stack project (including frontend, backend, and database schema files) for both web and app applications. The code features a clean, standardized structure and includes all required environmental configurations. Simply follow the included README.md instructions and run npm install to get your project running locally in minutes.
Projects are currently exported as a ZIP file, which you can manually upload to your GitHub repository. Native one‑click GitHub synchronization is under active development and will be available soon.

Data privacy and security

No. We fully respect your privacy and allow you to delete your account directly in account settings. Please be aware that account deletion is immediate and irreversible. All your projects, remaining credits, and related data will be permanently deleted and cannot be restored.For more details, refer to the Profile guide.
Please follow these troubleshooting steps:
  1. Double-check that your email is entered correctly and that Caps Lock is disabled.
  2. Ensure you have a stable network connection. You may also try clearing your browser cache or using a different browser.
  3. If the issue persists, send your registered email address and a screenshot of the error page to support@autocoder.cc, and we will assist you promptly.
AutoCoder.cc strictly adheres to applicable data privacy laws and regulations. All your data is stored and protected securely under our Security and Privacy Policy.

Progressive Build

Progressive Build splits project generation into three visible and editable stages: Draft, Requirements, and Full Project. You do not need to wait for the full build before you can confirm direction, review requirements, and fix issues before the final build.
Draft stage preview

Draft stage: editable styles, layouts, and visual drafts.

Requirements stage preview

Requirements stage: pages, user flows, business logic, and system architecture.

Full Project generating

Full Project stage: the build runs through the front end, back end, database, and API.

Completed project preview

Completed project, ready for end-to-end testing along the real user path.

The most effective modification sequence: handle visuals and layout in the Draft stage, confirm functions and rules in the Requirements stage, and test real business processes after the Full Project is completed. Do not overturn the completed core structure in the final stage.
Frequently asked questions
It may currently still be in the Draft stage. In the Draft stage, styling, layout, and content are prioritized, while capabilities such as login, data persistence, permissions, APIs, and database are developed in the Full Project stage. Check the current stage displayed at the top first, then judge whether the function should be available yet.
Yes. Once the Draft is generated, you can modify the page or supplement requirements via conversation. We recommend completing style and layout adjustments during the Draft stage. When modifying roles, processes, and business rules, check synchronously whether the Requirements have been updated.
The Draft is already an integral part of the project, not an independent preview that is discarded once the build completes. The layout, styles, and content confirmed in the Draft are carried over to subsequent builds.
Editing the Draft directly in the project
Treat the Requirements as the project blueprint for inspection. The key points to confirm are whether all pages are complete, whether role permissions are correct, whether core processes are intact, and whether data ownership and business rules are clear. Supplement any identified omissions as early as possible, before the Full Project is completed.
The reference durations of approximately 2, 5, and 15 minutes are not fixed completion times. The more complex the page count, user personas, database structure, and business logic, the longer the actual construction time. As long as the stage, status text, or construction node is still changing, the task is usually still in progress.
The Full Project incorporates real data, form validation, login status, error prompts, permissions, and administration entries, so some pages may require further adjustment. Under normal circumstances, the confirmed core layout, visual direction, and content are retained.
Example:When changing the “direct user booking” setting to “submit booking after payment and subject to administrator review”, you also need to check the payment status, booking status, administrator review entry, database fields, and notification logic.
Troubleshooting
This may show up as a color scheme reverting, deleted blocks reappearing, or copy not being retained. First, confirm that you are viewing the latest version of the Full Project. Then check whether instructions that overwrite the original modifications (such as “redesign the homepage”) were sent in later conversations. Organize the missing modifications into a single clear instruction and resubmit it. If the issue still cannot be resolved, submit it through the Feedback entry.
If the Full Project is shown as completed but operations such as login, submission, saving, permission configuration, or database operations still fail, this is no longer the normal incomplete state of the Draft stage. Test following the complete path (login → create data → submit → refresh and recheck), identify which category the issue falls into among page display, form submission, data saving, or permissions, and record the specific error prompt. Provide the project link, operation steps, and screenshots when giving feedback.
Adding payment, approval, multi‑role, inventory, or complex status‑transition functions is not a simple page modification — it simultaneously affects pages, APIs, databases, permissions, and the management backend. Do not split a single structural modification into multiple independent instructions. Instead, clearly specify the pages, processes, fields, and permissions that require synchronous updates within one instruction, then test the entire business link after completion.
Permission errors may not trigger obvious error prompts, but they can lead to regular users accessing admin pages and to cross‑role data exposure. Test separately as an unauthenticated user, a regular user, a staff member, and an administrator. When issues are detected, clearly specify the accessible pages, allowed operations, and data scope for each role, and synchronously update the front‑end entries, back‑end validation, and database query ranges.
First, distinguish between “slow processing for a complex project” and “a truly stalled build”. If the stage name, status text, or nodes are still changing, keep waiting. After confirming that all statuses remain unchanged for an extended period, record the current stage to avoid repeatedly submitting the same build instruction, then re‑enter the project to check the status. If there is still no change, save the project link, current stage, time stayed, and screenshots, and submit them via the Feedback entry.
Continue modifying, or repurpose and rebuild?
When submitting an issue, we recommend providing the following: project name or link, current stage and version, the page where the issue occurs and the user persona, and the complete steps to reproduce the issue.

Google Login and Payments

First, keep this in mind: payments in the preview environment are test transactions and will not result in actual charges. Before receiving real payments, you must complete payment‑platform verification and use the keys for the Live environment.
Core features
  • Google Sign‑In: add the “Sign in with Google” login entry to your project.
  • Payment integration: add a payment process for products, services, subscriptions, or reservation deposits.
  • Test / Live environments: verify login and payment flows in Test, then review production activity in Live.
  • Analytics: view Google Sign‑In activity and payment order data, with separate Test and Live views.
Some screenshots are for functional prototype reference only. Final button names and page positions may be adjusted with version updates.

Google Sign‑In

Enter Add Google Sign‑In in the project conversation. AutoCoder uses platform‑managed OAuth credentials by default, so no Google Cloud configuration is required. If you want to manage OAuth through your own Google Cloud project, select Your own credentials and provide your Client ID and Client Secret.
Adding Google Sign-In to a project through the chat
No. AutoCoder uses platform‑managed OAuth credentials by default, so you can enable and test Google Sign‑In without applying for your own Client ID or Client Secret.Only select Your own credentials if you want to manage OAuth through your own Google Cloud project. In that case, enter your Client ID and Client Secret, and use the Redirect URL provided by AutoCoder.
The error usually appears as redirect_uri_mismatch.
  1. Confirm that Google Sign‑In is enabled and that the latest configuration has been saved.
  2. Refresh the preview or republish the latest project version, then test again.
  3. If you selected Your own credentials, verify that:
    • The Authorized Redirect URI in Google Cloud exactly matches the Redirect URL provided by AutoCoder, including the protocol, domain, path, and trailing slash.
    • The Client ID and Client Secret belong to the same Google Cloud project.
    • Any custom domain has been added to the OAuth consent screen’s authorized domains, and the corresponding Redirect URI has been added to the OAuth client’s Authorized redirect URIs.
  4. If the issue persists, submit it through the Feedback entry and include the project link, current access URL, exact error message, reproduction steps, and screenshots.

Payments

Payment integration is a paid feature. Free users will see an upgrade prompt when they try to add payments. After upgrading, return to the project and restart the payment setup.
Upgrade prompt shown when a Free user adds payments
Enter Add payment functionality in the project chat. AutoCoder will guide you through the setup, including selecting your country or region, choosing a supported payment provider, and confirming the products or services being sold, pricing, currency, and payment type.After the required information is confirmed, AutoCoder configures the payment flow, order structure, and test environment. If pricing or other business rules are still incomplete, the final checkout flow will not be enabled until those details are provided.
Adding payment support through the project chat
No. When the message “All payments in preview are in test mode” appears at the top of the preview page, you are in the test environment. Test transactions are only used to verify payment, redirection, and result pages, and are not credited to the official merchant balance.
Test-mode banner at the top of the preview
  1. Enable payment in the Payment settings, and fill in the official API key provided by the payment platform.
  2. Release the project and proceed to the Go live process.
  3. Complete the account profile setup, merchant verification, and automatic review for the payment platform.
  4. Switch to the Live environment and conduct a complete test with a small‑value real transaction.
Payment settings with the live API key field
Signing in to the payment provider dashboard to retrieve the key
  • Confirm that the configured key is a production payment key, not a test or sandbox key.
  • Check that the complete key was copied, without extra spaces or line breaks.
  • Confirm that the payment‑provider account has completed verification and can receive payments.
  • Check that the amount, currency, and payment method are supported in the merchant’s region.
  • Save the key and republish the latest project version.

Analytics

Go to Workspace and select Publish from the left‑hand menu. Open the published project you want to review, click the three‑dot menu in the upper‑right corner of the project details page, and select Analytics.
Opening Analytics from the published project menu
Analytics shows Google Sign‑In and payment data for the selected project.
  • Google Sign‑In includes active users for today, the past 7 days, and the past 30 days, plus daily active‑user trends.
  • Payment includes the Transaction ID, amount, currency, Buyer ID, status, order creation time, and payment time when available.
Select Revenue Details for more information. For settlement, fees, refunds, and disputes, check the payment provider’s dashboard.
Analytics showing Google Sign-In and payment data
Use the Test and Live tabs at the top of the Analytics page to switch between environments.
  • Test displays Google Sign‑In activity and payment records generated while testing the project. Test payments do not create real charges.
  • Live displays activity from the published production environment and real payment transactions.
Test and Live data are stored separately. A test transaction will not appear under Live, and a live transaction will not appear under Test. To retrieve live payment records, the project must be published and valid live payment credentials must be configured.
Test and Live tabs in Analytics
Check the following:
  1. Confirm that you opened Analytics for the correct published project.
  2. Check whether you are viewing Test or Live. Activity generated in one environment will not appear in the other.
  3. Verify that the selected date range includes the date when the login or payment occurred.
  4. Confirm that Google Sign‑In or Payment has been added to the project. A section may be absent when the corresponding feature has not been integrated.
  5. Complete at least one login or payment flow in the environment you are viewing.
  6. For Live payment data, confirm that valid live payment credentials have been configured. If Analytics reports that payment keys are not configured, live orders cannot be retrieved.
  7. Check the payment provider’s dashboard to confirm whether the transaction was successfully created.
If the payment provider shows a successful transaction but Analytics does not display it, submit the issue through Feedback and include the project link, selected environment, Transaction ID, payment time, user account, and screenshots.

Difficult issues

AutoCoder uses platform‑managed OAuth by default. If Google Sign‑In shows a blank page, a redirect loop, or redirect_uri_mismatch, confirm that Google Sign‑In is enabled and republish the latest version.If using Your own credentials, ensure the Authorized Redirect URI exactly matches AutoCoder’s Redirect URL.If the issue continues, submit Feedback with the project link, current URL, full error message, reproduction steps, and screenshots.
The Test environment uses AutoCoder’s test configuration and requires no user‑provided key. For Live payments, verify that the key:
  • Is a production key.
  • Was copied completely, without extra spaces.
  • Has been saved before republishing.
  • Belongs to the project’s payment account.
Live payments require identity, business, bank‑account, and merchant verification by the payment provider. Complete any pending verification or account restrictions in the provider’s dashboard before testing.
Confirm the transaction succeeded in the payment provider’s dashboard. Then verify the correct project, environment, and date range in Analytics.If the order status or Analytics data is still missing, submit Feedback with the Transaction ID, payment time, user account, project link, and screenshots.
Remixed projects retain payment code but not payment activation or Live credentials, so the copied flow may work only in the Test environment. To enable Live payments, reconnect the payment feature, add a production key, republish, and retest the full flow.
Quick troubleshooting tips: for Google Sign‑In, check the OAuth configuration. For Live payments, verify the production key and provider account status. For missing data, confirm the project, environment, and date range.

Google Maps Website Generator

Turn a Google Maps business listing into an editable local‑business website. Paste a business Share link, review the available information, and generate the website. Core features
  • Dedicated entry: open the generator from the Solutions section in the AutoCoder homepage footer.
  • Google Maps import: paste a specific business Share link to retrieve available business details, images, and reviews.
  • Business preview: review the imported listing before starting website generation.
  • One‑click generation: select Generate Website to create an editable business website.
Scroll to the bottom of the AutoCoder homepage. Under Solutions, select Google Maps Generator. You can also open the generator directly from the link above.
Google Maps Generator entry in the footer

Google Maps Generator entry in the AutoCoder homepage footer.

  1. Open the Google Maps Website Generator.
  2. Paste the Share link for a specific Google Maps business listing.
  3. Submit the link and review the imported business preview.
  4. Select Generate Website to create the project.
The Google Maps Website Generator input page

Paste the Google Maps business Share link into the generator.

The preview may include the business name, address, rating, review count, categories, phone number, website, images, opening hours, and customer reviews, depending on what is available in Google Maps.Review the preview and confirm that it shows the correct business before selecting Generate Website.
Business information preview with the Generate Website button

Business-information preview before website generation.

No. AutoCoder automatically creates the website‑generation input from the submitted business link. After the project is generated, you can edit its copy, images, layout, and business information.
Yes. However, a complete business profile with more useful images, details, and reviews gives AutoCoder more source material. Review and update the generated content before publishing.
Troubleshooting
Close the preview, return to Google Maps, open the correct business listing, and copy a new Share link.
AutoCoder can only use information available from the submitted listing. Generate the website, then add or correct the missing content in the project.

Images, files and voice input

Image and file upload is available in website update workflows: light‑line and heavy‑line are supported, and a requirement‑list workflow can use a function‑interaction flowchart to revise matching requirement entries. Image and file upload is not available in the manual‑edit AI panel. Voice input applies to website generation and update workflows — including light‑line, requirement‑list, and heavy‑line — and to manual‑edit AI workflows. Voice is transcribed into editable text before submission.
Core features Some screenshots are functional prototypes. Button names, labels, and positions may change in later versions.

Uploading images and files

Use the file icon in the project input box during a supported website update workflow. After selection, attachments appear in a row above the input area before the request is submitted.Light‑line and heavy‑line update workflows support image and file upload. A requirement‑list workflow can also use a function‑interaction flowchart to revise matching requirement entries. Image and file upload is not currently available in the manual‑edit AI panel.
The file-upload entry in the project input box

Prototype reference: file-upload entry in the update input area.

  • Click the file icon and choose one or more files.
  • Drag files into the upload area.
  • Paste copied files into the conversation. This interaction is supported in the current test environment and may depend on the released browser and version.
Multiple files can upload in parallel up to the configured attachment limit. After upload, thumbnails or file cards are displayed in a horizontal row; the row can scroll when there are many attachments.
  • Images: JPG, JPEG, PNG, SVG, GIF, and WEBP.
  • Common documents and data: DOC, DOCX, XLS, XLSX, PPT, PPTX, PDF, TXT, MD, CSV, and JSON.
  • HTML and ZIP are accepted upload formats within their stated limits. HTML is sanitized before text or screenshots are extracted; it is not executed or treated as implementation source code. ZIP support is subject to both the archive‑size limit and the internal‑file‑count limit.
For reliable content updates, use common documents, spreadsheets, PDFs, text files, CSV, or JSON. Macro‑enabled Office files (DOCM, XLSM, and PPTM), executable files, engineering source files, and Figma design files are not supported for direct understanding. Figma and GitHub URLs are not read directly — export a screenshot, diagram, PDF, content table, or written requirement instead.
  • Maximum attachments per submission: 10. A bare URL pasted into the instruction does not count as an attachment by default.
  • JPG, JPEG, PNG, GIF, and WEBP: up to 50 MB per image.
  • SVG: up to 5 MB per file.
  • HTML: up to 5 MB. JavaScript, external links, and cookies are disabled before text or screenshots are extracted.
  • TXT, MD, CSV, and JSON: up to 5 MB per file. PDF, DOCX, XLSX, and PPTX: up to 25 MB per file.
  • Legacy DOC, XLS, and PPT: up to 25 MB per file. They are converted to a newer Office format or PDF first, and conversion may fail.
  • ZIP: up to 25 MB, with no more than 10 files inside. DOCM, XLSM, PPTM, EXE, and other executable files are not supported. Figma and GitHub URLs are not read directly in the current update flow.
Yes. You can submit attachments without a text instruction. If AutoCoder cannot identify a clear update action from the material, it will ask a follow‑up question about the material’s purpose and the required change.For better results, add a short instruction such as “replace the homepage banner with this image,” “use this screenshot as the visual‑style reference,” or “update the Services page copy using this PDF.”
Uploaded images can be opened in a centered preview. Uploaded files are displayed as file cards and cannot currently be previewed; selecting a file shows that preview is not supported. To remove an attachment, use the delete control in the attachment’s upper‑right corner before sending.
Several uploaded attachments shown above the input area

Prototype reference: multiple uploaded attachments displayed above the input area.

Common causes include a file exceeding the size limit, network instability, an incompatible format, corrupted file content, or exceeding the maximum attachment count. The upload error appears in the lower‑right corner, disappears after approximately 10 seconds, and can also be dismissed manually.Reduce the file size, upload fewer files at once, split a large document, verify the format, or retry on a stable network.
An upload-failure notification in the lower-right corner

Prototype reference: upload-failure notification.

Unsubmitted attachments are temporary. Depending on the page, refreshing or closing the tab may clear them. Keep the original files locally and do not use the upload area as storage.

Image-based updates

Images can replace static or data‑driven website assets, banners, backgrounds, product images, and logos. They can also guide visual style, page layout, prototypes, or an exact annotated area that needs to change. Interaction‑flow, permission, data‑flow, and architecture reconstruction applies to the heavy‑line workflow, with the separate requirement‑list flowchart case described below.State the image’s role. A product photo, screenshot, logo, wireframe, annotated screenshot, flowchart, and architecture diagram each require different handling.
Yes. Upload the replacement and identify the exact page and target area — for example, the homepage hero image, a product‑card image, the site logo, or a database‑backed image. If the position is unclear, AutoCoder will ask for clarification.Only the specified asset should change. Unrelated layout, copy, images, and data should remain unchanged. For a database‑backed image, AutoCoder must also update the associated fields needed to keep the record consistent, such as the image name, description, or business copy.
Yes. A reference image can guide color, typography, spacing, visual density, effects, component styling, and overall design direction. Specify whether the reference applies to one page or the whole site.Only the requested visual characteristics should be applied. Unrelated content, business logic, data fields, and functionality should remain unchanged.
A website screenshot used as a style reference

Example: a website screenshot used as a visual-style or layout reference.

Yes. These materials can guide section order, module structure, column proportions, information hierarchy, and the component placement shown in the reference. Label important blocks, especially in hand‑drawn or low‑fidelity references. If proportions, positions, or relationships are ambiguous, AutoCoder will ask for clarification.A direct “make this page look like the target image” request may affect UI, interaction, and data. AutoCoder prioritizes the UI layer first, then interaction and data where applicable, while preserving existing core flows as far as possible. Business logic is reproduced only where its user‑visible effect requires it; API‑layer replication is not included in this release.
Yes. In the heavy‑line/advanced update workflow, AutoCoder can reconstruct interaction flows, business processes, role permissions, data flow, and system architecture. In a requirement‑list workflow, a function‑interaction flowchart can be used to revise the matching requirement‑list entries, but that action updates the requirements rather than directly implementing the interaction or architecture.Heavy‑line changes can affect pages, navigation, branching logic, permissions, data transmission, and storage behavior. After completion, test the complete process — including branches, role access, data flow, and unaffected existing functions — not only the page appearance.
A flowchart describing interaction and business-process logic

Example: a flowchart used to describe interaction or business-process logic.

Yes. Add arrows, boxes, circles, or text notes to a screenshot and upload it with a short instruction. Annotation recognition supports multilingual text. The change should be limited to the marked component, while unmarked UI, layout, interaction, and data remain unchanged.When annotations are small, overlapping, or ambiguous, repeat the same instruction in the text prompt and name the page and component.
An annotated screenshot marking the exact area to change

Prototype reference: an annotated screenshot identifying the exact area to update.

The attachment did not contain a clear action. AutoCoder may not know whether an image should replace an asset, guide the style, reproduce the layout, modify interaction logic, or describe a business process, or whether a file should be used in full, by selected section, table, record, or field. Answer with the target page, target element or data, intended result, and scope.

File-based updates

Common documents can add or replace website copy, service descriptions, company information, product details, and other text‑based page content. The selected content should retain its heading and paragraph hierarchy while adapting to the website layout.For a long document, state whether to use the full file, selected sections, or a specific table. Unselected content and unrelated pages should remain unchanged.
Yes, when the target relationship is clear. These files can update text fields, content records, titles, notes, descriptions, detail fields, and other structured business data. Only the specified records and fields should be changed.After the update, verify both the backend data and the front‑end display. The same business item should be consistent across the project.
Figma design files, engineering source files, macro‑enabled Office files (DOCM, XLSM, and PPTM), and executable files are not supported for direct understanding in the current update flow. HTML is a special accepted format: it is sanitized, then used only for text or screenshot extraction rather than executed as source code. ZIP files can be uploaded only within the stated archive‑size and internal‑file‑count limits.Figma and GitHub URLs are not read directly. Export the relevant design as a screenshot or PDF, or export requirements and data as DOCX, TXT, MD, CSV, or JSON before uploading. For legacy DOC, XLS, or PPT files, using DOCX, XLSX, PPTX, or PDF is more reliable because conversion may fail.

Voice input

Voice input is available in full‑site generation and update workflows — including light‑line, requirement‑list, and heavy‑line paths — and in supported manual‑edit AI workflows. Use the microphone control to start recording. Speech is transcribed in real time and inserted into the input box for review before submission.
The voice-recording state in the input box

Prototype reference: voice-recording state during an update task.

Voice input is intended to support all languages, with priority support for Chinese, English, Spanish, and Arabic. Real‑time streaming recognition supports continuous and intermittent speech. Review the transcript before sending, especially when the instruction mixes languages.Check names, URLs, numbers, prices, product names, brand terms, page names, and field labels carefully, because recognition errors in these details can change the result.
  • Maximum duration per recording: 1 minute.
  • Free users: up to 100 recording starts per day.
  • Paid users: no daily start‑count limit.
  • If a recording exceeds the maximum duration, it is automatically truncated and a message explains that the effective content was retained.
For a longer requirement, split it into several short instructions and submit them in order.
  • Permission denied: enable microphone permission in the browser and try again.
  • No voice detected: after about 5 seconds without audio, the system prompts you to speak again.
  • Recognition failed because of network instability or timeout: retry or use text input.
  • Transcript incomplete or inaccurate: edit the text in the input box before submitting.

Pausing tasks

Yes. While a generation or update task is running, the send button changes to a pause control. When the task finishes, fails, or is manually paused, the control immediately returns to the normal send state.
  • Generation pause: all further output and resource processing stop. The current stage is shown as failed/interrupted, and the task can be regenerated. The paused request can still be referenced as conversation context.
  • Update pause: the current update stops, the cancelled request remains in the conversation, and the preview keeps the most recent available version. The system may display “this message is cancelled.” The paused request can still be referenced later.
Troubleshooting
Confirm that the attachment finished uploading before the request was sent, and that the prompt explained how to use it. For an image, state whether it is a replacement asset, style reference, layout reference, prototype, flowchart, or annotation. For a document, identify the full file, selected section, or table to use.
The target was probably ambiguous. Provide the page name, section name, component name, and visual location, or upload an annotated screenshot. For a database‑driven image, verify that the image and its associated fields were updated consistently.
Define the scope and the elements to reproduce: color system, font hierarchy, spacing, visual density, effects, component style, module order, column proportions, or the entire page layout. For a whole‑site update, check several pages; for a single‑page update, confirm that other pages were not altered.
Specify the exact section, table, records, or fields to use. Long files require a clearer extraction target. If the update affects structured data, verify the backend values and front‑end rendering together.
Edit the transcript before submitting, especially page names, numbers, prices, product names, brand terms, URLs, and field labels. If recognition repeatedly fails, use text input or split the requirement into shorter recordings.
That is expected. Pausing stops the unfinished update and keeps the most recent completed version in the preview. To continue the update, submit a new instruction. Regeneration applies to a paused generation task, not to the cancelled update task.
Quick troubleshooting checklistUpload issue: check size, count, format, file integrity, and network. Long screenshots may be split into six segments; ZIP files may contain no more than 10 files. Image update: define the image’s role and exact target. File update: specify full‑file or selected‑section use. Voice input: review and edit the transcript before submitting.