code-anything.com
Log inStart free

Changelog

What's new

New capabilities, improvements, and fixes — newest first, with a sentence on what each one actually changes for you. Entries below are illustrative examples prepared for launch rather than a verified historical record.

// releases · what changed · what it means · how to report a regression

How this page works

A release log you can read in one sitting

Most changelogs answer only the first half of the question. This one tries to answer the second half too.

A changelog is supposed to answer two questions: what changed, and whether it matters to you. The first is easy to write and the second is the one people actually came for, so every entry below pairs the change itself with a plain sentence about the difference it makes inside a real workspace. If you are new here and want the tour rather than the history, the platform overview explains how the pieces fit together, and the capabilities pages go feature by feature.

Releases are listed newest first. Each carries a version tag and a date, and each is a batch of changes rather than something you install — code-anything is hosted, so a release lands on the platform and is simply there the next time you open a project. Where a change has a longer story behind it, that story goes on the blog rather than in the notes. Where it needs step-by-step instructions, those live in the documentation. And where you want to know what is coming rather than what came, the roadmap is the forward-looking half of this page.

One honest caveat, stated up front and repeated on every entry: the releases below were prepared as illustrative examples for launch. The capabilities they describe reflect how the platform works; the dates and the exact sequencing should be read as a worked example of how releases are communicated, not as an audited record.

What gets an entry

Anything that changes what you can do, how something behaves, or how fast it happens — new capabilities, meaningful improvements, and fixes worth knowing about. Routine internal work does not get an entry; if a change is invisible from inside your workspace, it stays out of the notes.

How releases are numbered

Each release carries a version tag and a date. The number goes up as capability accumulates: the first public release is v1.0, and each feature-bearing release after it takes the next minor version. The tag is a label for a batch of changes, not a package you install.

How to follow along

This page is the record, newest first, so bookmarking it is enough to stay current. Longer write-ups on the thinking behind bigger changes go on the blog, and discussion about what shipped happens in the community.

Releases

Recent updates

Note: the entries below are illustrative examples prepared for launch, not a verified historical record.

v1.4

Auto-recovery and version rewind

A release aimed at the worst ten minutes of any project: the ones right after a deploy goes wrong.

  • Agents now attempt safe recovery automatically on transient deploy failures.A flaky install step or a dependency that timed out no longer needs a human to notice and retry it. The agent re-runs the recovery path it considers safe, and only escalates to you when the failure looks like something that needs a decision rather than a retry.
  • Version history and rewind let you restore an earlier version of a project.Every build leaves a version behind, so a bad change is a recoverable event rather than a permanent one. You open the version history for the project, find the version you want to go back to, and rewind to it — the earlier state comes back instead of you having to describe the fix from memory.
  • Alerts now include richer failure context to speed up triage.An alert that only says "build failed" makes you go digging. These alerts carry which check failed, where in the pipeline it happened, and when — so the first thing you read is usually enough to decide whether to rewind, re-prompt, or ignore it.
v1.3

Scheduled health checks

Monitoring stopped being something that only happens while you are watching, and became something you can put on a clock.

  • Set recurring checks for builds, deploys, and preview URLs on your own cadence.A side project that gets touched once a month and a live product that ships daily need very different levels of attention. Choosing the cadence yourself means the quiet project is not spamming you, and the busy one is not going unwatched between releases.
  • A live status view shows the current health of every workspace at a glance.Instead of opening each project to find out whether it is still up, one view answers the question for all of them. It is the page to check first when something feels wrong and you do not yet know which project is at fault.
  • A faster build pipeline shortens the time from change to live preview.The gap between asking for a change and seeing it is the single thing that decides whether building feels conversational or like waiting on a queue. Shorter builds mean you keep the thread of what you were doing.
v1.2

Continuous workspace monitoring

The release where projects stopped being fire-and-forget and started being watched after they shipped.

  • Agents now watch builds, deploys, and previews around the clock.Most breakage does not happen while you are looking at the screen — it happens overnight, on a weekend, or after an upstream service changes something. Continuous monitoring is what turns "a user told me it was down" into "I already knew".
  • Health checks flag failing builds and unreachable previews before they reach users.A preview URL that no longer responds is the earliest honest signal that something is wrong. Catching it at the check stage means the broken state is caught in your workspace instead of in front of whoever you sent the link to.
  • Email alerts land when a check fails or a regression appears.Monitoring is only useful if it can reach you when you are not logged in. Alerts go to your inbox so the notification arrives wherever you already are, not only inside a dashboard you would have to remember to open.
v1.1

More templates and faster previews

A quality-of-life release focused on the first ten minutes of a new project rather than the hundredth.

  • The starter template library grew several new opinionated starting points.Starting from a template that already has the shape of what you are building means the agent spends its first passes on your idea rather than on scaffolding. You can browse the current set on the templates pages and pick one before you write a single prompt.
  • Preview builds are noticeably quicker for most projects.Faster previews change how you work more than they change any single build — short loops encourage small, checkable changes instead of one large prompt you have to unpick if it goes sideways.
  • The workspace UI was polished and a range of smaller issues were fixed.Nothing here changes what the platform can do, but the rough edges you hit most often during a normal session are the ones that got sanded down. These are the fixes you notice by not noticing them.
v1.0

code-anything launches

The first public release — the prompt-to-running-app loop that everything since has been built on top of.

  • Prompt-to-app: describe what you want and get a working project.The whole premise of the platform in one line. You describe the thing in plain language, and what comes back is a real project with real files you can keep editing, not a mockup or a screenshot.
  • Live preview and deploy are available from the start.A project you cannot see running is hard to judge. Preview shows the app as it actually behaves, and deploying is a step you take from the same place rather than a separate pipeline you have to assemble first.
  • Backend wiring arrives with the build rather than before it.No environment to stand up and no data layer to hand-roll before your first prompt does something useful. The code your app needs is written with it, and stays out of the way until then.

