Cursor's new Build Live Apps feature creates and deploys web applications with databases, authentication, and hosting. Here's what's included and what it costs.

The post Cursor Can Now Build and Deploy Web Apps From Prompts: What’s Included? appeared first on TechRepublic.

Gift-giving isn't just about grabbing something solid under a determined spending limit. It's an expression of love, a way to show someone how well you really know them. That doesn't mean you have to do it all on your own, though. Sometimes you just need a push in the right direction to get things rolling.

This year, we spent hours collecting our favorites to help you get ahead of your holiday shopping. This list has everything: minimalist smart rings, Play-Doh flowers, sleek beat machines - you name it. Whatever your needs, no matter how demanding the recipient, you'll find something exceptional below for that special someone on your li …

Read the full story at The Verge.

New frontier models arrived this week as investors showed signs of growing cautious about AI spending. On the latest episode of This Week in AI, we examined those developments, along with research into how models learn and the less visible costs of AI adoption. From unequal pricing across languages to the environmental impact of data centers, the discussion raised questions about who benefits from AI progress and who pays for it.

Frontier models advance as investors question the spending

We started with three model announcements that show how quickly AI capabilities are expanding. Google introduced Gemini 4 Carbon, designed for cybersecurity and complex, multistep tasks. France’s Mistral published the weights for its trillion-parameter Large 4 model, also known as “Le Chonk,” giving developers more control over deployment and customization, provided they have the hardware to run it. Meanwhile, Google DeepMind previewed Genie 4, a world model that simulates environments, physical interactions, and sequences of events. Unlike language models that predict text, world models attempt to predict what happens when objects and people interact. With Genie 4, researchers could train AI systems in simulated worlds, an approach that would be especially useful in robotics, where teams could test AI designed to control robots before trying it on physical machines.

Investor enthusiasm for AI appeared to weaken even as model development accelerated. Anthropic moved closer to a public offering by filing its IPO paperwork publicly, although it hasn’t announced a date or share price. OpenAI has reportedly secured about $11 billion in funding for its latest round, well below its initial $30 billion target. Those developments coincided with sharp declines in several major technology stocks, and the tech-heavy Nasdaq ended October with its worst monthly decline since March 2025.

The scale of AI spending is attracting greater scrutiny, particularly as investors wait for returns. Companies investing in AI should pay attention to more than model performance. The economics of training and running increasingly expensive models could affect pricing, availability, and which providers remain competitive.

Researchers are rethinking how AI models learn

Researchers are investigating how AI models process information, retain knowledge, and generate responses. AI interpretability company Goodfire proposed a project modeled on the Human Genome Project, committing $10 million to begin mapping how large language models work internally. By studying which patterns activate in response to prompts and how changes to those patterns affect behavior, researchers hope to better understand why models produce particular outputs.

Google Research proposed a framework inspired by human cognition that introduces a “sleep” phase. During this offline period, models would consolidate new information and generate practice examples through a process researchers call “dreaming.” The goal is to address catastrophic forgetting, when learning new information degrades previously acquired capabilities, while helping models retain knowledge beyond individual conversations. The approach remains experimental, but it offers a possible way for models to continue learning without sacrificing existing skills.

We also examined Clover, a 35-billion-parameter diffusion language model released by China’s DiffuSpace. Most familiar language models use what’s called an autoregressive approach: They generate text sequentially, one token at a time. Diffusion language models instead work on multiple parts of an answer simultaneously, refining them over successive passes. DiffuSpace reports competitive performance and faster generation on some tasks when compared to autoregressive models of similar size. Alongside Goodfire’s and Google’s research, this work suggests that improvements in AI may increasingly come from rethinking how models learn and generate outputs rather than simply making them larger.

AI’s hidden costs extend beyond infrastructure spending

Research into the “tokenizer tax” revealed how AI pricing can disadvantage people who speak less widely represented languages. Researchers found that some languages require substantially more tokens than English to express the same message. In one example, the Malayalam translation contained slightly fewer characters than the original sentence in English, yet it required twice as many tokens: 26 compared with 13. Because AI providers commonly charge by token, these differences can translate into higher costs for users, particularly in communities where AI services may already be less affordable. Developers building multilingual applications need to consider tokenization efficiency alongside model quality.

