DEV Community: Hieu Louis

I Cut My Prompt by 90% and the AI Suddenly Got Twice as Smart

Hieu Louis — Tue, 15 Sep 2026 05:54:19 +0000

I used to write long prompts with step by step instructions, examples, constraints, and then cap it off with "if you're not sure, just ask me" because I thought that was the safe approach, and the result was always the same, 30 minutes in it would time out, loop its reasoning, forget the original request, fix a couple of bugs, and declare itself done.

I switched models and got the same thing. Split the task into smaller pieces and got the same thing. Thought my machine was too weak so I upgraded the hardware and nothing changed.

Then one day I was exhausted and just typed out a short blunt prompt with no explanations, no examples, just the job, the authority, and a couple of constraints.

I'm working on Halis, a self-hosting systems programming language where the compiler is written in itself. The codebase is around 224,000 lines and has been through 30 stages of development.

I handed the AI the repo link with a token, told it to scan everything for bugs and keep fixing until scanning found nothing left, no asking, and to commit under my name.

It ran for 5 hours, found 14 real bugs, fixed them all, never timed out, never looped, never forgot a thing.

I sat there staring at the screen for a while before a few things clicked.

The more authority you give, the more stable it becomes

That line about "if you're not sure, ask me" sounds responsible but it actually kills everything because every question chops up the context, and by the twentieth question the AI is exhausted while the original task drifted out of its head long ago.

I banned it from asking. It stopped seeking permission. It started making its own calls, and reasoning flowed where it was actually needed instead of being spread thin across trivia.

The shorter the prompt, the cleaner the context

A 2000 word prompt eats 3000 tokens before I've typed a single character. Add in the system prompt and a pile of tool descriptions and I've burned 15,000 tokens before the work even starts.

A million token context sounds like a lot but attention is not infinite. The more junk tokens you pile in, the more distracted it gets from the code.

A short prompt hands almost all of the context back to the code. It focuses, and the quality jumps.

The stopping condition has to be dynamic

"Fix the bugs" means it fixes a few, declares victory, and stops.

But "keep fixing until scanning finds nothing left" means it can't declare victory early. It has to scan, fix, scan again, repeat, and it becomes its own critic.

That's why my sessions ran through 25 scan passes, and each one dug up bugs the previous pass had missed.

This isn't me making things up

Stanford ran 100,000 prompts and found that long prompts hurt performance in 73% of cases
Another study across 144 microservices showed that with the same agent, a minimal prompt hit 75.9% test pass while a detailed prompt only managed 50.3%
Just this past September, OpenAI themselves admitted in a post that all the accumulated instructions from older model generations were wrecking the performance of the new one

A long prompt is a sign you don't trust the model

When you write 2000 words explaining how to fix one bug, you're telling it it's dumb. It hears that, and it turns into a command follower.

But when you write 110 words and say I trust you to handle it, it becomes an engineer, and it comes up with things you never would have thought of.

What it actually did in that 5 hour session

Wrote its own scanner because the standard linters weren't good enough
Ran 18 layers of checks in parallel
Found a segfault that had been sitting there for over a year
Found a security hole in the ZIP parser of the archive library
Caught 65 places with the same broken pattern in the SIMD emitter
Rewrote the test harness because the test itself was broken
Fixed an LTO regression that a previous stage had quietly introduced
Verified everything again
Committed each fix individually
Pushed it all with my username instead of the sandbox's default identity

I didn't ask for any of that. It did it all on its own.

Strong models need freedom

If I handed that same workload to Claude Fable 5.1, the strongest model in the world right now, along with a long detailed prompt, the result would actually be worse.

Not because it's weak. It's not. It's strong. But a long prompt chains down any model no matter how powerful.

Fable 5.1 with a short prompt would be terrifying. Fable 5.1 with a long prompt is just on par with a mid-tier model given a short one, maybe even worse.

I've tested it.

Strong models need freedom. Freedom means clean context. Clean context means good results. That's it.

Final thought

