# Astra for Writing, Fable for Coding Source: https://www.bobzhu.tech/astra-for-writing-fable-for-coding/ Markdown: https://www.bobzhu.tech/assets/agents/astra-for-writing-fable-for-coding.md Tags: Essays, AI Summary: Astra feels better for writing. Fable feels better for coding. Live speech adds another use case: talking through ideas and steering a draft as it develops. Feature image: https://storage.ghost.io/c/ea/80/ea80b01b-c9d0-45fd-a95f-5fbcd52ed925/content/images/2026/09/astra-fable-feature.jpg Feature image alt: Ink sketch of an open notebook with edited prose on one page, a code window on the other, and a plum pencil between them. Feature image caption: Writing and coding can lead to different model preferences. My current impression is fairly simple: [Astra](https://developers.openai.com/api/docs/models/gpt-6-astra) is better for writing, and [Fable](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1) is better for coding. It's a personal judgement, and probably too crude if you try to apply it to every task. But it's also a useful distinction. The model I'd want helping me write an essay isn't necessarily the one I'd want working through a codebase. That seems like a more interesting development than another argument about which model is ahead. We can have increasingly capable general models and still find ourselves giving them different jobs. ## Writing has to preserve what you mean When I ask a model to help with writing, I want it to understand what I'm trying to say, including the parts I haven't quite worked out how to say yet. A rough paragraph might contain a useful observation, an awkward sentence, and a qualification that needs to stay. A good revision should be able to separate those things. Making the whole paragraph smoother can actually make it worse if the qualification disappears or the observation becomes some broad claim about the future of work. This is where writing with AI gets frustrating. A sentence can be perfectly readable and still be something I would never write. The words are fine. The emphasis is wrong. Something I meant provisionally now sounds certain, or a fairly ordinary point has acquired an unnecessary sense of importance. Asking for something to sound 'more like me' is partly asking the model to stop doing that. Voice includes what I choose to leave uncertain, how much explanation a point deserves, and when I think a paragraph has said enough. It goes further than using Australian spelling and a few contractions. A model can follow those instructions and still produce an essay that feels like it could belong to anyone. That's the standard behind my preference for Astra on writing. I want help developing the thought while still recognising it as mine. There is only so much value in a quick first draft if I then have to rewrite every paragraph to recover what I meant. ## Live speech makes the writing use case more interesting The Astra use case I'm especially interested in is talking through the work while it's happening. Explain an idea aloud, let it start taking shape, then correct the emphasis before the whole draft goes in the wrong direction. There are some fairly ordinary uses for this. Talk through a rough essay before there's an outline. Explain why a paragraph feels wrong without having to write a second paragraph describing the problem. Rehearse an explanation for a lesson or presentation, then ask for a written version that keeps the useful parts of how you actually said it. Sometimes the correction is as simple as: 'That's too strong. I only mean this in the context of writing.' A useful model should carry that qualification into the next version. Otherwise, speaking just gives you a faster way to produce something you still need to rewrite. The setup needs a little precision. [ChatGPT Voice](https://learn.chatgpt.com/docs/features/voice) uses GPT-Live for the spoken conversation and can coordinate work in Chat, Work, and Codex. [Astra's API model](https://developers.openai.com/api/docs/models/gpt-6-astra) doesn't itself support audio input or output. I'm talking about using speech to direct work assigned to Astra, where that model is available, with the voice layer handling the conversation. [Astra also supports corrections while a task is in progress](https://developers.openai.com/api/docs/guides/latest-model). That makes this kind of back-and-forth more interesting: I can develop the brief as I see what the model does with it, instead of having to get every instruction right at the beginning. I've written before about [voice becoming a way to direct real work](https://www.bobzhu.tech/gpt-live-voice-assistant/). Writing feels particularly suited to it. The way someone explains an idea aloud can contain exactly the emphasis that disappears when a model tidies it into a generic essay.
Ink sketch of a microphone sending a plum speech waveform into a notebook with editable paragraphs.
Live speech can carry a rough idea and the corrections that shape its written version.
## Coding gives you a different kind of feedback With code, I can take the output and run it. I can inspect the change, try the feature, and see whether the original problem is still there. There are limits to that. Tests can miss things, and working code can still be difficult to maintain. A model also has to understand the request well enough to build the right thing. But there is a much more direct way to push back on parts of its answer: this fails, this behaviour changed, this doesn't work with the rest of the project. So the qualities I want become more concrete. Read the existing code. Make a sensible change. Check it. Use the failure to work out what to do next. Follow the problem far enough that I can actually use the result. Fable is my preference for that work. The explanation is useful, but I also need the change itself to hold up when I try it. I wouldn't stretch this into a claim that Astra is the creative model and Fable is the logical one. Writing requires reasoning. Coding requires interpretation and taste. Even the official documentation covers [Astra's coding behaviour](https://developers.openai.com/api/docs/guides/latest-model) and [Fable's writing style](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1). The overlap is substantial. What seems to be splitting is my preference within that overlap. Being capable of both jobs doesn't mean being equally useful to me for both. ## The context has to move as well Once you start choosing models this way, another problem appears. The useful context may already be sitting with the other model. An essay might explain why a tool should exist, who it's for, and which features would make it unnecessarily complicated. If another model is going to build that tool, it needs those decisions. A short instruction to 'build the app' leaves too much behind. This is another reason I prefer [keeping useful instructions and decisions outside the conversation](https://www.bobzhu.tech/build-something-that-stays/). A writing sample, a project brief, or a note explaining why something was removed can travel with the work. Having to explain everything again makes switching models much less appealing. There's a cost to the switching itself, too. If a small improvement means more copying, more checking, and another conversation to manage, it may not save much effort. I've written about [judging AI by the cost of finishing the task](https://www.bobzhu.tech/cost-per-finished-task/), and that includes my attention. For now, the split gives me a useful starting point. Astra when the work is writing. Fable when the work is coding. I'll change that preference when the results give me a reason to.