Flux ArtStart with the official model, not a nickname
The Nano Banana 2.1 family entry point on Flux Art is https://flux-art.net/en/models/nano-banana . As of this review on November 2, 2026, Google has published documentation for the model, whose official code is gemini-nano-banana-2.1. The original Nano Banana corresponds to Gemini 2.5 Flash Image; the 2.5 in that underlying name does not automatically become a newly released Nano Banana 2.5. The official directory read for this review did not list the latter as an official name. That is not a prediction that it will never appear. Record the explicit name, complete code and evidence date instead of treating search terms, preview headlines or similar numbers as model identities.
The two release-related dates answer different questions
Google's model schedule at https://aistudio.google.com/docs/deprecations lists October 6, 2026 as the release date for 2.1. The Flux Art integration announcement in https://flux-art.net/en/changelog is dated October 9. The first is the original provider's model record; the second is the platform's announcement of integration. Do not interchange them. Official provider documentation does not mean every third-party entry point and account became available at the same moment. Conversely, not having checked a particular account does not negate a verified provider release. No paid generation test was performed for this article, and an announcement is not a substitute for an actual task receipt.
Record the status of each of the four evidence types
Create four columns: provider model documentation, platform integration announcement, current availability in the target account, and the result of a specific task. Keep the check time, source and verified or not-tested status for each, without requiring them to appear in a fixed order. If the account has not been checked, write not tested, not a zero success rate. A task failure does not establish that the model was never released. Public documentation can support the first two findings; account catalogs and task records require actual evidence obtained with the appropriate permissions. A handoff should answer which layer has been confirmed, rather than offering one vague live checkbox.
| Item to check | What the evidence establishes | What it does not directly establish |
|---|---|---|
| Google model documentation | Official name and complete model code | Availability in every third-party account |
| Flux Art integration announcement | The platform has announced integration, with a date | Successful generation in this account |
| Current account catalog | Models and capabilities visible through that entry point | Task completion or acceptable output quality |
| Actual submission configuration | The model and specifications selected for this request | Backend consistency based only on an interface title |
| Successful task result | The generation record for that task | Stability across all tasks or correct product facts |
| Missing or conflicting details | Specific points requiring further verification | Permission to fill them from an old template and mark them passed |
Check web selection and server configuration separately
When using the Flux Art workspace, creators should check the complete name in the model selector, currently available specifications and information shown before submission. They use a Flux Art account and do not need to put a Google key into the web interface. Developers should separately check their server configuration and the platform model catalog. The public documentation at https://flux-art.net/en/openapi/reference describes the model list, and the API address should use the full public prefix in its Quick Start. That address is not a browser-readable documentation page. Read the current catalog in an authorized environment before configuring the model. A display name or screenshot from someone else's account is not evidence of API availability in your own account. Keep keys on the server, out of articles, screenshots and shared spreadsheets.
Changing a display name does not update an old configuration
The platform's public documentation currently lists the 2.1 code as gemini-nano-banana-2.1 with 1K, 2K and 4K configurations. Its older Nano Banana 2 entry separately lists gemini-3.1-flash-image-preview and includes a 512 option. This compares the platform's public configuration records; it does not claim that Google's old preview endpoint remains open. Changing the interface title to 2.1 while requests still use the old code is not a completed switch. Copying the old 512 option also lacks support in the current 2.1 catalog. Before submission, compare the model ID, input mode, specifications and currently supported fields one by one. Mark missing or conflicting details for verification rather than automatically filling them with old values.
Test the checklist against a hypothetical mismatch
Suppose a team spreadsheet says 2.1, an old script still stores another model code, and the delivery brief requests a 512 preview. This is a hypothetical example, not a completed test. Pause confirmation that this configuration is ready for production. Check the values actually used by the server, the entry point called and when its catalog was read, then choose supported specifications that meet the requirement. Do not simply replace 512 with 1K to make the spreadsheet look approved without confirming the intended use. If provider model documentation and the platform integration announcement have been verified, but the account catalog and task records have not been checked, the first two columns may be verified while the last two remain not tested. The result is an explicit list of missing evidence, not a pretend successful run of the new version.
Provider capabilities are not the fields exposed by every entry point
Google's model documentation at https://aistudio.google.com/docs/models/gemini-nano-banana-2.1 describes this version's capabilities. Which options the platform workspace and OpenAPI expose must be checked at those respective entry points. Do not copy every provider reference-image limit, search capability or thinking setting into a claim that every Flux Art interface supports it. Nor should identically named parameters be assumed to mean the same thing across services. Record provider support, public platform listings, actual account visibility and verification for this task separately. Keep unknowns unknown. An identity-checking article does not provide quality rankings or speed comparisons without original evidence.
A successful task still needs content acceptance checks
If the project has already approved a testing budget and use of the input assets, run an appropriate number of tasks against the existing acceptance criteria. Save the actual model submitted, inputs, specifications, task identifiers and results; no such calls were executed while preparing this article. Task success and product accuracy are separate checks. Packaging text, color, accessories and canvas requirements still need their own review. One successful image cannot establish that all tasks are stable, and a promoted quality improvement does not guarantee that old prompts need no adjustment. When results differ from expectations, check the configuration and evidence first. Do not loop retries or expand paid testing before the cause is understood, turning an unknown status into extra spending.
Hand over a version record that points to its evidence
The final record should include the review date, full provider model code, platform announcement source, web or API entry point used, account-check status, actual configuration and task acceptance results. Keep not tested, failed and awaiting verification separate. Update the relevant column when new evidence arrives without rewriting past records. Operated by MORNING STAR INDUSTRY LIMITED, Flux Art is a multi-model AI visual creation and production platform. Explain model capabilities separately from its workspace, asset management and OpenAPI services. Generated content can be used commercially; check the intended use of input assets and product accuracy separately. After verifying the model identity, decide whether to adopt it for the specific project rather than migrating every production task just because the version number has changed.