In Finland, authorities are investigating Google’s clearing of more than 400,000 trees for planned data centers. The investigation centers on whether the company completed required environmental assessments before clearing the sites. The case shows why environmental reviews need to happen before land is cleared or construction begins. Once that happens, regulatory action can’t immediately restore the affected ecosystem.

Finally, several AI companies said they plan to honor a shared website opt-out signal that would let publishers indicate that their content shouldn’t be used for AI model training. The proposal could give website owners more control over future data collection, although participation remains voluntary. It can’t reverse the use of material already collected for training, and the standard will only help if AI companies follow the instructions publishers provide.

What’s next

This week’s developments show why evaluating AI progress requires more than tracking model releases and benchmark scores. We need to understand how systems learn, whether their economics are sustainable, and how their costs affect people and communities. As more businesses and individuals adopt AI, those considerations will become harder to ignore.

We’ll be back on Monday, November 9, for another episode covering the latest developments in AI research and applications. You can catch previous episodes on YouTube, Spotify, Apple, or wherever you get your podcasts.

Remember back in 2019, when you had only a handful of language models to choose from, all with limited context windows? That world is gone, and it feels like a forgotten past. Today, flagship providers and open source projects compete across model families, sizes, capabilities, and deployment options. Coding harnesses seem to be heading in the same direction.

On the surface, Claude Code, Codex, Pi, DeepSeek Harness, and the other coding harnesses all seem to do the same thing: help you build software with models. Look closer, though, and each one gives you control over different parts of the harness. What can the model see and change? How does it use tools? Where does it run, and what happens when it fails? So instead of asking which coding harness is best overall, ask:

Which layers of the harness do you need to control?

Thanks for all the harnesses! Now what?

Choosing a coding harness isn’t only about which model writes the best code. You’re also choosing what the harness provides, what you can change, and what you must build yourself. If it doesn’t give you verification, durable state, repair routing, or an enforced execution boundary, those responsibilities stay with you. You remain accountable for the workflow’s reliability and governance.

In general, each harness has a center of gravity: a layer that gives you the most direct control. The following table is a deliberately high-level overview of where that center sits. It’s not a feature matrix, and the boundaries overlap in practice. Claude Code can also run noninteractively and inside sandboxes, Codex also reads repository instructions, and all of them are changing quickly. The point is to show where each harness gives you leverage by default, and where the engineering work is likely to stay with you.

Table 1. Where each coding harness puts its primary control

Read the table as a map, not a ranking. A harness that hands you more control also hands you more to build, and a harness that does more out of the box decides more on your behalf. Which trade-off is right depends on which layer your project actually needs to own.

Claude Code: Control inside the run

Claude Code buys you detailed control over how implementation unfolds. CLAUDE.md provides standing instructions, skills add task-specific playbooks, subagents divide the work, and hooks intercept actions before and after tool calls. Unlike a permission rule that simply refuses an operation, a hook can explain the refusal or immediately return a compiler or policy failure to the agent.

These controls let you steer the coding loop extensively, but they operate within Claude Code’s existing lifecycle. If you need to control the outer lifecycle itself, you need another layer.

Codex: Control through separation

Codex buys you separation between a coding task and its execution environment. A noninteractive codex exec run can work on a narrow task in a specified repository, under an OS-enforced sandbox, and return a schema-constrained result.

This is useful for independent verification. You can give Codex a clean checkout, exclude the builder’s instructions, restrict writable paths, and run separate reviews for code quality, test gaps, persistence, or user-visible behavior. The sandbox depends on the operating system, but it moves scope enforcement out of the prompt and into the execution boundary.

Pi: Control over the loop

Pi buys you control over the coding loop itself. Its tools, commands, event handlers, context, models, and session state can be extended or replaced. This lets you decide which steps remain agentic and which follow deterministic policy.

For example, a local defect can return to implementation, a repeated defect can force replanning, and conflicting findings can trigger a recheck or human review. Pi can also run agents inside this lifecycle, so it’s more than a deterministic orchestrator. For my example below, I used its programmability to make the outer decisions deterministic—that was my design choice, not Pi’s definition.

DeepSeek’s harness: Control through composition

DeepSeek’s harness is useful when you want to swap out whole parts of the harness rather than steer or wrap them. Tools, sessions, lifecycle behavior, verification, and governance are all composable plug-ins, and so is the loop itself. That lets you replace one component without rebuilding the rest.