Delivery

How updates reach your projects

The short version: they arrive on their own, and they do not touch your code.

code-anything runs as a hosted platform, which changes what a release even means. There is no CLI to update, no dependency to bump, and no version of the product pinned to your account. When a release ships, the improved behaviour is simply what you get the next time an agent runs, a build executes, or a check fires. That is also why you will never see a migration guide attached to an entry on this page.

The important boundary is between the platform and your project. Platform releases change the machinery — the agents, the build pipeline, monitoring, deploys, and the workspace UI. Your project's files change only when you ask for a change and a build applies it. Those two things are kept separate on purpose, so reading this page never has to feel like reading a warning about work you now have to do.

MERGED TO MAIN · CI · THEN, AND ONLY THEN, DEPLOYCIevery push to main, and every pull requestlint — type-aware, whole repotypecheck — five packagesunit tests — brain and webeval suite — the regression gateconclusion: successTHE GATEDeploythe production Worker, built andshipped from that same SHAmanual redeployasks the API the same question — is CI green for this exact commit? — and fails if it is not
A release is not a decision someone makes on a Friday — it is a commit that already passed lint, five typechecks, both test suites and the eval regression gate, deployed at the exact SHA those checks ran against. The one route round the gate is an emergency flag an operator has to set by hand.

Platform updates arrive on their own

Improvements to the agents, the build pipeline, monitoring, and the workspace itself are part of the hosted platform. They reach every account as they ship — there is no version of code-anything to upgrade and no package to bump.

Your project code stays yours

A platform release never rewrites the code inside your projects. Your files change when you ask for a change and a build applies it, not because a release went out. That separation is what makes a changelog entry safe to read as news rather than as a warning.

Templates are a starting point, not a live dependency

When a starter template is improved, projects already built from it keep the version they started with. New capability shows up in new projects; existing ones adopt it the same way they adopt anything else — by you asking for it.

Your side

Do you need to do anything?

Almost never — but here is the honest breakdown of the exceptions.

For platform changes, no. Nothing to install, nothing to approve, nothing to schedule. The three cases where a release does imply an action are worth naming, because they are the only ones:

  • You want a new capability inside an existing project. New platform capability is available to every project, but a project only starts using it when you ask. Describe what you want in the project and let the build apply it — the same loop as any other change.
  • The capability is on a paid tier. Some things — payments, connected repositories, monitoring, and custom domains among them — sit on the paid plans. If an entry describes one of those, the action is a plan question rather than a technical one; the pricing page has the current split.
  • Something behaves differently and you did not expect it to. That is a regression, and the section below is the fastest path through it.

Everything else is genuinely automatic. If you have been away for a month, opening a project is all the catching up your account needs to do.

When it breaks

How to report a regression

Four steps that turn a vague 'it stopped working' into something we can actually fix — and get you unblocked in the meantime.

ONE DEPLOY · SHARE OF LIVE TRAFFICpreviousnew version0%uploadedsmoke-tested on the production domain through a version-override header — no user traffic10%canarytwenty seconds of real traffic, then the same probe against the live domain100%promotedprobed once more before the deploy job is allowed to report success/ 200 · /api/gallery 200/ 200 · /api/gallery 200/ 200 · /api/gallery 200any probe that is not 200, at any rung — every user goes straight back to the previous version
Traffic moves onto a new version in three steps, and each step has to answer two live requests with a 200 before the next one starts. It is a health check rather than a test suite — it catches a deploy that does not serve, which is why the steps below still begin with reproducing what you actually saw.
  1. 1

    Reproduce it once, deliberately

    Note what you did, what you expected, and what happened instead. A regression that only appears on one specific action is far easier to act on than "it broke", and the answer often surfaces while you are writing the reproduction down.

  2. 2

    Check whether it is your project or the platform

    Open the project and look at the most recent build and check results. If the last build failed or a check is red, the cause is usually a change inside the project. If everything is green and the behaviour is still wrong, it is worth reporting.

  3. 3

    Rewind if you need the working version back now

    You do not have to wait for a diagnosis to be unblocked. Version history keeps earlier versions of the project, so you can rewind to the last one that behaved correctly and investigate from a working baseline.

  4. 4

    Tell us, with the details attached

    Send the reproduction, the project, and roughly when it started. The community is the fastest route for "is anyone else seeing this", and the contact route on the about page is the one to use for anything specific to your account.

The order matters more than it looks. Reproducing first gives you the one sentence that makes a report actionable. Checking the build and health checks tells you which side of the boundary the problem is on — the troubleshooting section of the docs covers what the common failure signatures mean. Rewinding gets you a working project back while the question is still open, which is the part people most often skip. And reporting last, with the details already gathered, is what makes the fix fast rather than a back-and-forth.

For "is anyone else seeing this?", the community is usually quicker than any support queue. Anything tied to your specific account or a private project is better sent through the contact route on the about page.

FAQ

Questions about releases and updates

The things people ask when they land on a changelog and want to know what it means for them.

No — and it matters enough to say twice. The releases listed here were prepared as illustrative examples for launch. They describe the shape of what the platform does and how releases are communicated, not an audited history with confirmed dates. Treat the capability descriptions as accurate and the timeline as illustrative.

Be first to try what ships next.

Start building today and new platform capabilities land in your workspace automatically — nothing to install, nothing to migrate.