Changelog

Every notable change to Lyra, release by release. Each entry describes what changed for you, not what changed in the code.

This page is generated from the product repository on every deployment, so it always matches what is live.

[1.11.3-beta] - 2026-10-14 - Your AI assistant sees the full frontmatter

Your AI assistant now gets a post's whole frontmatter, including lists and grouped fields.

Fixed

When your AI assistant reads a post, fields that hold a list or a group of values, such as tags, FAQs and author details, now come through in full instead of empty. Yes/no fields like featured now read as true or false rather than as text.

[1.11.2-beta] - 2026-10-14 - Your AI assistant sees a post's frontmatter

When your AI assistant reads a post that lives in your repo, it now sees the post's frontmatter and address instead of reporting them as missing.

Fixed

Reading a post from your AI assistant no longer shows empty frontmatter and no slug for posts in a pull request, which led assistants to say a finished post couldn't be published. The assistant now gets the post's title, author, tags and the rest of its frontmatter, its slug, and the file it lives in. For posts written before this change, the assistant is told the frontmatter is in the post's file rather than that it is empty.

[1.11.1-beta] - 2026-10-14 - Retry a skipped SEO fix

SEO fixes that Lyra skipped or couldn't finish can now be tried again with one click, and fewer of them get skipped in the first place.

Added

A Retry button on any SEO Copilot fix that was skipped or couldn't be made, when trying again could help. Lyra picks it up straight away and the card updates as she works. Fixes to your own pages, and changes you already made or declined in an earlier week, stay as they are.

Fixed

Fixes that expand a thin post no longer get skipped with "Lyra has no published address for this page". Lyra now finds the post's live address from your Search Console data, so she can research the page and make the change.
An SEO fix that covers several posts is now made on every one of them, each tracked on its own. Before, Lyra changed only the first post while the pull request listed them all.
Fixes Lyra makes on a later day now go into the week's open pull request instead of opening a second one.

[1.11.0-beta] - 2026-10-14 - Use Lyra from your AI assistant

Connect Lyra to Claude, ChatGPT, Codex, Cursor, VS Code and other AI apps, and run your blog by asking.

Added

A new AI connections page in Settings with a link you paste into your AI app and steps for each app. Once connected in Claude, it works in the Claude mobile app too.
Your assistant can read every post in full, check Copilot and analytics, edit your writing guide and site settings, and write, revise, schedule and publish posts.
Your assistant can hand finished posts to WordPress, Webflow, Ghost or any other CMS it is connected to, and Lyra shows where each post was published.
You choose which websites each AI app can reach and a daily limit on actions that use your Claude key, publish, change your writing guide or site settings, or can't be undone. Your assistant asks you before any of those, and shows you what will change first. Questions to Copilot count toward the daily limit without asking.
The AI connections page lists every app you've connected, when you connected it and when it was last used, and lets you disconnect one app or all of them at once.

Security

Resetting your password, signing out everywhere, or having your account disabled also disconnects the AI apps you connected before that.

[1.10.2-beta] - 2026-10-02 - Clearer handling of a failed payment

When a website's plan payment doesn't go through, Lyra now pauses that website completely and tells you exactly what to pay, then starts again on her own as soon as the payment lands.

Changed

If a website's plan or extra-website fee can't be charged, Lyra stops all work on it: no new posts, rewrites, review fixes, revisions, SEO fixes or conflict resolving. Before, some of that work kept running on an unpaid plan. Your posts, drafts and settings are all kept.
Paying the open invoice is all it takes to start again. There is nothing to resume by hand, and a pause you set yourself stays as you left it.
The Billing page shows the payment that is due, with a button to pay it on Stripe's secure page or to update your card, instead of showing the website as being on the Free plan.
The automation status at the top of the dashboard reads "Payment due" and takes you to Billing. In Settings, a website waiting on payment shows a way to pay, and resuming your websites says which ones are still waiting on a payment.
Subscribing a second time while an invoice is still owed is no longer possible, so you can't end up paying for two plans on one website.

[1.10.1-beta] - 2026-09-30 - Sharper judgement on topics and search results

Lyra used to decide some things by matching words: whether a topic belonged to your focus area, what kind of page ranks for a keyword, and which subtopics the top results share. A post squarely on your subject could be turned away for using different words, and a topic on something else could slip through by borrowing yours. She now judges these by what they mean, and checks each part of a post's search plan against the draft one by one.

Changed

Topics are judged on their subject when Lyra plans your calendar, so a post that fits your focus area is no longer rejected for describing it in its own words, and one about something else no longer gets in by repeating your focus area's wording.
Lyra reads what searchers want from a keyword's results more accurately, including when the top results are mostly product and pricing pages.
The subtopics Lyra plans a post around now include ones the top results cover under different headings, and leave out filler like conclusions and FAQ sections.
Lyra's review checks each subtopic, question and angle in a post's search plan against the draft individually, so the same draft gets the same verdict every time.
When Lyra reviews a revised draft, she first checks which of her earlier notes it has already fixed, so she stops raising the same point again after it has been dealt with.
Her review also checks up front whether a post answers its reader's question from the first paragraph, whether the title promises only what the post delivers, and whether it shows first-hand experience, such as a worked example or a real measurement.
SEO Copilot suggests merging or removing a post only when two posts really cover the same ground. On a blog about one subject most posts share its vocabulary, and posts about different products or providers could be flagged as duplicates of each other.
Comments on an SEO Copilot pull request that only say it looks good or say thanks no longer set Lyra working on the pull request. Questions and requests still get an answer.
SEO Copilot no longer proposes a fix it already made, or one you declined, as if it were new. It shows the suggestion as not proposed again and names the week it was decided.

Fixed

When SEO Copilot found a post running thinner than the pages that rank on your site, it could suggest expanding it and then leave the page alone, saying it could only rewrite one passage. Lyra now recognises a fix that needs new sections and gives it a full refresh, so the post is actually expanded. Suggestions still waiting to be worked on are caught the same way.
When GitHub had a brief outage just as Lyra opened your pull request, the whole post failed and her retry checked every fact in it again before trying once more. She now retries opening the pull request itself, and a retry that does run skips the fact check when the post has not changed since it passed, so the pull request arrives sooner.
A review that finished just as Lyra's background cleanup ran could show up as a failed run with no score, even though Lyra had read the review and was already acting on it, and the post could briefly be marked as failed while it was still being written. A run that finishes is now always recorded as finished, with its result.

[1.10.0-beta] - 2026-09-23 - Posts are planned from what already ranks

Until now Lyra planned each post from her own web research, without looking at the pages Google already ranks for your keyword. Now, before she researches a post, she reads the current top results: what those pages cover, the questions people ask about the topic, and what Google shows at the top of the page. She plans your post to cover what searchers expect, and to add at least one angle none of the top results has. Her review then checks the draft actually delivers on that plan before the post is ready for you.

Added

Lyra studies the pages that already rank for your post's keyword before she plans it, so the outline matches what people searching for it expect to find.
Each post is planned to answer the questions people commonly ask about the topic, and to include something the current top results miss.
Lyra's review checks the draft covers what the plan promised before the post reaches you.