If you're still writing long prompts and wondering why your agent keeps timing out or looping or forgetting what it was doing, try cutting it by 90%.

You might be surprised.

#AI #PromptEngineering #LLM #Developer #Coding #Productivity

The Email That Almost Fooled a Developer: A Story About Open Source, Trust, and Scams

Hieu Louis — Sun, 06 Sep 2026 13:09:29 +0000

I am a developer. For months, I have poured almost all of my free time into Halis, a systems programming language that I believe can change how people think about safety in software. I have written thousands of lines of code. I have fixed my own compiler errors, my own security bugs, my own infinite loops. I am at stage 30 out of 150. There is still a long road ahead, but I am proud of what I have built.

Then one morning, I opened my inbox and found a strange email.

The sender called himself Joshua. He wrote in English, with a confident and direct tone. He said he knew my project was underexposed, but that was a fixable problem. He said he noticed I had been committing recently, and that mattered more than people thought. He said the core work was already done, and what was missing was distribution, getting Halis in front of the right communities, the right people. He offered to rewrite the README, find four or five channels that fit my audience, and build a sustained presence. At the end, he invited me to a short call, no obligation, no pitch.

I sat there for a moment. My first feeling was joy. Someone cared about what I was building. Someone saw value in the code I had stayed up late to write. But then an uneasy feeling crept in. I did not reply right away. I read the email again, slower this time, line by line, and I started to see the cracks.

The Artificial Directness

His opening line was a perfect example.

"I will be direct, since you probably get plenty of vague emails."

It sounded sincere. But any scammer can write that sentence. He was trying to separate himself from the spam, trying to lower my defenses in the first few seconds. A real person who genuinely wants to help does not need to convince me that he is not a scammer. He just needs to show me that he understands my project.

This is a classic psychological trick. By acknowledging that I probably get spam, he is implying that his email is not spam. But the truth is that any scammer can write this exact sentence. It requires no knowledge, no skill, and no real intention to help. It is a canned line designed to lower my defenses in the first three seconds.

The Obvious Weakness

Then he said Halis was underexposed. That was true, but anyone who opens my GitHub can see it. He did not need to read my code or understand what Halis does. He just needed to look at the number next to the star.

He called it a fixable problem and positioned himself as the one with the solution. This is how he creates dependence. He wanted me to think I needed him.

Think about what that phrase does. It tells me that I have a weakness, and he has the solution. He is creating a problem in my mind and positioning himself as the only person who can solve it. This is manipulation, pure and simple.

The Public Information

He said he noticed my recent commits. But I had just published an article about Halis on dev.to a few days earlier. Anyone who read that article would know I was actively working on the project.

He did not need to follow my GitHub. He only needed to read a public post. He used public information to create the illusion that he was paying close attention. In reality, he just repeated what he had read.

He is using publicly available information to create the illusion that he is paying close attention to my work. He wants me to believe that he is genuinely interested in Halis, that he has been watching my progress. But the truth is simpler. He read a blog post and repeated what he saw.

The Lie About My Project

Then came the sentence that stopped me cold.

"From what I can tell, the core work is already done."

If he had actually read my ROADMAP, he would know Halis is at stage 30 out of 150. If he had looked at the repository, he would have seen the long list of features still missing. He did not read. He did not know. He just guessed, and he guessed wrong. That told me he had not spent any time understanding my project. He just wanted to sell me something.

This was the moment I realized something was very wrong. A real consultant would spend time understanding the project before offering advice. This man did not do that. He just wanted to convince me that everything was ready and that all I needed was his help to "distribute" it.

The Vague Promises

He talked about finding the right communities, introducing the project without being flagged as promotion, keeping momentum after the initial spike. It sounded intelligent. But he mentioned no specific community. He offered no strategy. He did not say how to write a post, how to approach admins, how to create value for readers. These are basic marketing principles anyone can write without knowing anything about Halis.

He promised to rewrite my README. But rewrite it how? Focus on what features? Emphasize what points? He did not say.

