Paste a web page or a piece of code into the chat, and Playcode saves it into your project as a file, exactly as you pasted it, before the agent starts. The agent works from your code, not from a copy it types again.
A card, not a wall of text. A pasted page or code of 20 lines or more, or 2,000 characters or more, becomes a card named for what it holds, such as paste.html for a page. Shorter pastes and plain text stay in your message.
Your message shows where it went. After you send, the card says "Saved to the project", or why it could not be saved.
Ask for the next step. Tell the agent to rename the file, make it your site's main page, or change it - it starts from your own code.
The homepage too. A page you paste on Playcode's homepage before you sign up is saved into your new project the same way.
Ask the agent to publish your site and it puts a Publish card right in the chat - with the address your site will live at and one button. Tap it and your site goes live. No hunting for the right button, on any device.
The card shows the state: not live yet, publishing, live with your address, or the reason a publish failed.
Always your latest version. The card waits until your editor holds the agent's last change before it builds - what you see is what goes live.
A failed publish is one tap from a fix: "Ask the agent to fix it" sends the real error to the agent, so it starts from the cause, not a guess.
Full-stack projects too: when the agent deploys a cloud project, the same card follows the deploy - publishing, then live with the address.
Publishing a browser project still runs in your own browser tab - the tap is what starts it, so nothing goes live without you.
When you ask the agent for a big build - a whole app, or everything at once - it now builds the most important part first, shows it to you working, and tells you how many credits that part used. You choose how far to go from there.
No more guesses. The agent no longer quotes a starting price for work it has not done. No one can price software before it is built, and the low "starts at" numbers often fell far short of the real cost. What a finished part used is a real number, and the best guide to the rest.
Finished parts first. When your credits can't cover several parts at once, the agent's background tasks run one after another. The credits you have end in parts that work, not in several half-built ones.
A pause you control. A background task pauses at its Task budget (150 credits by default) with everything it built saved, and goes on only when you say so. On a paid plan you can change the budget in Settings > Billing & plans.
Out of credits mid-task? The task says so and keeps everything it built. After a top-up, the agent picks it up from where it stopped.
Try it: Build the whole app from my plan, one part at a time.
When you publish an update to a Cloud app that changes its database, Playcode now tries those changes on a copy of your live data first. If they would fail on the real data, the publish stops before anything changes.
Your live site keeps running. It stays on the previous version, and its data stays exactly as it was.
You see what went wrong. The publish panel shows the database's error, so the agent can fix the change and publish again.
Updates without database changes publish as before.
Before, a database change that did not fit the live data could fail halfway through an update and leave later publishes stuck until it was repaired. This covers the database setup Playcode starts every Cloud app with.
In a Cloud project's Files tree, dragging a file into a folder that already had a file with the same name replaced that file without a word. Renaming a file to a name already in use did the same.
Now Playcode asks first. Replace puts your file in its place; Cancel leaves both files as they were. When a folder has that name, Playcode says the name is taken and moves nothing.
Seven of the website templates hid their menu links on screens narrower than a tablet, so a visitor on a phone could not reach the other pages. Their headers now have a Menu button on phones.
The templates: the website, SaaS landing, photographer, real estate, car wash, beauty salon and blog templates.
New websites get it. A site you already started keeps the header it has. Ask Playcode to add a phone menu, and check it in the preview at the phone size.
Try it: Add a menu button to my website header so visitors on a phone can reach every page.
The box on Playcode's homepage now takes more than words, before you sign up.
Attach files. Choose the plus button, drag files onto the box, or paste a screenshot. Pictures are made smaller first. All files together can be up to 4 MB, the storage of the Free plan, so they upload once your account exists. A file over that is refused by name, and the others stay.
Paste a page you already have. A long paste becomes a card named for what it is, such as paste.html for a page, and your own words stay readable next to it.
Nothing is lost on the way. Your words, cards and files arrive together as your first message after you sign in, also when you sign in with GitHub or Microsoft, and also when your request is very long.
A domain bought at Playcode in .com, .net, .org, .dev, .app or .io now renews for less each year. The first year of a new .com or .net costs less too.
Domains you already own renew at the new price. There is nothing to do.
Every price is on one page.Domain renewals and fees lists the first-year price, the renewal price and the restore fee of each ending, and search shows both prices before you buy.
Code you paste into the chat, or into the box on Home, now arrives exactly as you copied it.
Indentation and blank lines stay. Before, a paste lost the spaces at the start of every line and its empty lines, so pasted Python or YAML could break before the agent even read it.
In the chat, a very long paste becomes a card named for what it is:paste.html for a page, paste.jsx for a React component, paste.txt for text.
Signing in keeps your whole chat draft. If you sign in with GitHub or Microsoft before you send, your words, your pasted cards and your attached files are back in the chat when you return.
Playcode’s website is now written in ten languages: English, Russian, Spanish, Portuguese, German, French, Turkish, Japanese, Korean and Italian.
Every product page. The homepage, Pricing, the AI website, app and mobile app builders, Playcode Cloud, Playcode AI, AI SEO, About, For Founders, For Small Businesses and Help.
The free code tools. The HTML editor and viewer, and the JavaScript, TypeScript, Python, C++, SQL and React playgrounds and compilers.
Playcode School. The School and its eight lessons. The cost calculator reads numbers the way your language writes them, with a decimal comma in German or French.
Written for each country, not word for word. Prices, limits and promises stay exactly as they are in English.
Pick your language at the bottom of any page, or in the menu on your phone. The docs, the blog, the changelog, the Terms of Service and the Privacy Policy stay in English.
The plans page now answers the questions people wrote to us about.
Your plan on another workspace. If your Pro or Max is on another workspace, the plans page says which one and lets you switch to it or move the project there, instead of offering a second plan. You can still buy a second plan, after one question.
Why checkout stopped. If checkout cannot open, you see the reason and can try again.
Top up from Plans. A paid workspace can add credits right from the plans page.
No Playcode branding on paid sites. Every site in a paid workspace publishes without Playcode branding. There is nothing to turn off.
Lifetime plans. Pro and Max are not added on top of a Lifetime plan. The plans page explains this and puts you in touch with us.
If you moved your domain's DNS to Playcode, asking the agent to connect www or another subdomain, like shop.example.com, now finishes the job: Playcode writes the subdomain's record in your domain itself, checks that it is there, and the address goes live once its certificate is ready.
Before, the subdomain could be claimed with no record written, so it stayed on Not seen yet until someone added the record by hand.
Nothing to add yourself. Your domain's DNS is at Playcode, so there is no provider to visit.
A record you added while waiting is taken over. If it already points at Playcode, it becomes Playcode's record instead of causing an error. A record that points somewhere else is named, so you can remove it first.
Moving your DNS moves your site. When you hand your domain's DNS to Playcode, your site's old address is replaced by Playcode's, and the agent says so before anything changes. The old address stays in your domain's history.
A connection that cannot finish changes nothing. If the record cannot be written, the address is not left half-connected: you get the reason and what to fix, and asking again picks up from there.
A subdomain served from somewhere other than your main domain still connects. When Playcode cannot write that subdomain's record for you, the agent gives you the one record to add in your domain's DNS settings at Playcode, and the subdomain is connected.
What we review. AI agents run by our team read chats with the AI assistant and look at the projects it works on. They write short notes for our team, for example when something on our side failed or when you might need help.
Who reads what. Our team reads these notes, not your chats. A person reads a chat only when you ask us to, for example in a support request, to stop fraud or abuse, to answer a payment dispute, or when the law requires it.
What we never do. We do not sell your chats or projects, use them for ads, or train AI models on them. The review does not read what your connected accounts, such as Gmail, return to the assistant.
Your choice. You can object to the review at any time by writing to us, as the Privacy Policy explains.
Your app can now read photos and PDFs - receipts, invoices, scanned forms - and turn them into data, through Playcode AI Gateway.
Ask the agent to add it. It tells you what one document costs, the limits and where the data goes. Then it builds the upload, a signed-in endpoint and the call to a model that Playcode's own tests found good at reading documents, and it tries the feature once on a sample you give it.
Photos are priced as photos. Before a call, Playcode sets aside credits by each model's own limits for images and PDF pages, then charges what the model reports. A phone photo no longer needs the credits of a long text to start.
Files in new Cloud apps. The app's AI service takes files, images and PDFs, and the browser sends them with apiUpload.
Gemini for apps, processed in the EU. Your app can call Gemini 3.1 Flash-Lite and Gemini 3.8 Flash, run on Google Cloud in the EU. Gemini 3.1 Flash-Lite read every field of every test document in Playcode's runs, at about 0.005 credits a document. A model's card says where it is processed: ask the agent for the models that say EU.
A clear error for a big request. A request over the gateway's size limit gets a 413 requesttoolarge that names the limit, instead of an empty error.
A monthly AI budget for each app. Ask the agent, for example "Set a monthly AI budget of 50 credits for this app." Past it, that app's AI requests stop until the 1st (UTC). An app has no budget until you set one: without one, only your balance stops its AI.
The monthly spending email no longer stops your app's AI. Before, your app's AI requests were refused once the workspace passed its monthly line, even with credits left. The line is now what its setting says: an email.
Tools billed outside your credits are refused. A request that turns on a tool the model's maker runs and bills itself, such as web search or code execution, gets a 400 servertoolnot_supported. Write the tool as a function in your app instead.
The Playcode SDK now calls AI models: playcode.ai. Your app reaches the Claude, GPT and Gemini models Playcode offers it through one API, and switching models is a change of one id.
One call for every model.generate() answers, stream() answers as it writes, and both read images and PDFs. Give a schema (zod or JSON Schema) and the answer comes back as a checked, typed object.
Agents.agent() lets a model call your app's own functions in a loop. A run stops at its step limit, at its credit budget, when the balance runs out, or when you cancel it. In new Cloud apps, a run is saved as it goes, survives a restart, and goes on from its last finished step.
What a call cost. Every answer says the credits it used, by the model's published price.
Live models.models() lists the models your app can call, with what each reads, its limits, where it is processed and its price. A new model reaches your app without a code change.
The changelog ships in the package.CHANGELOG.md says what changed in each version and what to do when you upgrade. When the agent updates your app's SDK, it reads it first.
Ask the agent to add AI to your app: new Cloud apps come with it, and the agent updates an older app's SDK before it builds.
The docs for @playcode/sdk, the package your app's backend uses for AI, are now a section of their own, so you find what you need and copy code that works.
A quick start, and a map of what you can build with each part.
Agents in depth: tools, how a run ends, approvals, hooks, fallback models, sub-agents and spending limits.
A chat for your users, step by step: the chat endpoint and the React hook.
Runs that survive a restart, on your own database and queue.
Examples from real use cases: reading invoices, sorting tickets, answering from your own data, refunds a person reviews, a weekly report.
A reference of every option, event, error and default.
Every code sample in these pages compiles against the SDK: a test checks them on every release.
Activity and webhooks now include what happens inside your projects: file changes, commands, publishes and environment variables. These events were recorded before, but they were missing from the workspace's activity, and no webhook received them.
A project's events reach only the people who can see the project:
A private project's events stay with the people it is shared with.
An access token limited to some projects sees only their events.
A webhook gets a project's events only while the person who added it can see that project.
@playcode/cli 0.2 (npm) is out. Update with npm i -g @playcode/cli@latest.
playcode projects lists your projects again. In 0.1.1 it printed the list of project operations instead.
170 operations of the Playcode API, up from 89. Among the new ones: workspaces with their members and invites, billing settings and top-ups, creating a project of a chosen type, a Cloud app's computer settings and restores, uploads for big inputs, chats, project export and aliases, and app services. playcode <family> help lists a family's operations and marks the ones that need consent.
Every operation that charges money takes two steps, and so do destructive ones like deleting a project, a workspace or a chat: a proposal that states the terms, then the operation with that proposal's id. See Consent.
The CLI carries the operation list of its release, so an operation Playcode adds later needs a newer CLI. playcode mcp always reads the current list.
The Playcode SDK now does the hard parts of an AI agent for you. Ask the agent for a chat in your app, and it comes with these by default.
Conversations that keep going. Each of your users has their own conversations, saved in your app's database. An answer goes on when the page reloads or the server restarts, and picks up from its last finished step.
Actions wait for approval. An action your user confirms - a booking, an email in their name - waits for their Approve or Deny in the chat. An action only you allow, such as a refund, waits for you on your app's admin page.
A daily line per user. Set what one of your users may spend in a day. Past it, the chat says so before it calls a model.
What each user costs. Ask the agent what your app's AI cost, per user, per model or per day.
A spare model. Name a second model, and when the first one's maker is down, the chat goes on with it.
Long chats stay inside the model's limits. Old tool results are cleared first, then a short brief stands for the older part.
Agents cost less. An agent reads the part of its prompt that repeats from the cache, at the model's cache price.
Tested without credits. A scripted model and recorded runs let you test your agent with no network.
The chat page is plain and yours to restyle. Your app's secret key never reaches the browser.
Try it: Add a support chat to my app - each customer has their own conversation, refunds wait for my approval, and a customer can spend at most 1 credit a day.
Since October 8, an ad blocker could hide parts of the sign-in window on the Playcode website, the one that opens after you type an idea on the home page or pick a plan on the pricing page. With a blocker turned on, the Continue with Google, GitHub and Microsoft buttons were missing, and the field for the 6-digit email code did not show. Without that field, you could not finish signing in.
The sign-in window now shows every button and the code field, with or without an ad blocker. If it stopped you before, try again. You do not need to turn your ad blocker off.
The Create access token dialog in Settings → Workspace → Developers now offers every permission the API understands - including read-only levels (see projects, see domains, see chats), project management without the computer, and Drive the agent (start chats the Playcode agent works on). The list is served by the API itself, so new permissions appear in the dialog the day they exist.
Tokens are also editable now: change a token's name or permissions at any time without re-issuing the secret - the change applies on the token's next call. The workspace, project reach and expiry stay fixed; revoke and re-create to change those.
When you sign up and send your first message, it now goes straight to the agent. Before, many new accounts saw the pricing screen first, even though their free credits had already arrived, and had to send the message again.
Playcode now checks your balance with the server before it shows pricing, so the pricing screen opens only when you are really out of credits. If the check cannot reach the server, you get a short message to try again, and your text stays in the box.
When you upload files saved on Windows, the agent now edits them like any other file.
Changes across several lines work. Before, the agent could change a single line in these files but failed on any change that spanned more lines. It then worked around the failure: it hid old sections in comments instead of removing them, or rewrote the whole file.
Nothing to do on your side. Files you uploaded before this fix are covered too.
When your website fails to build on publish, the editor now shows the error itself.
The real error, with its place. The dialog names the problem and the file and line it comes from. Before, it showed only {}, so neither you nor the agent could tell what went wrong.
Hand it to the agent. Copy the error into the chat, and the agent can fix the code it points to.
When the agent takes a screenshot, views an image by URL, or generates or edits a picture, the image now reaches the model on every model choice - not only the Claude family.
FAST and economy models see what they work with. Before, models such as Gemini 3 Flash or GLM-5.3 Flash received only a text description of their own screenshots and image views, so visual tasks - matching a design, picking a product photo, checking a layout - could go wrong without the agent noticing. Now they look at the real image.
Honest results. A model that cannot view images no longer gets told an image was shown to it.
Full-stack projects can now be downloaded whole. Open the main menu and choose Project → Download, or simply ask the AI to export your project - it hands you a download card in the chat.
The ZIP carries your complete working tree, uncommitted changes included, ready to run on any server. node_modules, build output, your database and secret values stay out of the archive - a PLAYCODE-EXPORT.md file inside explains where each of those lives: secret values stay safe in Settings → Secrets, and your data downloads from the Files tab. The download itself names which of your own secrets and folders stayed out and where to copy each one; a fresh project, whose settings Playcode generated, has nothing to warn about.
A sleeping project computer wakes on its own for the export. Code export is part of the paid plans, same as the browser projects' ZIP.
The Standard model picker now opens on four models: Claude Opus 5.5 (the default), Gemini 4 Argon, GPT-6.1 Sol and Claude Sonnet 5.5. Grok 4.7, Gemini 3.8 Flash and Kimi K3 are still there: choose More models… at the bottom of the list to see them.
Claude Opus 4.6 and DeepSeek V4.1 Flash have left the picker. If one of them is already your model, it keeps working until you choose another.
Gemini 4 Argon - Google's new frontier model, built for deep, long-horizon work - is now available on the Standard tier, next to Claude Opus 5.5. Google released it yesterday; it went through our full verification before reaching the picker: live tool-calling, prompt caching, and token accounting all confirmed on the real wire.
Argon arrives at Google's introductory pricing, which runs through November 30: until then it is one of the cheapest ways to run a frontier model on Playcode. If you want long multi-step builds, large refactors or research-heavy work at well under flagship spend, this is the moment to try it.
Asking for a custom subdomain while publishing a cloud app now reliably gives your site that address.
The address you ask for is the address you get. A publish that requests a subdomain (in chat, the publish dialog, the API, or the CLI) now pins it the moment the publish succeeds, and the reported site URL uses it. Before, the request could be silently lost and the site answered only at its generated address.
You learn the outcome, not a promise. The publish result now states whether the subdomain was pinned, or exactly why it was refused - for example when the name is already taken.
Bad names are refused up front. A subdomain that is malformed, reserved, or already in use is refused before the publish starts, so you never wait through a deploy to learn the name cannot work.
Changing the address of an already-published app no longer requires a re-publish from the API or the agent - the same subdomain controls the editor always had are now available everywhere.
Try it: Publish my app with the subdomain my-cool-app