[1.9.2-beta] - 2026-09-17 - Planning tells you when Claude could not run

When planning could not reach Claude, because your Anthropic balance had run out or your key was no longer accepted, the activity log said Lyra had found no topics. That sent you looking at your focus area when the fix was on your Anthropic account. It now says what actually happened. This release also keeps a busier calendar topped up sooner, and checks new topics against your most recent posts on a large blog.

Fixed

When your Anthropic balance runs out or your key stops working, a planning run now says so in its log, instead of reporting that no topics could be found.
The activity log no longer says every weak topic was replaced when none were. It says how many were replaced, and that the rest still go ahead on keywords with less search demand.
A calendar that publishes more than one post a day is now topped up while two days of posts are still waiting, the same as a one-a-day calendar. Before, it waited until only one day was left, so a single failed top-up could leave the next day empty.
On a blog with more than a thousand posts, new topics are checked against your most recently updated posts, not the first thousand in alphabetical order.

[1.9.1-beta] - 2026-09-14 - Planning fills your calendar instead of coming back empty

When Lyra plans your calendar she swaps out any topic that would compete with a post you already have. Those swaps could fail over and over until the plan came back with nothing in it. She was never shown the posts she had to avoid, so she kept suggesting ones you already had. And when she explained how a replacement differed from your existing posts, that explanation could get it thrown out as being off your subject, even when it was squarely on it.

Fixed

When Lyra replaces a planned topic, she now sees the posts you have published and the ones she has already planned or written, so she stops suggesting posts you already have.
Lyra now keeps her reasons for a replacement separate from her description of which part of your focus area it covers, so a replacement that is on your subject is less likely to be turned away as outside it. Topics that really are about something else are still turned away, exactly as before.

[1.9.0-beta] - 2026-09-10 - Tell Lyra which folder to publish into

A repository can hold more than one website's worth of pages, a blog and a set of product or model pages, say. Until now Lyra always used whichever one she found first, usually the blog, and there was no way to point her at the other one. Now, when you re-scope a repository in Settings, you can type the folder that website should use. Lyra reads that folder to learn its format and voice, writes new posts there, and only looks at the posts inside it when she links between your own posts. Leave the box blank and she keeps finding the location herself, exactly as before.

Added

A folder field in the re-scope dialog, so you can tell Lyra which part of your repository a website publishes into.
Lyra learns the writing format and voice from the folder you name, rather than from wherever else in the repository she happens to find posts.
New posts are written into the folder you name, and cross-linking between your own posts only looks at what is inside it.
Leave the folder blank and Lyra finds the location herself, the same way she always has.
Type a folder that is not in your repository and Lyra tells you right away, without starting a scan.
If the folder you name holds only template or placeholder pages, Lyra learns its layout from them but not its writing style. She writes in her usual voice rather than copying the placeholder text, tells you so in the writing guide, and you can set the voice you want by editing that guide in Settings.
While a folder is set, everything Lyra does for that website stays inside it, including her SEO suggestions: pages elsewhere in the repository are left alone.

[1.8.3-beta] - 2026-09-10 - A post whose branch will not merge tells you what to do

Pressing Merge on a post whose branch had drifted out of step with your repository could leave it stuck. Lyra would try to sort the branch out herself, and when she could not, the post went red, lost its Merge button, and offered nothing but starting over or cancelling. Both of those throw away a finished post. Now the post stays where it was, keeps its Merge button, and says in plain words what is wrong and where to fix it.

Fixed

A post Lyra cannot merge on her own now explains itself instead of going quiet. When the branch genuinely conflicts with your repository it points you at the pull request on GitHub and tells you to press Merge again once you have sorted the conflict out there. When the merge simply did not finish, and the branch was never the problem, it says so and asks you to try again. A conflict warning clears itself the moment the branch can merge, whether you fixed it or Lyra did.
Posts that had already got stuck this way come back on their own. You do not need to do anything: they return to waiting for you to merge them, with the work they had done and the same pull request, and Lyra has another go at the conflict herself.
Merging a pull request yourself on GitHub is now noticed whatever state the post was in. Before, a post that had been set aside for you stayed on your "Needs you" list forever, asking for something you had already done.
A conflict Lyra has already read and could not resolve no longer costs you a writing run every few minutes for as long as the pull request stays open. She stops, tells you what she needs from you, and waits. A merge that failed for any other reason still retries in full, automatically and on demand, because retrying those is what fixes them.
Pressing Merge on a post that is still marked a work in progress now tells you to accept it first, rather than starting work that could never have finished.
A branch that has drifted too far from your repository for Lyra to merge automatically no longer leaves the same note on your pull request every couple of minutes. She says it once, the post explains what is wrong and stays ready for you to merge, and she picks the work back up on her own once the branch can merge again.
A post set aside because it did not clear Lyra's own review keeps its "Decide what's next" choice even when its pull request has since fallen behind your repository. That choice used to disappear, leaving no way to accept the post or ask for another pass.

[1.8.2-beta] - 2026-09-10 - A writing guide can be as long as you need

A long writing guide could stop Lyra writing at all. Once a guide grew past a certain length, every attempt to write a post failed the instant it began, and the attempt had no log to open and nothing in it that explained why.

Fixed

Your writing guide can now be any length. Past a certain size it used to stop Lyra before she started, so the post was never written. One blog's guide crossed that size and its posts stopped being written for two days; guides of every size work now, and nothing is trimmed to fit.
A post that cannot be started now says so, and says why. It used to be recorded as a writer that had finished without handing its post back, which described the opposite of what happened and sent you looking through an empty log for it.
A post stopped that way is left ready to run again rather than put in front of you for review, and Lyra no longer tries it twice more first.

[1.8.1-beta] - 2026-09-03 - Nothing is cut unless the source says otherwise

The fact check was taking true sentences out of finished posts. It would follow a link off the page a claim cites onto a different page on the same site, fail to find the quotation there, and remove it. One post lost a quotation copied word for word from the paper it cites, along with the figure beside it. Both are back, and the rule that allowed it is gone: a sentence is only ever removed when Lyra has read the page it cites and found that the page says otherwise.

Fixed

A claim is checked against the page it actually cites. Lyra used to follow links off that page when it looked like the page was crediting someone else, and an ordinary phrase in a headline or a paper title was enough to set that off. She now only follows a link when the claim's own sentence credits another source.
A quotation, figure or price that Lyra cannot find on the page it cites is now reported to you and left in the post. It used to be deleted. Not finding something is not the same as finding it wrong, and a page behind a sign-in, one that draws itself in your browser, or one that has been rewritten since answers the same way an invented quote does.
A claim whose source could not be read at all is likewise reported and kept rather than quietly removed.
A figure taken from a table on the source page is checked against the numbers in that table. Lyra used to require the sentence she wrote about the table to appear on the page word for word, which no honest sentence about a table ever does, so correct benchmark numbers were flagged and taken out. She now confirms every number is on the page and then reads the surrounding rows to check the sentence means what the page means. A number that is not on the page still stops the claim, including one invented among real ones.

Changed

The fact check panel now separates the two findings that used to look alike. "Not confirmed" means Lyra could not find the claim on the page and has left it in for you to check. "Contradicted" means she read the page and it says something else, and that is the only finding that still takes a sentence out of the post.