He promised to find four or five channels. But which ones? Reddit? Hacker News? Dev.to? He did not say.

He promised sustained presence. But for how long? How many posts? How much engagement? He did not say.

He was selling me a service with promises that had no concrete commitments. This is a hallmark of scammers. They use vague language so they can never be held accountable for failing to deliver.

The "No Obligation" Call

Then he invited me to a short call. No obligation. No pitch.

But this was the trap. Over the phone, he would use his voice, his speed, and psychological pressure to make me agree to pay. He would say this opportunity only comes once. He would say he was busy with other clients. He would push me to decide fast.

"No obligation" was just bait to make me say yes.

The phrase "no obligation" is another psychological trick. He wants me to feel safe so I will say yes. But once I am on the call, he will create urgency. He will tell me that this opportunity is limited. He will say that he is busy with other clients. He will push me to make a decision quickly, before I have time to think. This is high-pressure sales disguised as a friendly conversation.

The Wrong Frame

He called Halis a product. He called it a service. But Halis is an open source programming language. I do not sell it. I do not make money from it.

If he had actually read the repo, he would know that. He was trying to frame my project as merchandise and me as a customer in need of help. He did not want to contribute. He wanted to sell.

He is trying to frame my project as a commercial thing and me as a customer who needs help selling it. This is a tactic to turn a potential contributor into a paying client. He does not want to help Halis grow. He wants to sell me a service.

The Ghost

He used a generic email address. A professional marketer usually has a company email, or at least a verifiable online presence.

He had no LinkedIn. No GitHub. No blog. No portfolio. I could not find any trace of this person.

He was a ghost.

He wanted me to trust a person who did not exist.

What Kind of Scam Is This?

This is a marketing consulting scam. It works like this.

The scammer finds active open source projects on GitHub.
He sends personalized emails to build trust.
He offers marketing services for a fee.
If the developer pays, he does very little or nothing.
Sometimes he asks for repository access, then disappears with the code.

After the payment is made, the scammer vanishes. The developer loses money, and the project gets nothing.

What I Did

I did not reply. I marked the email as spam. I reported the account. I went back to building Halis.

And I realized something important. If someone genuinely cared about my project, they would read the ROADMAP. They would know what stage I am at. They would not call Halis a product. They would not send a vague email. They would start by contributing code, or at least opening a specific issue.

Joshua did none of that. Joshua wanted to sell me something.

I did not buy.

What You Should Look Out For

If you are building an open source project, a personal product, or anything you pour your heart into, let me say this honestly.

Be careful with emails like this.

They are not always obvious scams. They are often written with great skill, soft and precise, aimed directly at the psychology of a builder who longs to be seen. A scammer does not need you to be stupid. They only need you to be lonely, tired, and wishing someone would acknowledge your work.

Here is what to watch for.

Fake directness. A sentence designed to sound honest is not proof of honesty.
Exploiting an obvious weakness. Anyone can see a public repo with few stars. That does not mean they understand your work.
Praising public information. They are building false familiarity by repeating what they read.
Lying about the state of your project. If they cannot be bothered to read your documentation, their advice is worthless.
Vague language. Real experts give specific, actionable advice.
The "no obligation" call. It is much easier to pressure you when you can hear their voice.
Treating your project like a product. Not everyone who offers help wants to help.
No verifiable identity. Trust is earned, not requested.

Always verify the sender. Read every line slowly. Ask yourself: does this person truly understand my project, or are they just repeating what is visible from the outside?

Do not let excitement cloud your judgment. Someone who genuinely wants to walk beside you will not rush. They will take time to understand. They will ask specific questions. They will not need you to answer this week.

And above all, remember that your worth is not measured by how many people notice you. It lives in the code you write, the problems you solve, and the patience you keep when no one is watching.

Do not let a strange email shake that.

Halis: The Side Project That Became My Life's Largest Ambition

Hieu Louis — Sun, 06 Sep 2026 01:47:11 +0000

I never intended to build a programming language.

