What would you like to build?

Describe your app in your own words. Start with an idea alone, or add optional context and a GitHub publication target before the automated run begins.

Your app idea

Advanced settings

Workflow behavior

Choose how Giddyapp handles clarification, code-generation instructions, right-sizing, and file errors.

Focus clarification on app featuresWhen on, ask AI to avoid technical and non-functional questions. Do not generate code solely to test other codeWhen on, AI focuses on code needed to deliver requested capabilities. Override the default Flex service tierWhen off, Giddyapp requests Flex for AI requests. Automatically right-size files after completed runsWhen on, Giddyapp attempts to split eligible oversized JavaScript and PHP files after successful initial and resolution runs. This best-effort work does not block the main workflow. Pause the workflow when a file failsWhen off, Giddyapp uses the configured retries, records an unsuccessful file, and continues when safe. Explicit Pause and Stop remain available.

Technology stack

Choose the kind of app Giddyapp should build. The selected stack guides planning; it does not deploy the app.

Clarifying questions Number of functional questions to request. Optional maximum review/resolution cycles Leave blank for no maximum.

Automatic retry limits

Set the maximum number of additional attempts after the initial AI request. Set a value to 0 to disable automatic retries for that failure category. Retries are only made when the failure is classified as eligible.

Processed response or unreadable response Default: 5 additional attempts. Confirmed transient, unprocessed failure Default: 5 additional attempts. Flex-capacity rejection Default: 20 additional attempts. Explicitly classified unknown-cost transient Default: 5 additional attempts.

File-size planning and right-sizing

Planning targets guide architecture and manifest planning; they do not reject completed files or prevent publication. Right-sizing is a separate, best-effort follow-up for eligible files.

New-file planning target (KB) Default: 5 KB. Existing-file planning target when modification is needed (KB) Default: 15 KB. Do not change an existing file solely because it exceeds this target. Automatic right-sizing threshold (KB) Files larger than this measured size are considered for best-effort right-sizing after a completed run. Default: 15 KB. Reject replacement files smaller in both bytes and linesOff by default. When enabled, the existing smaller-replacement safeguard applies unless the individual manifest entry explicitly allows a smaller file.

Automatic baseline and prompt-cache refresh

Giddyapp estimates the stable baseline-prefix and dynamic-suffix sizes from UTF-8 content bytes (about 4 bytes per estimated token; this is not provider tokenization). The cached-input target percentage compares the baseline prefix only with suffix content that a baseline rebuild can absorb, such as accepted post-baseline file versions. Task instructions and other content that remains dynamic after a rebuild do not count toward the percentage or suffix minimum and do not, by themselves, trigger a refresh. When automatic refresh is enabled, both the prefix share must be below the target and the accumulated absorbable suffix estimate must reach the minimum before Giddyapp rebuilds the baseline ahead of a later request. Provider-reported cached and cache-write tokens are separate telemetry; they do not drive this local refresh decision, and a rebuild does not guarantee provider-side cache reuse.

Automatically refresh the baseline during a runWhen on, refresh when the estimated baseline share of absorbable content is below the target and accumulated absorbable suffix content reaches the minimum. Target baseline-prefix share (%) Default: 90%. This is an approximate local composition target, not provider-reported cache efficiency or a cache-hit guarantee. Minimum accumulated absorbable suffix estimate (tokens) Default: 32,768 estimated tokens. Only changing context a baseline rebuild can incorporate counts toward this minimum; task instructions and other persistent dynamic content do not.

GitHub connection

GitHub is optional. Add or select a key to check access and choose a repository and branch.

GitHub key Add a GitHub key in Keybox to test access and load repository choices. A key is optional.

Publication destination

Files that pass acceptance checks are published sequentially to this target during the run. GitHub publication does not deploy a live application.

Repository Repositories are loaded using the selected GitHub key. Publication branch Branches are loaded for the selected repository. Parent path Leave blank to publish manifest paths from the repository root.

Create a publication branch

Choose a base branch from the selected repository, then enter a name for the new branch.

Base branch New branch name

Credentials for apps built with Giddyapp

App-use permission is separate from using a key for Giddyapp itself and is off by default. Publishing selected secrets commits them to the configured GitHub repository; a private repository is not a secrets vault, and secrets may remain in its history, clones, or copies. Giddyapp will never send these app credentials to AI.

AI requests send relevant content and your provider key through api.maxflex.ai to the selected AI provider. Review the project and provider data-handling terms before continuing. GitHub files are published to the configured target after validation; GitHub publication is not live deployment.