[1.8.0-beta] - 2026-09-03 - The same post, for a fraction of the run

Lyra used to rediscover your blog on every post: reading through everything you have published to find a free web address, checking the same links over again on every pass, and pulling your own pages down off the web while those very posts sat in the copy of your repository she was already working in. She now starts each post already knowing all of that. The posts that come out are the same; the run behind them is far smaller, and it is your Claude key that keeps the difference.

Added

Lyra now starts a post already holding the state of your blog: what you have published, which web addresses are taken, and which of your posts are worth linking to. She no longer spends part of your allowance working that out from scratch every time.
The run log flags a stage that has gone on far longer than it should, so an unusually expensive post is something you can see while it is happening rather than afterwards.

Changed

Every source a post cites is checked once, before the writing starts, and the answer is handed to each stage that needs it. The same links used to be checked again on every pass.
A link to one of your own posts is confirmed against the copy in your repository instead of by fetching your live site, and no stage goes out to the web for a post of yours that is already sitting in that copy.
The web address for a new post is checked for a clash against every post you have published. On a large blog the older posts used to be invisible to that check.
The fact check now runs once, on a post that has cleared review, instead of inside every review pass. A claim taken out for being unverifiable no longer gets written back in by the pass that follows, which is what used to send some posts round the loop several times over at your expense.
The fact check runs on a stronger model than the one that wrote the post, and a different one, so it is a real second opinion. Writing itself now always runs on the model Lyra picks rather than whatever your setup happened to default to, so what a post costs you is predictable.
A small review note no longer blocks the final writing pass, so fewer posts come back for your decision when the review is down to minor things.
The live log reads as an account of the work rather than a transcript: each claim's verdict in plain words, each of your posts weighed as a place to link from, and a step repeated five times shown once with a count.
A saved Gemini key shows as Active in Settings. There is only one, so a key you have saved is always the one drawing your banners.

Fixed

A post is no longer held for your decision over a claim Lyra had already confirmed. A sentence that carried on past the part being checked, or one holding a shortened word like "N. California", could be reported a second time as having no source.
A restarted post no longer redoes work that has already shipped. If the run being replaced had opened the pull request first, the restart now stops instead of writing and shipping the same post a second time against your key.
The short re-read after a claim is removed is no longer drawn on your dashboard as a whole extra fact check.
The fact-check summary in the run log accounts for every claim checked. Two outcomes were missing from the tally, so most of a run's claims could vanish from a line that read as complete.
A post no longer arrives without its banner because the tool that draws it could not start.
Every post is judged against the same review bar, whichever machine writes it.

[1.7.4-beta] - 2026-09-02 - Keep improving costs what it says, and a finished post never lands half-written

Keep improving handed a post a fresh allowance of writing passes instead of the one it promised, a post held back over a claim went round again without anyone able to fix it, and a pull request that could not be finished still went out as an unfinished commit on your default branch. Each of those now does what the screen says it does.

Added

A post that is finished but whose pull request is stuck now says exactly that, and offers the one action that helps: try to finish it again. It used to be reported as a post that never reached the score, on a post that had passed.

Changed

Keep improving now buys ONE more writing pass, so what a click costs is knowable, and clicking again always buys exactly one more.
Keep improving on a post held back over an unconfirmed claim now sends it to be rewritten, which is what the dialog has always said it does. It used to re-run the same check on the same words and come back with the same answer.
A post held back over a claim now stops as soon as nothing further can be tried, instead of re-checking the identical post two more times first. The reason you are given is the same one, sooner and for less.

Fixed

An accepted or improved post no longer leaves a half-written commit named after itself on your default branch.
When a claim is removed from a post, the sentence written in its place is now checked before the post goes out, and the fact-check summary on the pull request describes the post you actually received rather than the version before the edit.
A run that crashed and picked itself back up no longer spends a post from your monthly allowance without writing anything, and no longer loses the note saying why the post was waiting on you.

[1.7.3-beta] - 2026-08-27 - Every claim in a post is checked against the page it cites

A post's links resolving was never proof that what it said was true, and a wrong figure, an invented quote, or a study that does not exist could clear review as long as the page it pointed at loaded. Every factual claim is now checked against the source it cites before a post is finished.

Added

Before a post is finished, each claim it makes is checked against the page it cites, not just that the page loads.
A wrong figure is corrected to what the source actually says, automatically.
A claim that cannot be confirmed is dropped if the post's point still holds without it.
A claim central to a post's argument that cannot be confirmed is left for your call instead of being published or quietly removed.
Every pull request now ends with a fact verification summary: how many claims were checked and confirmed, and what was corrected, dropped, or left for you to decide on.

[1.7.2-beta] - 2026-08-27 - Posts stay on your subject, and stop repeating themselves

Your content focus decided whether Lyra would plan at all, and after that it was a line in her notes. Three checks stood between a proposed topic and your calendar, and not one of them asked whether the topic was about your business. The sameness had a cause one line away: the paragraph asking her to vary the plan was only written when you published more than one post a day, so a one-a-day calendar never received it.

Fixed

A topic outside your content focus is now rejected before it is written. Every topic has to name which part of your focus it serves, and that is checked against what you actually wrote in Settings rather than taken on trust.
A rejected topic gets replaced with one inside your focus. If no replacement can be found, that day plans one fewer post rather than one about somebody else's subject.
You can see it happen. The planning activity log now says how many topics strayed outside your focus and whether replacements were found.
The review pass knows what your site is about, so a post that drifted off your subject is caught before it reaches you, not after.

Changed

Every plan is now asked to spread across your focus area rather than circle one corner of it: different sub-areas, angles, funnel stages, audiences and kinds of post. That request used to appear only on calendars publishing more than once a day.
Variety is judged against what your site has already written, planned and published, not just against the other topics planned the same day. A plan that avoids repeating itself this week while repeating last month's posts was the same problem a month later.

[1.7.1-beta] - 2026-08-27 - The rules in your writing guide are the rules she follows

Your writing guide is the one part of Lyra's instructions you write yourself, so a rule you put in it should settle the matter. Rules about voice always did. A rule about anything else, like how a source is credited or how a date is written, could be read as a suggestion and quietly passed over, which is why a guide you had already fixed kept producing the same thing you asked her to stop doing.

Fixed

Every rule in your guide is binding now, not only the ones about voice and where posts go. Where your guide says never, she does not do it.
Where your guide disagrees with Lyra's own house style about wording or formatting, your guide wins. The handful of things she will not do either way, like em dashes and links she has not opened and checked, are unchanged.
The review pass reads your guide rule by rule against the draft and sends the post back for anything it breaks, quoting the rule and the exact line that broke it.
Breaking a rule your guide states outright now counts as a real problem rather than a passing note, so a post can no longer be published while still breaking one.
Asking for a change on a finished post keeps the guide in view. What she rewrites from your comments follows the same rules the post was written to in the first place.

[1.7.0-beta] - 2026-08-26 - Tell Lyra what to change, right on the post

Reading a finished post and wanting one paragraph different is the most ordinary thing in the world, and until now the only way to ask was to leave a comment on its pull request. If you had not connected a repo there was no way to ask at all.