It began as an idle thought, a question I could not shake during a quiet evening. I had spent enough time writing software to feel the friction that every developer knows: the constant negotiation between performance and safety, between control and convenience, between trusting the programmer and trusting the runtime. I started wondering what a language would look like if it simply refused to accept those compromises. Not as a theoretical exercise, but as a real system that a person could actually run.

What started as a random experiment slowly became something far larger. It became the most ambitious project I have ever undertaken.

That project is called Halis.

What is Halis?

Halis is a compiled, self-hosting systems programming language where safety is the default state, not an afterthought. The compiler, called hlc, is written entirely in Halis itself. Two compilation passes produce byte-identical output, a fact that is verified by the bootstrap chain on every build.

The language is still under active development and has not been publicly announced until now. But the repository is open, the code is available, and the work speaks for itself.

This is not a toy language built for a weekend hackathon. This is a serious attempt to answer a serious question: can a systems language be built so that safety is not a feature, not a checklist, but the very foundation everything else is built upon?

How It Started

I did not have a grand plan. I did not have funding, a team, or a deadline. I had a question that refused to leave me alone.

The more I thought about it, the more I realized that most languages treat safety as something you can add later. You can enable warnings. You can run static analysis. You can adopt best practices. But the language itself does not stop you from writing unsafe code. It allows the mistakes to exist and then asks you to find them yourself.

I wanted something different. I wanted a language where the compiler says no. Where dangerous patterns are rejected before they ever become bugs. Where the default state is safety, not risk.

So I started building. At first, it was pure curiosity. Could I write a lexer? A parser? A type checker? Each small success made the next step seem possible. But somewhere along the way, the curiosity turned into conviction. The experiment turned into a mission. And the mission turned into the largest undertaking of my life.

Why I Kept Going

Most systems languages force a false choice: raw speed with the risk of memory bugs, or protection with runtime overhead you cannot always afford. Halis rejects that trade-off outright. Safety and performance are not opposites. A language should not ask its users to sacrifice one to gain the other.

That belief is not a marketing slogan. It is enforced by the compiler at the deepest possible level. Halis implements seven core guarantees that every program must respect, not because a style guide recommends them, but because the compiler refuses to build anything that violates them.

Seven Core Guarantees

1. I/O is a Declared Effect

In most languages, any function can silently read a file, write to disk, or print to the screen. You cannot know what a function does just by looking at its signature.

In Halis, if a function wants to perform I/O, it must declare it. If a function calls another function that performs I/O, even indirectly through five layers of calls, and that outer function does not declare the effect, compilation fails.

A function without a uses clause is guaranteed pure. It cannot touch the outside world. It cannot surprise you. What you see in the type signature is exactly what you get.

2. Every Operation is Checked

Integer overflow, divide-by-zero, out-of-bounds array access, invalid string indexing. In most systems languages, these are sources of undefined behavior. They are the bugs that turn into security vulnerabilities.

In Halis, they halt safely. There is no switch to disable these checks. There is no escape hatch that turns off safety in the name of performance. The checks stay on, always.

3. No Null, No Uninitialised Variables, No Hidden Globals

These three things are responsible for an enormous fraction of real-world bugs. They are not allowed to exist in Halis.

Everything is explicit. Everything can be audited. You never have to wonder whether a value might be missing, because the type system makes missing values explicit and forces you to handle them.

4. Memory Safety Without Garbage Collection

Use-after-move is a compile error. clone() deep-copies every owned type. The generated runtime uses reference counting with exact free at scope exit.

This is verified in CI with a memory-stress program that runs with a flat RSS under a 256 MB address-space limit. The memory footprint does not grow. It stays flat. That is the kind of proof I care about.

5. Fine-Grained Effects and Capabilities

The single IO effect is split into eight capabilities: IO, Fs, Clock, Args, Exit, Net, Rand, Proc, and Conc. Each is individually declared and statically verified through the entire call graph.

A function that only needs to read the system clock cannot secretly open a network connection. A function that needs to read command-line arguments cannot silently spawn a process. The compiler knows what every function is allowed to do, and it enforces that boundary.