The trade-off is that your control is only as good as the plug-ins you compose. Where Pi gives you a minimal core to build on, DeepSeek’s harness gives you a set of parts to assemble.

A practical example

Let me give you the problem I was actually trying to solve: migrating a legacy Python 2.7 application reliably, without changing years of accumulated behavior or corrupting its persisted data. Getting the code to run on Python 3 was only one part of it. I also needed to preserve behavior, verify the data across both runtimes, control what the coding agents could change, and decide what should happen when a test or verification step failed.

So I approached the choice of coding harnesses from a very different perspective. Instead of asking which one was best, I asked what each one would buy me in terms of control, isolation, and lifecycle management. The answer led me to use more than one:

• Claude Code built the port because I wanted internal steering, specialized skills, hooks, and a factory of implementation and review subagents.
• Codex verified it in isolated runs because I wanted an independent model context, clean workspaces, constrained writes, and structured findings.
• Pi owned the outer lifecycle because I wanted durable state, evidence validation, bounded repairs, replanning rules, and human escalation.
• Frozen acceptance, including Playwright and Python 2/3 differential checks, ran outside the agents so neither the builder nor the verifier could redefine success.

I didn’t use DeepSeek’s Harness here because I wanted a very small outer lifecycle I could read end to end, not because it can’t do the job. To first check whether this setup would actually make a difference, I built a small Python 2 application with the same kinds of traps as the real migration. I then compared the composed setup with a single Claude Code session, in which Claude could verify and test its own code.

Interestingly, both setups passed all 25 hidden behavior tests. Yet the single-session setup silently collapsed two distinct Python 2 dictionary keys, the Unicode u’é’ and byte string ‘é’, into one Python 3 string. After the data was saved, one entry was permanently lost. The single-session setup also changed a Python 2 Unicode value into bytes without documenting it.

The test suite missed it. Claude’s own tests missed it. Hundreds of recorded behavior comparisons missed it. Even my hand-written reference port had the same hole.

But what happened next was even more interesting. Two isolated Codex verifiers independently reproduced the defect. Claude didn’t simply accept the finding; it contested it. Pi then launched a fresh Codex run that received only the finding and Claude’s argument. The independent recheck upheld the finding, and Claude accepted it. Pi routed the defect into a bounded repair, and the next verification round confirmed that both keys and their original types now survived.

It’s also ironic because models are often criticized for being sycophantic. They apologize and rewrite working code the moment you ask, “Are you sure?” Here, the opposite happened. Claude contested a defect that two independent verifiers had reproduced. Its session context contained its own implementation history and passing tests, all of which supported the patch. A fresh verifier context broke that self-reinforcing frame. Independent verification matters not because the second model is automatically right, but because it’s not anchored to the same history.

The important point is that no individual harness deserves all the credit. The better result came from combining the controls I needed: internal steering, independent execution, frozen behavioral evidence, and deterministic lifecycle policy.

How to choose your coding harness

When choosing a coding harness, start with the level of control you need and how much of the remaining harness you are prepared to engineer yourself. A useful comparison could begin with questions like these:

• Do I want to configure an existing coding loop, extend it, or replace parts of it?
• Can I control tools, context, memory, and model selection at the level my project requires?
• Where are permissions, allow lists, and policies enforced: in instructions, application logic, or the operating system?
• Can I intercept actions and lifecycle events before and after they happen?
• How much of the orchestration, state management, and session lifecycle can I change or orchestrate?
• What does the harness expose for observability, verification, and structured evidence?
• Which reliability and governance controls does the harness provide, and which ones remain mine to build?
• Can the harness work with other tools and harnesses if my requirements cross several control layers?

These are some examples to get you started, not an exhaustive checklist. The questions that matter for you will also depend on what you’re building, how much autonomy you’re willing to give the coding agent, and what you remain accountable for when it fails.

Your answers may lead you to Claude Code, Codex, Pi, DeepSeek’s harness, or another coding harness entirely. In the end, the developer’s name only tells you who packaged the runtime, not where your guarantees live. Whether you settle on one harness or orchestrate several, the principle is the same: Choose the tool by the boundary of control it gives you, and ask whether you want the agent to define the terms of its own success.