Added

Ask for changes on any part of a finished post, the way you would on a pull request. Point at a paragraph, heading, list or table and a plus sign appears beside it; click it and say what you want changed.
Leave as many comments as you like across the post, then send them together. Lyra reads them all at once and changes only the parts you pointed at.
The banner takes comments too. Ask for a different one and she works from the banner you already have, so the new one still looks like it came off your blog.
No repo needed. With none connected, the post Lyra is holding for you is rewritten in place, and that is the same copy that goes into your repo the day you connect one.
With a repo connected, the change is committed to the post's open pull request, so what is on GitHub matches what you are reading. The comments you left and what she did about them are noted on the pull request as well.
The commit she makes says what she actually changed, so anyone reading your repo's history can see what happened to the post without opening the pull request to find out.
Watch it happen. The comments you sent stay on screen while she works, and the post updates in front of you when she is done.
Keep going until you are happy. Send more comments whenever the last set lands.
Every request stays beside the post: what you asked for, what she changed, and when she found the post already said it and left it alone. The count sits beside the section it touched, so you can open the history from the paragraph you are reading.
Changed your mind? Undo the last set of changes and the post goes straight back to how it read before them. The way back sits under the before-and-after, so it is right where you have just finished reading what she did.
Undo the undo to put the change back again, so trying something is never a decision you are stuck with.
Only the most recent change can be undone, so an undo can never quietly throw away something you asked for afterwards. Take that one back first and the one before it is next in line.
With a repo connected the undo is committed to the post's pull request and noted there too, so GitHub never disagrees with what you are reading.
If that round also made you a new banner, the banner stays: Lyra keeps only the post's current one, and she says so before you undo rather than after.

Changed

The card beside a post no longer counts Lyra's passes over the draft. The score she gave it is the part worth reading; the number of attempts behind it is not something you act on.

[1.6.8-beta] - 2026-08-24 - When your Claude key stops working

A key can stop working without you touching it: revoked, rotated, or expired. Until now Lyra kept starting work on it anyway, and every run was turned away at the door.

Added

A website whose Claude key is refused now stops, instead of starting run after run that cannot begin. Your activity log stays readable, and nothing waiting to be written is lost: she picks up the same plan once the key works again.
You get an email when it happens, so a website is never quietly sitting still until the next time you open the dashboard.
The website says so at the top of the page, and offers the two ways out. Add a working key and she starts again. If you have already sorted it out at Anthropic, have her check the key instead and she starts back up without you pasting anything.
Only the website whose key was refused stops. Every other website you run carries on, each on its own key.

[1.6.7-beta] - 2026-08-23 - Your post allowance counts the right month

Fixed

Your post allowance counts the month you are paying for. It had been measured as a fixed thirty-one days, so in any shorter month posts you had already paid for counted against the new month, and you could be told you had used up an allowance you had not.

[1.6.6-beta] - 2026-08-23 - When a fix cannot be finished

Not every fix works first time. The ones that do not now say so on the card instead of going quiet.

Added

A fix Lyra cannot make comes to rest. She gives a slow page several goes, but once one has failed the same way every time she stops asking and leaves the page as it is. Nothing is lost: the fix stays on this week's report, and next week's offers it again.
A fix that fails tells you why, on the card and in the run log, rather than showing the word "Failed" and nothing else.
A report or a fix that runs out of its time says so. A run stopped part-way is never mistaken for one that finished badly.
Work waiting on your Claude usage limit waits it out. Lyra holds it for more than five hours, so it starts itself once the limit lifts rather than needing you to run it again. Anything that genuinely runs and fails stops after three goes.

[1.6.5-beta] - 2026-08-23 - Watch a run of fixes, and stop it

A run of fixes can spend the better part of an hour on a single page. You can now follow it while it happens, and end it whenever you want.

Added

Open a run while it is going and you can follow it live. You see the searches Lyra runs, the sources she opens, how many facts she traced back to one, and the parts of the page she changes.
A refresh shows more still: which draft she is writing, why the last one was turned down, and whether the sources backed the finished page up.
Fixes that are not refreshes show their work too, so a run of twelve that went well reads as twelve pieces of work rather than a single line.
Stop ends a run within seconds. The page tells you that you stopped it, that nothing was changed on your site, and that the fixes remain for her next run. Your website is free again straight away, so anything queued behind it can begin.

[1.6.4-beta] - 2026-08-23 - Lyra brings a page's facts up to date, with sources

Some pages do not need better wording. They need newer facts, and now she can go and find them, read her own work back against the sources, and rewrite until it holds up.

Added

A new kind of weekly fix: a refresh. When a page loses traffic because what it says has gone stale, Lyra researches the topic on the web and rewrites it with current benchmarks, sizing and configuration detail. She replaces the facts rather than rewording what is already there. These arrive labelled "Refresh" alongside her other fixes.
Every figure in a refresh is quoted from the source she took it from, and she lists those sources in the pull request so you can check one in seconds.
She reviews her own refresh the way she reviews a new post. She researches the page, writes the update, then opens the sources again and reads her draft against them, rewriting until it stands up. She judges the finished page rather than a list of quotations, so she can go and find a figure her first research missed.
A refresh she cannot fully stand behind still reaches you. It arrives as a pull request with the open doubts written into it and how serious each one is, so you decide with the diff in front of you. Nothing reaches your site until you merge it.

[1.6.3-beta] - 2026-08-23 - Her weekly pull request explains itself and answers you

The pull request Lyra opens after each weekly pass says what is in it, keeps the rest of your repository in step, and does what you ask of it in review.

Added

Lyra answers review comments on her weekly pull request. Leave a comment on a line, or mention her in a comment on the pull request itself, and she reads it, makes the change, pushes it, and replies. She keeps going until you merge or close it, so the pull request ends up the way you want it.
Tell her to leave a file alone and she will. A change you did not want costs a comment rather than a revert.
She titles the pull request by what she changed on your pages, so a list of them reads as a list of different changes rather than the same line over and over. The description opens with a sentence or two on what she did and why it was worth doing.
Under that opening sits the file by file list of fixes, the sources behind any figures she added, and what she left for you.
Her fixes update the files your repository keeps in step with page content: a sitemap date map, a feed or tag index, a redirect list. She works out which ones those are by reading your repository and its own guides rather than being told, and the pull request says which files she touched and why.
Anything she decides not to change is listed under "Left for you", with the reason, so you can see at a glance what is still yours to finish.

[1.6.2-beta] - 2026-08-22 - Fixes for your own pages come with a brief you can hand off

Lyra says plainly which fixes are hers and which are yours, and gives you everything you need for the ones that are yours.

Added

A fix on one of your own pages - pricing, a product page, a landing page - comes with a Copy the brief button. It puts the whole issue on your clipboard: what is wrong, what to change, the pages involved, and the Search Console numbers behind it, ready to paste into Claude or ChatGPT. Those numbers are the argument, so what comes back is a first draft rather than a guess.
Lyra only ever changes the posts she writes, never your commercial pages, and the report says so on each of those findings. The finding is real either way, and still worth acting on.
Connect a repository and Lyra opens a pull request for the safe fixes on your latest report straight away, rather than leaving them as instructions until next week. She carries out anything you had already approved, and leaves anything you turned down exactly as you left it.