6. Taint Tracking

The built-in generic type tainted[T] wraps any value as potentially attacker-controlled. The compiler statically rejects passing a tainted value to any sink, including print, println, write_file, read_file, file_exists, exit, net_lookup, and proc_exec.

You must sanitize first using the standard library helpers like sanitize_html, sanitize_path, sanitize_sql_identifier, or sanitize_command. If you need to bypass it, there is an explicit taint_unwrap() escape hatch. But it is explicit. It is visible. It cannot happen by accident.

7. Data-Race Freedom by Construction

The Send rule set and the ownership-boundary rule mean sharing a variable with a task outside a channel is a compile error. The type system rejects every data race at compile time.

Concurrency is hard enough without having to worry about two threads silently corrupting the same memory. Halis makes that entire class of bugs impossible.

Self-Hosting: Proof, Not Promise

The compiler source is written in Halis. The Stage-0 seed, written in Python, produces the first native compiler. That compiler then recompiles its own source.

The output of pass one and pass two are compared, and they must be identical, byte for byte. If they are not, the bootstrap fails.

This is how the language grows in itself. It is not bootstrapped by accident. It is bootstrapped by design.

Every time I run the bootstrap and see that diff of zero bytes, I am reminded why this matters. It is not enough to claim that a language is self-hosting. You have to prove it, every single time.

Formal Verification

One of the things I am most proud of is the verification layer. Halis supports formal verification through requires and ensures contracts. The hlprove tool generates proof reports and interfaces with the z3 SMT solver to verify properties about your code. The hlmodel tool performs finite-state model checking.

This is not a toy. These are serious tools for proving that your code does what you say it does, before you ever run it.

In a world where software failures can cost millions of dollars or human lives, this matters more than we like to admit.

Looking Ahead to v1.0-pre

As Halis moves toward v1.0-pre, I am preparing two significant changes that I believe will make the project far more accessible to the community.

First, I will be adding comprehensive documentation. Right now, much of the language's design and behavior lives in the source code, the specification, and my own notes. That is not good enough for a language that I want others to read, understand, and eventually contribute to. By the time v1.0-pre arrives, I intend to have clear, structured documentation covering the language syntax, the core guarantees, the standard library, the tooling, and the security model.

The goal is simple: someone new to Halis should be able to sit down, read the documentation from start to finish, and understand exactly what the language is, how it works, and why it was built this way. No guessing. No digging through commit history. Just clear, honest documentation.

Second, I will be breaking up the large source files into smaller, more focused modules. The compiler currently lives in a relatively small number of large files, which is natural for an early-stage project where the priority was getting the bootstrap working. But as the language grows and more people begin to look at the code, that structure becomes a barrier. Large files are harder to navigate, harder to review, and harder to contribute to.

By the time v1.0-pre is ready, I want the codebase to be split into logical, manageable pieces that make it easier for a new contributor to find what they need, understand how it fits into the whole, and make a meaningful change without being overwhelmed.

These two changes share the same underlying goal: to make Halis not just a language that works, but a project that people can genuinely participate in. A language is not just a compiler. It is a community of people who share a set of ideas about how software should be built. That community cannot grow if the barrier to entry is too high. Documentation and code structure are how we lower that barrier.

Current Status

Halis is at version v0.47.0-alpha. The test suite includes over seven hundred tests covering interpreter execution, native compilation, differential output, and bootstrap determinism. Bootstrap is deterministic. The language is stable enough to be studied, tested, and challenged, but it is not yet production-ready.

I expect v1.0-pre to arrive in 2027, with v1.0 LTS following in 2029.

Those dates are not deadlines. They are commitments.

Why This Matters to Me

I did not build this to chase a trend. I did not build this to add another line to my resume. I built this because I believe the next generation of systems programming needs stronger foundations, and because I wanted to prove that a serious language can be built from first principles with discipline and patience.