[1.6.1-beta] - 2026-08-22 - Ask for this week's report without waiting for it

The weekly search report no longer only arrives on its own schedule. You can ask for it whenever you want one.

Added

A Run this week now button on the SEO Copilot page. It does the whole thing at once: reading your search data, working out what changed, and writing the report. The button says when a report is already being written. There is a daily limit on how many times you can ask, since each run reads fresh data and writes a full report. The weekly report still arrives on schedule either way.

[1.6.0-beta] - 2026-08-22 - The SEO Copilot

Every week Lyra reads your search results and your own posts, tells you what happened and why, makes the fixes she safely can, and asks you first before anything that would take a page down.

Added

A weekly read on search, written as a briefing. Once a week Lyra works out what changed and why, and writes it up in plain language. The week, its headline and its four numbers sit in one strip that stays with you while you read. Each number shows the shape of its own week, so you can see whether a drop happened on a single day or across all seven. Each week is named by the dates it covers.
Findings that open onto their evidence. Each thing she raises shows the real pages, searches and numbers underneath it, so you can check her reasoning rather than take her word for it. The reasoning and the measurements fold away behind Why, and the actions you have to decide on stay visible.
Your decision this week, at the top. It names how many things are waiting on you, how much Lyra already handled without asking, and takes you straight to the first one. On a week where nothing needs you, it says that instead.
A line saying where the week's work went: how many fixes reached the pull request, what is still waiting on you, a link to check it, and a Merge button once nothing is still being written into it. Anything still waiting on your approval stays yours to decide, and arrives as its own pull request when you approve it.
Ranked fixes, and she makes them. Each one says exactly which page it would change and why. The safe ones - titles and descriptions, wording, and internal links - go ahead on their own and arrive as a single pull request for the week.
She reads a page before she rewrites it, so the new wording fits how that page already sounds. If the page turns out not to have the problem after all, she leaves it exactly as it is and tells you why. She only ever edits the pages a fix actually names.
Anything that would merge or remove a page waits for you. Those fixes come with Approve and Decline buttons, and nothing touches your site until you press one.
A page is never removed without somewhere for its readers to go. When two posts compete for the same search and she proposes folding the older into the newer, the redirect that keeps the old page's traffic comes with it. If she cannot find a way to forward an old address, she leaves the page alone and tells you she skipped it.
Every fix shows where it has got to, so you can tell at a glance what is waiting on you, what is on its way, and what is already in a pull request, with a link straight to the one it landed in.
Ask the Copilot. Every finding has an Ask button, and there is one for the week as a whole. Lyra answers from that week's report: why a fix is the fix, what happens if you ignore it, which pages are affected. Each finding also offers the two questions worth asking about it, so you can get an answer in one click.
Answers come from your actual site, not only the week on screen. Before she replies, Lyra reads the report you are looking at, every earlier weekly report for this site, what has already been fixed, what you declined, and, when a repository is connected, the pages themselves. So "has this already been dealt with" and "what does that page actually say" are questions with real answers.
She only ever reads when she answers, and never changes anything. When a question needs something none of that covers she says so instead of guessing. There is a daily limit on questions, since each one runs on your own key.
You can watch her work. An answer takes a minute or two, and instead of a spinner you see what she is doing as she does it: which week she is re-reading, which of your pages she has opened, and what she is weighing up, each with the time it took. When the answer arrives, the working-out folds away behind a line saying how many files it rests on, and you can open it again on any earlier answer.
A week by week archive, so you can look back at what she said and see whether it played out. She reads her own earlier weeks before writing a new one, so she stops suggesting a fix that has already shipped or one you turned down. If something you declined genuinely comes back, she says it came back and what is different this time.
This week's headline on your overview, taking you straight to the full read.
Quiet weeks are reported as quiet. Lyra will not invent work to fill the page, and a week where nothing needs doing is a good result rather than a blank one.
No repository connected is not a dead end. The same fixes arrive as clear step by step instructions you can follow by hand, and connecting a repository later turns them into pull requests.
Every measurement says what it is. A page can be measured several ways in one week, and each row under a finding names which measurement it is and shows only the numbers that were actually taken. Nothing is filled in to square off a table. The brief you paste into another assistant and the report you download name them the same way.
Pages are measured on all of their traffic. Google withholds the search term behind its rarest searches, so Lyra reads each page's own totals rather than adding up only the searches she can name. Her numbers agree with your Analytics tab for the same page and week.
She checks what Google shows about a post, which you rarely see yourself: two posts sharing one title, a title long enough to be cut off in results, a post with no description while your others have one, the same description used twice, and a post with no image to share with. She raises these only where your own site already does the thing, so a site that describes no post is not handed a hundred problems that are really one choice.
When a drop is not your page's fault, she says so. If Google has started answering a question above your page, or changed what your result looks like, the report explains that rather than suggesting you rewrite something that is not broken.
A week Search Console did not fully report says so, so a quiet tail is never described as your site going quiet.

[1.5.0-beta] - 2026-08-22 - See how your posts do in Google search

Search performance is now live in Website Analytics. Connect the Google account that owns your site in Search Console and Lyra shows how your posts actually rank, which search brings which page, and what Google has indexed.

Added

Website Analytics has a working Google Search Console tab. Sign in with Google, choose your verified property, and you get clicks, impressions, click-through rate and average position, plus your top pages and top search queries. Lyra pulls up to sixteen months of history the moment you pick a property, then keeps it current daily. She only ever reads from Google, never writes.
A Queries by page view pairs each search query with the page it sent visitors to, along with clicks, impressions, click-through rate and average position for that pairing. You can see which search drives which post, instead of reading top pages and top queries as two separate lists. Use the week picker above it to look back at past weeks.
Underneath the summary numbers, a breakdown shows how your search traffic splits across mobile, desktop and tablet, across countries, and how your pages appear in search results.
Index coverage tells you which of your posts Google has indexed, which it has not picked up yet, and where Google settled on a different address for a post than the one you pointed it at. It updates every week, as a complete report rather than filling in a post at a time.
The weekly numbers behind these leave out the last few days on purpose, because Google itself has not finished counting them. A normal week reads as a normal week, not as a drop in traffic.
While Lyra pulls your history for the first time, the page stays on the pulling screen until the whole pull is saved, then shows everything at once. You never read real click numbers above an empty list of pages.
Finishing the Google sign-in drops you straight onto the Search Console tab you just connected, instead of leaving you to find it.

[1.4.7-beta] - 2026-08-20 - You choose how often Lyra publishes

Planning no longer assumes a pace for you, and Starter no longer starts at three posts a day.

Added

"Plan next 7 days" now asks how often you want to publish before it fills anything in. Pick a few days a week (2, 3, 4 or 5, spread across the week so posts never bunch up) or a number of posts every day. Lyra keeps planning at that pace from then on, and you can change it whenever you like.
Each choice shows you the week it produces, day by day, and roughly how many posts a month it adds up to. If a pace would write more posts than your plan includes, it says so before you commit to it rather than letting the calendar stall partway through the month.

Changed

Starter now plans one post a day instead of three. Three a day used up a month of posts in the first five days, and publishing that fast can read as spam to search engines and hurt the site it was meant to help.
The pace picker used to appear only on the top plan. Every paid plan gets it now, up to what that plan publishes.

[1.4.6-beta] - 2026-08-08 - Your calendar is planned on real search demand again

Some plans were being filled with topics whose search demand had never actually been checked, and nothing on the page said so.

Fixed

Lyra checks how many people search for a keyword before putting a topic on your calendar, and rejects the ones nobody looks for. On some plans that check was not running at all, so the topics were chosen on judgement alone while looking exactly like checked ones. The check now runs wherever your calendar is planned.
When every keyword a topic could target turns out to have no real demand, Lyra now goes back and looks for different ground instead of planning the topic anyway.
A topic planned without the demand numbers now aims at the broader, more searched phrasing rather than the narrowest one.

Added

Your topic now says "volume not checked" when the demand numbers could not be read, and the planning entry in Activity tells you the same thing, so a plan built on judgement alone is never mistaken for a verified one.

[1.4.5-beta] - 2026-08-05 - Your plan's posts write at the same time, as sold

Growth and Scale now really do write several posts at once.

Changed

When more than one post was scheduled for the same day, your plan allowed them to be written together but Lyra still ran them one after another, so the last one in line could wait a long time before it started. They now write side by side, up to the number your plan allows. Free and Starter are one at a time either way, so nothing changes there.

[1.4.4-beta] - 2026-08-05 - Posts that were writing fine no longer read as failed

Posts waiting their turn are no longer marked failed while they wait.

Fixed

A post could show up as "Write Failed" a couple of minutes after Lyra picked it up, with a note saying the run had been lost, even though nothing had gone wrong. Lyra writes one post at a time per website, so when several posts came due together the later ones sat in line waiting for their turn, and waiting in line was being read as having died. Lyra would then start the post over on top of the one that was still going, which is why a run could flip between failed and finished as you watched it. Queued posts now simply wait, and the note on a genuinely failed run no longer guesses at a cause it cannot know.

[1.4.3-beta] - 2026-08-02 - The post you open is the post you wrote

Opening a post now shows that post, not one of the older posts Lyra linked to it from.

Fixed

A post's page could show a completely different article from your blog under the right title. It happened once Lyra had gone back and added links to a new post from the older posts that relate to it: those edits travel in the same pull request, and the page could pick up one of them instead of the post itself. The pull request was always correct, so nothing wrong was ever published or merged; only the page you read inside Lyra showed the wrong text. Every post that was affected has been put back to its own article, with all its review changes included.

[1.4.2-beta] - 2026-08-02 - Never two posts chasing the same search

Lyra now refuses to plan a post that would compete with one you already have, rather than only being asked not to.

Fixed

A new topic can no longer be aimed at the same search as a post you have already published or planned. Two posts chasing one phrase split the clicks and the ranking between them, so when a proposed topic lands on ground you already cover, Lyra plans that slot again for a different subject, and again if the next one clashes too. Each attempt is told which subjects are taken, so she is not answering the same question twice. Only when every try comes back onto ground you already cover does she leave the slot empty, because one fewer post that week beats one that competes with your own.
Before proposing anything, she now checks against your most recent posts first. On a blog with hundreds of them she had been comparing against the oldest ones, which are the least likely to clash with what she is about to plan.
On a site with no repository connected, the posts she reads to cross-link from are now the ones genuinely related to what she is writing. They had been picked in alphabetical order, so a blog with more than fifty posts had her linking out to, and checking for overlap against, whatever happened to sort first.

Added

The planning step now records what it checked your new topics against: how many posts it read from your published site, how many Lyra has already planned or written, and how many proposals it dropped for competing with something you have. If your sitemap could not be read, it says so there instead of quietly carrying on with less to go on.

[1.4.1-beta] - 2026-08-01 - See the links she added to your older posts

The step where Lyra links your existing posts to a new one now shows its work.

Added

Opening that step on a post's page lists every older post she linked to it, the exact words she turned into the link, and the reason that post earned it. When she linked nothing, it says how many related posts she weighed and why none of them qualified, so a post with no new links reads as a decision rather than a step that did nothing.

[1.4.0-beta] - 2026-08-01 - Keywords people actually search

Lyra now checks real search demand before she decides what to write, so her posts target phrases people type instead of ones that only sound specific.

Added

Every planned post is aimed at a keyword with real, measured search demand, in the range where a growing blog can realistically win. The blog page shows you which keyword a post targets and how often it is searched, so you can see why she chose it.
Posts about something brand new still go out fast. A subject nobody is searching for yet is worth writing precisely because you get there first, so Lyra pairs it with an established keyword that earns readers straight away instead of waiting months for the new subject to catch on. She also schedules those posts first.

Changed

Titles and section headings are now written around the post's keyword, so a post ranks for the thing it was chosen for rather than mentioning it once and moving on.

[1.3.0-beta] - 2026-07-31 - Your new posts join the rest of your blog

Every post Lyra writes now arrives connected to what you have already published, instead of sitting on its own with nothing pointing at it.

Added

When Lyra finishes a post, she goes back through the posts already on your blog and adds a link to the new one wherever a reader would genuinely want it next. She reads your posts to decide, so only the ones that are really related get a link, and she adds nothing at all when nothing fits. At most three posts are touched, and each gets a single link written into the sentence where it belongs, never a list of related reading bolted onto the end.
Those edits arrive in the same pull request as the post itself, and its description lists which posts she linked and why she chose each one, so you can see exactly what changed before any of it ships.
Posts you had Lyra write before connecting your repository get the same treatment when they land in it, so nothing written early is left stranded.

Changed

When Lyra picks posts of yours for a new post to link out to, she now chooses them by what they are actually about. On a blog with more than fifty posts she had only ever been shown the first fifty in alphabetical order, so much of your archive was invisible to her no matter how well it fit.

[1.2.12-beta] - 2026-07-29 - Every banner reaches the post

A banner Lyra draws now always arrives with the post, and weighs a fraction of what it did.

Fixed

A banner Lyra had already drawn could go missing from the finished post. The larger ones were being discarded on the way to your dashboard, so the post arrived with no header image even though the work had been done and reported as finished, and nothing said why. A large banner is now resized to fit rather than dropped.

Changed

Banners are now saved as WebP. It is the same picture at around a fifth of the size, so posts open faster in your dashboard and the image your readers load once the post is published is far lighter. A repository whose site cannot serve WebP still gets the format it expects.

[1.2.11-beta] - 2026-07-29 - Finding your blog, and your real banners

Learning your banner style no longer depends on how your site is built.

Fixed

Lyra now finds your published posts even when your site has no sitemap. It reads your blog page directly, and if it does not know where that is, it follows your own site's navigation to it. A site without a sitemap used to look to Lyra like a site with no blog at all, so nothing was learned from it.
The header image Lyra learns from is now the one on the post itself. Some sites give every post the same shared preview image, usually a logo card, and working from that produced a banner matching nothing you had published.
When Lyra still cannot find one of your banners to work from, it now searches for your blog, takes a real banner off one of your posts and works from that before drawing anything. If there was genuinely nothing to find, it tells you so instead of quietly inventing a look.