This project has demanded years of careful thought, and it will demand many more. There were nights when nothing worked and the bootstrap failed and I questioned whether it was all worth it. But every time I came back, because the question that started this journey still matters to me.

Can we build a language where safety is not an afterthought?

I believe the answer is yes. Halis is my proof.

Repository

The repository is open. The specification is available. The security model is written down. The code is there to be read, compiled, tested, and criticized.

GitHub: github.com/mhieuhonda/halis-lang

Everything is there. The SPEC. The SECURITY file. The compiler source. The standard library. The examples. The test suite.

Read it. Build it. Challenge it.

Final Words

I am not asking you to use Halis in production today. I am asking you to look at it with honest eyes and see whether the foundation is sound. I am asking you to consider whether a language built this way, with safety as the default, with proof as the standard, with discipline as the method, is worth paying attention to.

I believe it is. I believe it deeply.

What started as a random thought has become the largest undertaking of my life. And I am only getting started.

GPT-6 Astra: What’s Actually New in OpenAI’s New Frontier Model

Hieu Louis — Sun, 06 Sep 2026 01:22:18 +0000

OpenAI has released GPT-6 Astra, its newest frontier model, less than a week after Anthropic’s Claude Fable 5.1. OpenAI calls Astra the world’s most intelligent and aligned model yet.

What actually makes Astra different?

The simplest way to put it is this: Astra is built to do more, not just answer more. It can use a computer to complete tasks instead of telling you how to do them. It can create finished documents instead of giving you a rough first draft. During long coding sessions, Astra can also remember what happened earlier instead of starting from scratch. And it’s better at knowing when to take action and when to stop and ask.

The bigger shift isn’t just smarter answers. AI is getting closer to actually getting the work done.

Some important caveats remain, though. Astra doesn’t beat every competing model, and some of its biggest benchmark numbers come with asterisks.

What Actually Changed in GPT-6 Astra

Drive a Computer End-to-end

Astra can fill out forms, update CRM records, run frontend QA checks on a website, and troubleshoot software by watching what happens on screen, without step-by-step hand-holding. OpenAI reports a score of 72.6% on OSWorld 2.0, narrowly ahead of Claude Opus 5’s 70.2% and well ahead of GPT-5.6 Sol’s 65.7%.

Example: GPT-6 Astra can extract information from a W-2 and enter the relevant details into a Form 1040, helping automate routine tax-preparation work while leaving the final return for human review.

Knows When to Ask and When to Guess

Earlier models tended to either guess wrong on ambiguous instructions or interrupt with unnecessary questions. Astra is trained to fill in routine gaps on its own and pause only when the answer would meaningfully change the outcome.

OpenAI’s own side-by-side demo shows the difference: GPT-5.6 Sol built a personal career website on its own in about 13 minutes. Astra paused after 20 seconds to ask what career the user was actually moving into. That’s a small moment, but it illustrates the difference between a model that acts and a model that uses judgment about when to act.

Produces Finished Documents

Astra is trained to match your existing templates, tone, and structure, and to pull in only the context that’s relevant rather than padding the output with everything it knows.

Astra builds a slide deck from just a handful of template slides while keeping the tone and layout consistent throughout.

Remembers Across Long Coding Sessions

In Codex, Astra can now keep searchable notes across context windows instead of repeatedly compressing long debugging sessions into a single summary, preserving details that compaction tends to lose, like why an earlier fix failed. It’s opt-in for now through Codex’s config file, and OpenAI says it will become the default in the coming weeks.

Cybersecurity

Astra’s biggest jump isn’t a productivity feature at all. OpenAI reports Astra reaches the "Critical" threshold for cybersecurity under its own Preparedness Framework, its highest risk tier, meaning the model can independently identify and develop working exploits for previously unknown vulnerabilities. OpenAI reports a 100% score on ExploitBench and says Astra solved 88% of SRE-Bench reverse-engineering tasks on the first attempt.

Because of that risk tier, OpenAI is gating the more dangerous parts of this capability at launch. Astra will help with defensive work like secure code review and patch validation, but it refuses to create proof-of-concept exploits until OpenAI expands access through its Daybreak program.