[1.2.10-beta] - 2026-07-29 - Banners that look like your blog

Lyra learns your banner style from the posts you have already published.

Added

Banners for posts written before you connect a repository now follow the look of your blog. Lyra reads the header image off your own published posts and works from it, so a new banner keeps your colours, layout and type and changes only the artwork and title. A site with no posts to learn from still gets one drawn from your brand, as before.

[1.2.9-beta] - 2026-07-29 - Setup that survives a bad start

Signing up and setting up hold together when something goes wrong on the way.

Changed

Everyone now fills in the short form about themselves when they sign up, and gets in the moment they submit it. No queue, and no waiting on an email.

Fixed

Signing in no longer occasionally fails outright and leaves a half-made account behind.
When Lyra cannot read your site during setup, the chat offers to try again instead of moving you on with nothing, and a slow read is waited out rather than reported as failed.
Refreshing part way through setup no longer jumps you ahead to an analysis that was never produced, and a site read that failed and then worked no longer shows the failure beside the result.
Lyra learns your voice from posts across your whole blog instead of only the oldest ones.
Lyra's emails no longer say you are waiting on a repository when your posts are already written. If posts are waiting, she leads with what is ready and mentions that connecting a repository opens a pull request for each one.

[1.2.8-beta] - 2026-07-29 - A dashboard that points you the right way

Every screen sends you to where the work actually happens.

Changed

The Overview's repository card is one line pointing at Settings, where connecting actually happens, instead of a whole setup flow in the middle of a status page. The sidebar's "Not connected" now takes you to the same place.
Today's focus leads with the work that needs you. Connecting a repository is a publishing step, not a gate, so it no longer pushes ahead of choosing a focus, planning your first week, or upgrading. Finished posts waiting on a repository lead with how many there are, and something Lyra is already running says so instead of offering a button that would start a second one.
A post's page asks you to connect GitHub beside the draft itself, and says what you get for it: the post released. That button no longer sits in the row that starts a post over, cancels it, or stops it.
Back on a post returns you to the page you opened it from, so a post you opened from the calendar goes back to the calendar instead of the library.
A finished draft shows on the calendar in the colour of a post that is ready, instead of sharing the colour of a day Lyra has not started yet.

[1.2.7-beta] - 2026-07-29 - See what a rewrite changed

A rewrite opens on the parts that moved, not the whole post again.

Added

See what a rewrite changed. When Lyra improves a post you already have, that run opens on just the parts that moved, with how many lines were added and removed and a count of the unchanged lines it is hiding. The whole post is one click away, and a first draft still opens in full.

Fixed

Reading a run no longer cuts a long post off part way through, and the tables, lists and links inside it now render properly.

[1.2.6-beta] - 2026-07-29 - What Lyra tells you about your repository is true

Every screen waits until it knows, instead of guessing from a weaker signal.

Fixed

Starting to connect a different repository and then backing out no longer leaves a connected website looking unconnected. Until now that quietly sent every new post to your drafts instead of your repository, and skipped your repository's writing guide.
A post can no longer be written in a shape your site cannot build: once a repository is connected, its own format leads the writing guide. A guide you wrote by hand is still kept, underneath, for your voice and tone.
A post shows branch and pull request details only once its branch is really on GitHub. While Lyra is adding a post to your repository, the page says so instead of naming a branch that does not exist yet.
Settings no longer reports a scan as pending in the middle of a running one, no longer goes blank when a check does not come back, and no longer shows the previous website's repository for a moment after you switch websites.
The scan timer counts from when the scan started, so leaving the tab and coming back no longer restarts it or under-counts it, and picking a new repository starts it from zero.
Lyra acts on a pull request comment only when it names her exactly, so a mention of a similarly named account no longer pulls her into work nobody asked for.

[1.2.5-beta] - 2026-07-29 - Every draft reaches your repository

The posts Lyra wrote before you connected now arrive whatever happens on the way.

Fixed

A post you have paid for can no longer be stranded on its way to your repository. A move that was interrupted part way picks up where it left off instead of failing for good, and posts you stopped mid-write or whose writing failed are moved across too.
Connecting while Lyra is paused, or while she is waiting out a rate limit, no longer gives up on your posts. She waits, then moves them across when she can work again.
Restarting in the middle of a move no longer loses the post being moved, and a move that fails for a passing reason is tried again instead of landing in your "Needs you" list.
Your posts are moved across even when Lyra cannot finish reading your repository, so a scan that fails no longer leaves them behind.
A post is never placed in your repository twice, and posts are moved in the order they were scheduled, with undated ones last.
A pull request Lyra opens from a draft carries that post's review score, so its description says where the post actually stands.
A post written before you connect no longer comes back carrying the previous post's text.
A post interrupted by a restart before you connected a repository no longer sits on Writing for good with nothing to retry.
With a full calendar, Lyra starts with the earliest post due rather than skipping past it.
A problem with one website's Claude key no longer stops Lyra's scheduled work on your other websites.

Security

Files that come with a post can only ever be written inside the workspace Lyra prepared for it, and the branch and folder names she creates for it come from a cleaned-up version of the post's title.

[1.2.4-beta] - 2026-07-29 - Posts finish instead of circling

A post could get caught rewriting itself for hours. Now it settles and lands.

Fixed

A post no longer loops between writing and reviewing long after it is good. The review used to start from scratch every time, so it kept raising a fresh set of small points even when the previous set had been fully fixed, and the post could never clear the bar. Each review now sees what the last one asked for and checks that work instead.
Lyra stops treating a source it could not open as a source that is wrong. A page that times out, blocks automated readers, or sits behind a paywall no longer sends the post back for another rewrite. A link that is genuinely broken still does.
A post that has stopped improving is handed to you rather than rewritten again and again. Small points can no longer hold back a post that has already met the quality bar and had its serious issues resolved.
Live logs from two of your websites can no longer overwrite each other, so the activity view shows the right run for the right site.

[1.2.3-beta] - 2026-07-28 - Cancel a post you do not want

Merging is no longer the only way to finish with a post Lyra has written.

Added

Cancel a post from its own page or straight from the Blogs list. When it already has a pull request, Lyra closes that pull request without merging it and moves the post to Cancelled.
Your branch stays in the repository, so you can reopen the pull request on GitHub if you change your mind, or write the post again from Lyra whenever you want.
Lyra asks you to confirm before she cancels anything, and tells you if she could not close the pull request so you can close it yourself.
A post that is already merged and live cannot be cancelled. A post Lyra is still working on asks you to stop her first, so nothing is cancelled out from under her mid-write.

[1.2.2-beta] - 2026-07-28 - Ask Lyra on the pull request

Tell Lyra what you want changed by commenting on the pull request, the same way you would ask a colleague.

Added

Ask for a change by leaving a comment on the pull request and mentioning Lyra. She makes the change, pushes it, and replies to say what she did. Review comments on a specific line work exactly as before and never need a mention.
Every request gets one reply, including when Lyra cannot carry it out, so nothing you ask goes unanswered. She acts on each comment once; comment again to ask again.

Fixed

Posts no longer come back with only a title and no body. A post that Lyra picked back up to improve could be saved empty, which also left the review scoring a post it could not read, so it never settled and kept trying.
A blog written before you connect a repository no longer shows branch and pull request details for something that does not exist yet. You now see the draft Lyra is holding for you, with its review score and dates, and a way to connect a repository.

[1.2.1-beta] - 2026-07-28 - The post you read is the post you have

The post on your blog page now matches the one in your pull request, and you can take it away with its banner.

Fixed

The blog page shows the current post. When Lyra rewrote a post to answer your review comments, resolve a merge conflict, or fit it into your repository, the page kept showing the older version while the pull request had already moved on. It now updates with every pass, so the two never disagree.
Images inside a post no longer render as a broken picture in the middle of the article. The post's banner is still shown above it as before.

Changed

Download gives you the whole post: a zip holding the markdown and the banner Lyra made for it. A post without a banner still downloads as a single markdown file.
Copy and Download now sit with the post they act on, next to the Brief and Article switch, instead of crowding the row of buttons at the top of the page.
You can copy and download a post once its pull request is open, not only before.

[1.2.0-beta] - 2026-07-27 - Posts before you connect

Lyra now writes your first posts as soon as you finish setup, and brings every one of them with her the moment you connect your repository.

Added

Lyra starts writing before you connect a repository. Setup plans your calendar and gets your first post written right away, on the same visit, instead of waiting for its first scheduled day.
Your calendar keeps running with no repository connected. Every post that comes due is written on its day and waits for you as a draft, so nothing stalls until you connect. You can plan a calendar before connecting too: all Lyra needs is your content focus.
Lyra learns your voice before she writes: she reads your own published posts, or your site's marketing pages if you do not have a blog yet, and builds a writing guide grounded in how you actually write. You can re-run this from Settings any time, and edit the guide yourself.
Posts written before you connect a repository show up in your dashboard with a review score, fully readable, with buttons to copy the markdown or download it as a file.

Changed

Connecting your repository now brings every post Lyra already wrote with it: she fits each one to your repository's format and opens its pull request, in scheduled order. A post that still needs a person opens as a draft pull request instead of a regular one.
If you edited your writing guide before connecting a repository, that edit is kept rather than replaced. Connecting adds what she learns from your repository to it.
A post Lyra writes before you connect counts toward your plan's posts, the same as any other, since the writing is already done by the time it reaches your dashboard.

[1.1.1-beta] - 2026-07-26 - Free trial writing

Your free trial writes its posts on its own now, on the days they are planned, instead of stopping after the first one.

Changed

Your free trial's calendar is planned once, when you start, and is not topped up after that. It already holds more posts than the trial covers, so Lyra no longer plans days she was never going to be able to write.

Fixed

Your free posts now get written on their own, on the days they are scheduled for. Until now only a post you started by hand was ever written: every other planned day passed quietly, so most people on the free trial only ever saw their first post and never received the rest.
Reviews keep running on the posts Lyra opens during your free trial, so a post that needs another pass gets one instead of stalling.

[1.1.0-beta] - 2026-07-26 - Notification controls

You decide what Lyra sends you, from Settings or straight from your inbox, and the guides are now one click away from anywhere in the dashboard.

Added

A Notifications tab in Settings, with a single switch for whether you get product mail from Lyra. Account, billing and security mail is separate and always on.
An unsubscribe link that works straight from your inbox without signing in, including your mail app's own Unsubscribe button. Turning it back on is done from Settings, so a forwarded link can only ever stop mail, never restart it.
A Docs link in the top bar, so the guides are reachable from anywhere in the dashboard.

Changed

Copy across the app now describes Lyra as the AI blog writer that lives in your repo, in her own voice.

Fixed

Signing in no longer occasionally leaves your account with a second, empty website you never added.

[1.0.1-beta] - 2026-07-14 - Access emails and a safer writing guide

You now hear back by email at each step of getting access, and a failed re-scope can no longer wipe the writing guide Lyra built for your repo.

Added

You now get an email confirming your request to access Lyra was received.
You now get an email the moment your access is granted, whether on its own or as part of a batch.

Fixed

If re-scoping a connected repo fails or comes back empty, your existing writing guide is kept instead of being wiped.

[1.0.0-beta] - 2026-07-14 - First public beta

Lyra opened to the public, bringing everything in the releases below together as one product you can sign up for.

Added

Lyra is open to the public. Request access, create your account, connect a repo, and she starts writing.

Changed

The writing pipeline, billing, teams, analytics, and payment tracking now ship as one product rather than separate pieces.

Fixed

A final round of bug fixes and interface polish before opening the doors.

[0.3.0] - 2026-07-14 - Payments and revenue tracking

Accurate, refund-aware tracking of every payment, replacing the earlier snapshot view of revenue.

Added

Every payment is sorted by what it was for: a plan, an add-on, or an extra website.
Refunds are recorded and netted out, so revenue totals stay correct.
Payments are captured as they happen and reconciled once a day.

Fixed

Steadier matching and recording of payments and refunds, including when a refund arrives before its original charge.

[0.2.0] - 2026-07-14 - Conversions and marketing attribution

Conversion tracking and first-touch attribution, so the source of every sign-up and purchase is captured.

Added

Key actions are tracked as conversions: sign-in, sign-up, purchase, new website, and adding payment details.
Each user's first-touch source is captured and kept, so you can see where sign-ups come from.
Sign-in tells a brand-new sign-up apart from a returning login.

Changed

Conversion tracking never blocks or breaks a request; it runs quietly in the background.

[0.1.0] - 2026-07-13 - The Lyra platform

The first platform release. It turns the blog pipeline we ran for our own site into the Lyra product, where everyone gets their own account.

Added

The writing pipeline (foundation). Daily SEO topic discovery, drafting with hero banners, editorial / fact-check / pricing review on every draft, and an iteration loop that runs until a post is ready, with full run visibility.
Your own account. Each user connects their own repo and brings their own Anthropic key, with strict isolation so no account can see another's data, and a per-repo writing guide built automatically when a repo is connected.
Multi-website projects. Run several websites from one account, each with its own pipeline, analytics, agents, billing, and calendar, plus a quick switcher between them.
Onboarding. Paste a website URL and Lyra fills in the focus area and settings for you to edit, grounded in SEO best practice, with an editable writing guide.
Billing. Four plans (Free / Starter / Growth / Scale), per-website subscriptions, stackable add-ons (extra post packs and seats), a paid slot for each additional website, enforced monthly and Free-lifetime post limits, upgrade-now / downgrade-at-cycle-end, and billing on posts written.
Teams. Per-website membership and roles, email invitations, and seat limits.
Account security. Email verification and one-time codes, password reset, an access-request gate, and rate limiting to keep accounts safe.
Analytics. Daily pulls from your connected Search Console, Google Analytics, and SEO data sources, tiered by plan, shown in a per-source panel.
Auto-writer and calendar. A scheduled sweep that writes the posts due each day at your plan's pace, with the ability to cancel or reschedule planned posts.
Reliability at scale. The pipeline keeps running smoothly under load, recovers automatically after an interruption, and paces itself so runs stay stable.