GPT-6 Astra Benchmarks

All figures are self-reported by OpenAI in its launch materials.

Benchmark	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1	Claude Opus 5	Gemini 3.8 Flash
OSWorld 2.0 (computer use)	72.6%	65.7%	–	70.2%	–
FrontierMath Tier 4	97.6%	83.0%	87.8%	73.2%	–
GPQA Diamond	96.0%	94.6%	93.7%	93.7%	95.3%
Terminal-Bench 4.0 (coding)	57.7%	37.3%	55.8%	52.3%	19.1%
ExploitBench	100.0%	78.5%	–	70.0%	–
Humanity’s Last Exam (w/ tools)	57.2%	–	65.0%	63.6%	–

What this actually tells us:

Astra’s clearest strength is computer use. It leads Claude Opus 5 on OSWorld 2.0 and does it in meaningfully less time per task.
Its coding scores have improved substantially over its own predecessor, though the lead over Claude Fable 5.1 on Terminal-Bench 4.0 is narrow rather than decisive.
It is not universally ahead of Claude. On Humanity’s Last Exam with tools, Astra scores 57.2%, behind both Claude Fable 5.1 (65.0%) and Claude Opus 5 (63.6%).
Some headline numbers rely on evaluation setups that don’t reflect normal usage. Astra’s marketed 99.9% on ARC-AGI-3 depends on an expensive, stateful evaluation harness. Independent testing by the ARC Prize Foundation found that a standard, stateless API call scores far lower, somewhere between 17% and 63% depending on the reasoning tier used.

GPT-6 Astra vs Claude Fable 5.1 Comparison

As neither model is publicly available yet, early access users on X have been sharing interesting examples.

Building a 3D Villa from a Single Prompt

Developer Karan Kendre posted a head-to-head Blender comparison, asking both models to build the same villa scene. Astra comes out ahead, with a more polished and realistic-looking result, particularly in interior details.

Designing a Travel App from the Same Prompt

Both models were prompted to design an app with the same goal. Fable went sky-themed, while Astra took an astro-inspired approach. Astra comes out ahead, with a more distinctive visual identity and stronger thematic consistency.

Video Prompt Generation

Both models generated a prompt for the same video concept, then created using Higgsfield AI. Astra comes out ahead, with a more coherent sequence and stronger visual storytelling.

Cost of GPT Astra

GPT-6 Astra is rolling out in stages: limited organizations first, then all ChatGPT Plus, Pro, Business, and Enterprise users over the following days.

For developers, Astra is available as gpt-6-astra through the OpenAI API, Microsoft Azure, and Amazon Bedrock.

API pricing:

Input: $10 per million tokens
Output: $50 per million tokens
Fast mode: roughly 2.5x the speed at 2x the price

That’s well above GPT-5.6 Terra’s $2/$12 rates and Claude Opus 5’s $5/$25 rates. The pricing is a signal: this is built for high-value autonomous work, not routine bulk-text generation.

The model also supports zero data retention for eligible API customers.

Conclusion

The real test for Astra won’t be whether it can top another benchmark. It will be whether companies can hand it a messy, multi-step task and trust it to get the job done with minimal supervision.

On paper, Astra looks like a significant step forward, particularly in computer use, coding, and agentic workflows. But it doesn’t lead everywhere. Claude’s models still have an edge on broader reasoning benchmarks.

The bigger question is what happens outside the leaderboard. Once Astra is widely available, real-world testing will show whether its strengths translate into reliable, everyday workflows. That’s the test that matters most.

🦀 Learn Rust - From Zero to Master

Hieu Louis — Tue, 04 Aug 2026 05:50:37 +0000

https://github.com/hieulouisdev/learn-rust.git

This repository is a complete, self-contained journey through the Rust programming language. It is designed for absolute beginners who have never written a line of code, all the way to advanced Rustaceans who want to understand unsafe code, macros, and async internals.