Val Town Release Notes

Val Town is the deployment platform for internal tools, and Val Town Access makes it easy to make tools internal. Now you can restrict access to your vals so that just your team, or just some people, or just the people with some email domain, can view them. We've taken all of the complexity of authorization and put in an easy switch that you, and your agents, can control.

Access requires no changes to your source code: it just works with your existing vals and URLs. When you change access to restricted and someone visits your val, they authenticate with Val Town and we manage their session and identity. You never have to think about cookies and passwords.

If your val relies on user identities, like if you want users to be able to create content or comment under their own names, you can do that too. We inject a signed x-val-town-user header with each request that you can read to get a user ID, and expand with our API to get usernames and more information.

Humans using browsers will get authenticated sessions when they're using Access: their browser receives a secure cookie which identifies them. But what about robots? And what about vals that also want to receive requests from webhooks or other computery sources? There's a button for that too: bypass tokens. You can create a token and supply it with the X-Val-Town-Access header or a ?val_town_access= query parameter to authenticate a non-human entity of your choice.

And speaking of non-human entities: it's all supported via our MCP server and Claude Code / Cursor / Codex plugin. Your agent can tweak access settings, create bypass tokens, make requests to vals, and anything else you can do in a browser.

We've been using Access for all of the internal tooling that we've built at Val Town on Val Town. It lets us simplify things a lot: no longer do vals have to deal with authentication, and we can easily audit who has access to what, without having to read the code. It's a powerful new primitive on the platform.

And today, all paid organizations on Val Town have it! Try it out on the settings page of any val. Now you can bring your team to the platform and make sure that only they have access to the important stuff.

Want a 1 month free trial of Val Town Business to try it out? Email us and we'd be happy to get you set up!

Dear investors and friends,

Val Town is the instant deploy platform for small apps. Our mission is spreading the joy of programming.

July 2026

In July, ARR grew 6%. Not quite our 20% target, but still decently positive. The growth came from Pro subscriptions ($25 / month), which as its own ARR category grew 26% in July (up from 16% in June). The majority of those customers were referred to us by AI.

Our use-case focus has been internal tools, particularly around growth and go-to-market, and we've been doing a lot of dogfooding. We built ourselves a CRM, Slackbot, and a handful of other bots to help us figure out which users to talk to.

In product updates:

• We added DeepSeek v4 Flash 0731 to Townie, and made it the default model. In my opinion, it's smart enough for most of what you'll need in Val Town, and 13x cheaper than GLM 5.2, 89x cheaper than Opus 5, and 178x cheaper than Fable 5 – not to mention that it's fast and shows its reasoning traces.
• ChatGPT Plugin
• The Val Town Docs are now hosted on Val Town
• Started our SOC 2 Type II audit
• & lots more

August 2026

Our goal for August remains growing MRR 20%.

Our use-case focus remains growth & GTM engineering. We will help others build internal tools, continue to build our own growth internal tools on Val Town, and increasingly talk publicly about what we're building.

In terms of product, we're about to release Val Town Access to enable your team to securely access your private vals.

We're also thinking a lot about Slack as a core surface area for our product. Let's make programming more multiplayer! Internal tools typically are illegible, brittle, built by one person, and difficult for others to understand, maintain or tweak. We think building in your internal tools in Slack with a Val Town agent could solve many of these problems – while at the same time, making your work on your internal tools more immediately legible to the rest of your company. Our instant deploys are an amazing fit for this paradigm.

Given where the market is, we're also thinking a lot about our AEO (getting AIs to recommend us more) and better evals for agents (ensuring LLMs have good experiences with us).

Key numbers

• Team: 6
• Hiring: 1 Infra Engineer
• Revenue Growth: 6% (Goal: 20%)

Highlights

• ARR grew 6%
• Pro ARR grew 26%
• Townie is another 13x cheaper

Lowlights

• Missed the 20% ARR growth goal
• 79 bug bounty reports in July (6 valid)

Best,

Steve

Many changes since early July: new docs site, new Discover page, new Townie models, new app layout, and more.

Docfooding

The Val Town docs are now written and hosted on Val Town. You can read about that docfooding effort on the blog.

Discover

To dislodge your codewriter's block, we have a new Discover page on val.town with templates, staff picks, and integrations.

Whack-a-model

DeepSeek V4 Flash is now Townie's default model. It's ~100x cheaper and roughly as intelligent as Opus. We also added Fable 5 and Opus 5 to Townie, because to each her own. The game of whack-a-model persists, though, with Qwen 3.8 atop the charts today.

ChatGPT Plugin + AGENTS.md

After adding our plugin to Claude's official marketplace last month, we did the same for Codex / ChatGPT.

One more piece of news in agentland: we now support the AGENTS.md convention via a special .config val. Those agent instructions are injected into Townie chats and MCP sessions.

Layout

Jackson redesigned and implemented new val.town global navigation app chrome. There's now an org switcher, left sidebar, searchable val dashboard, and an updated footer.

Tags!

You can now add tags to vals in val settings.

Monograms

Vals now have little placeholder monograms instead of defaulting to your profile picture as the val's image.

Environment variables

Environment variable groups are now accessible through our API — create, update, and attach environment variables for your org. Thanks to our friends at Herd for the feature request.

You can also now show and hide secrets while editing environment variables in the UI.

Sprig Sans

We've been sprinkling Sprig Sans, the typeface on our new homepage, across other pages. Gosh, type foundries always have the coolest websites.

std/openai

We updated the std/openai val to use OpenAI's latest models.

MCP branching tools

New MCP tools: merge_branch and delete_branch. That's 54 tools now, so Steve made some docs (in a val, ofc).

HTTP analytics

HTTP analytics in a val now have more useful x-axis time labels.

Lightning round

• PRs for vals now show the author's handle instead of their org's name
• We fixed a bug where some Pro users were seeing the wrong Townie limits in settings
• You can now link to a val's Connections page (and its other pages, like env vars) in its README by writing markdown, like Connect to Slack
• The first HTTP file in a val is now auto-pinned so that a preview will appear on the val's home page. You can change a val's pinned HTTP file in settings
• When creating a val, we now present an inline warning when a val description is too long. Thanks Nico for the suggestion
• We fixed a tiny text overflow problem in Townie, e.g. when rendering long URLs
• The MCP server can now directly upload blobs up to 1 MB, or 10 MB if the blob is hosted at a URL
• We fixed the CLI command to rename an org
• The Townie/MCP system prompt now documents val transfers between orgs
• Code search is now available on public vals (thanks, Nico, for reporting)

The Val Town documentation site is now written and hosted on Val Town. To reach parity with our now-deprecated Astro+Cloudflare site, our docs needed to meet a high bar of AX, DX, and UX.

1. AX: Agents read docs more than humans these days. Are we serving them well?
2. DX: We knew Val Town would lower editing friction and tighten feedback loops. But could we live without a static site framework?
3. UX: Docs must be fast and searchable, with all the table stakes features. Will users like our new site?

Stack

The stack for our new docs is unusual. Notably, the entire app is server-rendered. We do not load a client-side library like React, although we do use JSX for components. We write vanilla CSS and old fashioned <script> tags for client-side JavaScript. We author pages in markdown and hand doodle the illustrations (thanks, Jackson). Version control moved from GitHub to Val Town, and hosting from Cloudflare to Val Town. We still use Cloudflare’s edge caching.

As I’ll discuss below, there is no build step in Val Town, which is a huge architectural departure from most static sites, and also the biggest tradeoff. Whether we’re on the right side of that tradeoff, I’m honestly not sure—this is experimental, and I’m writing this to hear what you think.

AX

Getting agent experience right, or at least to parity, was much simpler than developer and user experience. Like the old site, we surface llms.txt and llms-full.txt for agents. Each page has a “Copy as markdown” button for the human in the loop, and you can append .md to any URL path to view the raw markdown. The old site’s structure is preserved, so we inherit all that SEO and AEO juice, which, lately, has become a rather large slice of our new customers pie (user funnel cake?).

DX

Val Town’s core tradeoff is not having a build step. Apps (“vals”) are live the moment you save (in ~100ms), so the friction to edit is very low. Philosophically, that’s grounded in Bret Victor’s principle that creators need an immediate connection to what they’re creating. We knew from moving this blog to Val Town that we’d like how easy it is to edit.

The problem is, most static sites rely on a build step to achieve nice DX without sacrificing UX.

Consider CSS. I’m a big fan of scoped CSS, whether by CSS modules or styled-components or somesuch. Those solutions typically rely on a build step to generate unique classnames. In our docs app, we colocate CSS alongside components, like Header.css next to Header.tsx, which makes for nice editing but opens us to specificity footguns. And, to deliver those files without a build step, we have a single /styles.css endpoint on our server that reads and stitches together all those CSS files at request time when the browser parses a <link rel="stylesheet"> in a page’s HTML. That stylesheet is cached both in your browser with a Cache-Control header and on the edge via Cloudflare, but a cache miss can be slow: up to ~500ms. Nice DX has a cost.

Overall, though, the DX is pretty nice. While building the site I jumped between Claude Code, Townie, the val.town editor, and my local editor. With MCP or CLI, we can pretty much work wherever we’re comfortable.

UX

Docs should be fast and searchable. For search, the old site used Pagefind—a nice library that I still use for my personal site—which required a build step. We replaced it with MiniSearch, which the cmd+k bar lazy loads and is, IMO, about as good as Pagefind. Re speed, I’ll admit that I’m not sure our site is quite as snappy as the old Astro one. Pages are small and relatively quick to load, save for vals embedded in iframes, but for uncached pages the file retrieval and markdown parsing on the server takes a beat. It could be helpful to do some pre-fetching, say, for any pages linked in the page you’re viewing.

Forgoing a framework is also just fun. Documenting from scratch feels like an invitation to be “on brand” and playful. Links on the new docs site are green for internal pages, blue for val.town and val.run URLs, and orange for external sites. Of course, we could have applied custom styles to our previously frameworked site, but, idk, we didn’t. Coding in Val Town is supposed to be productive, but also fun. We’d like the user experience of reading our docs to leave that impression. We hope you like it.

Eat our docfood

Jim, whose blog post I linked up top, writes that our priority should be “UX over AX over DX.” I worry that our new docs may not be faithful to that order, but dogfooding has its own benefits. We want to push against and feel Val Town’s platform limits.

As before, the code is all public for our new site, and we’d love your critique to pick out the no-nos and gotchas.

Val Town now supports AGENTS.md. This is a feature we craved for ourselves and think you may find quite useful.

Per val

When you include an AGENTS.md file in any val, Townie will automatically read those instructions when viewing that val. Perfect for onboarding an agent to a project, explaining preferences and patterns and gotchas.

Per user

For instructions and preferences that Townie should always be aware of, you can add AGENTS.md instructions in a special .config val, which you can create and view via val.town/settings/preferences.

Per org

Orgs can also create agent instructions for context shared across your team. Like your personal instructions, org-wide instructions live in AGENTS.md within your org's .config val, also accessible in org Settings > Preferences.

For any agent

Agent instructions are surfaced to any agent—not just Townie—via our MCP server. So when you're using Claude Code, Codex, Cursor, or somesuch, your agent will have always read your personal instructions (and can likewise read per-org and per-val instructions).

Self-improving agents

One neat thing about AGENTS.md is that agents can read and write to the file. By writing its own instructions, an agent can create its own memory system.

This complements our custom skills and platform skills that agents can already discover. In combination, instructions and skills make Val Town a malleable and durable space for agents.

Read more about agent instructions and skills in our documentation.

Table of contents

1. Townie is 5x cheaper with GLM-5.2
2. Use Val Town with Claude Code, Codex, and Cursor
3. Write your own skills for Townie
4. New in town
5. HTTP analytics
6. Scoped blob storage
7. et cetera

Townie is 5x cheaper with GLM-5.2

There’s a lot of new stuff to talk about from the past 37 days. Personally, I’m most excited about zero-config HTTP analytics and scoped blob storage, but we’ll start with all the AI stuff.

GLM-5.2 is now available in Townie. It’s an open weight model about as smart as Opus 4.8 for about a fifth the cost.

Per our brief announcement, the top story on HN Monday was “GLM 5.2 beats Claude in our benchmarks,” and the top story Tuesday was the Sonnet 5 announcement. Then yesterday Fable 5 came back. You can try all three out with Townie, and let us know which other models you’d like us to support. (Townie is now using the Vercel AI Gateway, so we can freely swap models in and out.)

Use Val Town with Claude Code, Codex, and Cursor

Our new agent plugin bundles the Val Town MCP with Skills that teach your agent how to use Val Town. Plugin skills instruct Townie or any agent how to use Val Town’s features and platform, like SQLite and blob storage and integrating third-party APIs. You can view (and contribute to) skills in the plugin’s source code.

The plugin is in Anthropic’s official marketplace and also supports Codex and Cursor. There are commands to install for each, and npx plugins add val-town/plugins to auto-detect your agent(s).

Write your own skills for Townie

In addition to platform skills that ship with the plugin, you can create your own custom skills in Val Town. User-defined custom skills are more opinionated and personalized than plugin skills. Like, you could make a design skill based on your preferences.

You can define a skill in any val within a /skills folder, for example /skills/design/SKILL.md. Townie and our MCP server are able to discover your skills from any val. And, ofc, we have a plugin skill for creating custom skills, so you can ask Townie to help you out.

New in town

Jackson drew a warm town with his human hands for the val.town homepage.

We hope you don’t see it too often, but I also think you’ll enjoy the 404 easter egg.

HTTP analytics

Vals with HTTP endpoints now come with lightweight built-in analytics. Pretty handy, I think.

Scoped blob storage

Just like each val already has its own SQLite database, every val now also has its own blob storage. Also pretty handy.

et cetera

• New MCP tool to add/update a custom *.val.run subdomain
• New UIs for diffs and HTML previews (and more) when using the Val Town MCP server in a supported MCP client like Claude Desktop (this feature is technically called an MCP app, which is confusing, but is a step in the right direction to improve sometimes-gnarly MCP tool call diffs)
• Still-running vals can now be stopped via Logs > Traces
• Townie can now save images uploaded in chat to blob storage
• Syntax highlighting, higher contrast, expand/collapse in Townie diffs
• You can now paste up to 4,000 chars in a Townie chat (previously 512)
• New UI for creating a new API token. “We don’t have to do this...but I always wanted the API token form to work like this.” -Jackson
• Updated docs for AI in Val Town (tl;dr is Townie or Plugin > MCP > CLI)
• New docs for syncing vals with GitHub
• New optional run boolean for MCP tools that update code, so your agent can decide whether to test running the code after edits
• Better handling of attempts to save files while offline
• Hovering a timestamp in Logs now displays local, UTC, and relative time
• Code editor supports JSON schema via CodeMirror extension
• About a dozen new templates to remix, e.g. AI phone caller, agent skills library, downtime email alerts, Stripe webhook handler
• New MCP tool to find templates
• Limit total vals to 2,500 for Free accounts and 4,000 for Pro accounts
• New MCP tool to delete a val
• Tighter API token permissions on MCP tool calls
• Any MCP tool call that edits files with an HTTP or email trigger will return its URL or email address
• Better discovery of docs.val.town/llms-full.txt (full docs in one file) by pointing to it from docs.val.town/llms.txt
• Fixed blob storage click-to-upload UI
• Generate val lockfiles async in background after code edits to speed up time to first run
• Agent plugin install instructions sprinkled around product for ease of discovery
• Clearer in-flow information and docs on transferring vals between orgs
• Cloudflare error pages now have more helpful info to troubleshoot
• Updated our Terms of Use to ban general-purpose proxying and similar high volume pass-through traffic (see terms for specific language)
• Display cron scheduled runs in local time instead of UTC

It’s scoped!

Since the early days, vals on Val Town have had the ability to store blobs on an S3-like service. Just import a val from the standard library and it works, with no setup or configuration. It's a tremendously useful and popular feature.

What's a blob, you might be asking? It's binary data that you store with a name, just like a file. And it can be any kind of data - text, photos, music, JSON - it's all the same to blob storage. It's a great option for storing unstructured, simple, or big data. If you've got structured data and need a database, check out our SQLite database support which is just as easy to setup.

Today we're adding a new version of blob storage with two important tweaks:

Scope blob storage is isolated by val, rather than by account. This simplifies things for when you might need to transfer a val from one organization to another, or list only the blobs that were created by one specific val.

In the old days (before yesterday), blob storage was scoped by your user account or organization. In the rare case that two vals wanted to access the same blobs, this was nifty, but in the more common case we'd see vals accidentally overwriting each others data. And there was no connection between a blob and the val that wrote it, so you couldn't transfer a val without losing access to all of its blobs.

It’s faster!

About 5x faster on our internal benchmarks. Pretty good! I'll even give away the secret: under the hood, scoped blob storage is based on good old Amazon S3.

We used Cloudflare R2 for the global blob storage system, because we were already using some of the Cloudflare stack, and the egress pricing difference is compelling. But in this case, proximity is the deciding factor: with an S3 bucket in the same region as our servers, file uploads, downloads, and other operations involve the minimum amount of network hops. It all stays in Amazon's network, and for small requests where latency is the biggest factor, that means a big performance difference.

View those blobs in the settings

Just like for global blobs, you can list, download, and upload blobs from the website, not just from code. Check it out with the new Blob Storage menu item from vals.

Scoped blob storage: a solid new default

If you're using Val Town's MCP servers, skills, or Townie, you might notice that the LLMs are now set to prefer scoped blob storage, as the more future-proof, faster alternative to global storage. If you're coding by hand (bless you, sweet thing) check out the new documentation for the std/blob val for details on how to use scoped blob storage. It's the same API, just a different import.

The Val Town plugin for coding agents is live, bundling Val Town MCP and platform Skills for your agents. It supports Claude Code, Codex, and Cursor.

Install

Install for Claude Code, Codex, and Cursor in one command:

npx plugins add val-town/plugins

Or from Claude Code's official plugin marketplace:

claude plugin install valtown@claude-plugins-official

Or in Codex:

codex plugin marketplace add val-town/plugins

Or in Cursor:

/add-plugin valtown

Capabilities

With the plugin, your coding agent can write idiomatic vals and deploy live to Val Town in 100ms. The plugin includes:

1. Val Town MCP server: list, read, create, edit, run, and deploy vals; view logs; query your SQLite and Blob storage; manage env vars, branches, and version history
2. Val Town Skills: platform know-how from our system prompt, plus skills for HTTP vals, crons, email vals, SQLite, OAuth, frontend patterns, API integrations

You can explore the plugin's source code at github.com/val-town/plugins.

Lately: Claude front and center, a fresh val layout, MCP upgrades, new Pro pricing (for new users), and more.

The month of Claude

More and more Val Town users are having Claude Code bebop, wibble, photosynthesize, and jitterbug¹ their vals, using the Val Town MCP server. Every val’s homepage now includes a copyable command for using Val Town MCP + Claude Code.

The val.town homepage also now has that command handy to meet our potential users where existing users are using Val Town—in Claude Code. You can bring the Val Town MCP anywhere you get your LLMs, though—not just Claude. It works in Codex, Cursor, Copilot—you name it. If it starts with C and thinks all your ideas are great, it’ll work with Val Town.

Townie now defaults to Claude Opus 4.6 with “Allow all” mode (a.k.a. YOLO mode) enabled (although you might consider taking things slow sometimes).

When starting a new chat, Townie remembers your selected mode and model from the last active chat. Opus 4.7 with xhigh effort level is also available, along with Sonnet 4.6 and Haiku 4.5 for faster and cheaper conversations. Inference is billed at-cost, without any markup: see our pricing update below for more information.

Our MCP server has new tools to remix vals and and copy files. That’s over three dozen tools now. Pretty much anything you can do in Val Town, you can do with the MCP server:

• read/write/run code
• read/write SQLite and blob storage and logs
• set up cron jobs and email handlers
• visit HTTP URLs
• ...and more

New val layout

The biggest change in town lately is to the core val UI:

• Both the val sidebar and file tree are collapsible, allotting more real estate to the file you’re editing
• There’s an editor status bar abottom the code editor with logs, editor settings, and the Deno Language Server
• You can view history for folders, files, and the whole val
• The SQLite explorer makes better use of available space
• Townie launches from the top right rather than bottom left
• ...and dozens more changes

I’ve been loving the new layout, personally. Thanks to Jackson for his careful craftsmanship!

Pricing updates

We increased Pro pricing to $25/month, or $250/year.

If you are an existing Pro user, your prices won’t change! As a thank you for betting on us early, existing Pro users will pay the legacy $10 per month (or $100 yearly) forever.

After using up monthly Townie credits ($10 monthly for Pro and $100 for Business), billing is now pay-as-you-go with 0% markup on LLM inference costs. We pass through costs from our upstream provider, Anthropic.

Free plans are limited to public vals, only for new vals. Existing private vals on Free accounts will remain private.

Also, the Val Town Teams plan is now called Business.

Everything else

As always, many more changes have landed.

Val history and file diffs can attribute edits to Townie.

A Val ID field and HTTP section were added to val settings, so you can copy IDs and set *.val.run custom subdomains (as well as which HTTP file to preview on the val’s homepage, as before). There’s also a new save-and-copy button when adding a custom subdomain or email.

The main val.town/dashboard now has a switcher for toggling between your personal account and any orgs you belong to. User profiles also got a facelift—you can pin vals to feature your best work (like you’d pin repos on your GitHub profile).

The new val creation flow always has you fill out a form with owner, name, description, visibility, and image. Previously, you could create an untitled-* val, which was convenient, but it meant metadata wasn’t as deliberate.

You can now download any public val, not just your own vals.

Script val logs now stream during execution rather than buffering until exit.

You can now sign in with Google, as an alternative to GitHub and email.

Townie now remixes opinionated starter templates by default when building new projects.

When you’re on a branch in a val’s code and navigate to another top-level resource, like SQLite, then back to the code—your branch now persists.

A confirmation dialog now appears in the SQLite explorer for destructive actions.

That’s it for this changelog. As always, send us your feature requests! Our Discord server is the best place to discuss requests.

Footnotes

(1) Bebopping, wibbling, photosynthesizing, and jitterbugging are all, in fact, in the Claude Code spinner verb dictionary. I’d play a quiz game of “Is it a Claude spinner verb?” if someone made one. Hm, you could probably make one in 5 minutes with Claude Code and the Val Town MCP server...

In this changelog: improving Townie and the Val Town MCP server; a std/oauth library for wrapping vals with authentication; migrating auth providers from Clerk to BetterAuth; upgrading to Deno 2.7.5; and much more.

Editor's note: We've been deconstructing the old Newsletter into discrete parts: this changelog (new), the Talk of the Town series highlighting community vals, Steve's public investor updates, and perhaps a public roadmap soon. The Newsletter itself is a periodical rounding up the best of what we've written each month.

Making Val Town delightful for both you and your LLM

Val Town exists foremost for you the developer, which for many increasingly means for your agent. Much of our energy of late has been spent improving Townie and our MCP server to improve DX both in the browser and wherever you get your LLMs. We've appreciated all the positive feedback on Townie and our MCP server, but more importantly please continue to send us bug reports and friction points so that we can improve AX while preserving great DX so you can improve UX.

Better Townie system prompt

We've updated Townie's system prompt with more platform guidance and opinionated patterns on building vals, like:

• Wrapping vals in std/oauth for authentication
• Runtime constraints/gotchas
• Preferring incremental progress over one-shot implementation
• Testing vals to validate generated code
• When to use different frontend app architectures
• How to integrate external services (Slack, Google, Stripe, etc.)

The system prompt doubles as a dense but high-yield guide you can read to learn how the Val Town platform works. Thanks to Michael from Sourcebot for the nudge here!

Preventing Claude Code hallucinations with the Val Town MCP server

Claude Code has been recommending Val Town to some users as a handy place to deploy the code it spits out (we're not doing any fancy AEO, in case you're wondering). But when using our MCP server with Claude, it's been hallucinating how to work with Val Town. We updated instructions in the Val Town MCP server with more platform/runtime context that MCP clients previously had to explicitly request.

Bringing Val Town to OpenAI Codex

Like Claude Code, Codex + Val Town MCP is an increasingly popular workflow for developers on Val Town. We updated our docs instructions for getting set up. Thanks Ash, Arti, and David M. for feedback on making the Codex auth flow smoother.

Fullscreen Townie

Townie now has two modes:

1. Sidebar (status quo)
2. Fullscreen (new)

Fullscreen UX is more like Claude Code or Codex where you're not necessarily keeping a close eye on the code itself, and sidebar Townie is more like Copilot or Cursor chat where you're reviewing code changes. (Why do all the AI coding tools start with C?)

Explicit context in Townie conversations

Previously, Townie knew which val you were currently viewing, but that wasn't obvious as a user. You were on the same page without knowing it. Now you can see and explicitly choose which vals to attach to Townie's context window.

Townie can read blob content

Townie could previously only read blob storage metadata: key, size in bytes, and last modified timestamp. Now Townie (and any MCP client) can also read blob content via an updated MCP tool.

Townie onboarding for new users

Onboarding for new users now routes to a Townie prompt box, which can be skipped to instead create a val manually (like the legacy onboarding flow).

Improving Townie reliability

We fixed a few corner cases in Townie where (1) responses manually stopped in progress by the user would disappear from the chat, (2) duplicate messages would appear, and (3) you could still approve tool calls after stopping a response in progress.

CLI improvements

The vt CLI is a third way to use LLMs with Val Town (we recommend Townie, then MCP, then CLI—in that order). Thanks to JP from Datasketch and Halah from Swayable for bringing a couple vt login frictions to our attention.

Add a secure authentication layer to your vals

Wrap any val with the std/oauth middleware from the Val Town standard library. This will authorize users based on their membership in your Val Town org (i.e. your teammates) or by their username or user ID. Or just add a gate that someone must have a Val Town account to access your val, to keep out spammers. It's sort of like Google OAuth meets Cloudflare Zero Trust, but for Val Town. This is a major unlock for internal tools that need to be secured behind an authentication wall. Thanks to Cole Lawrence who pushed for this feature!

Migrating auth providers: from Clerk to BetterAuth

After experiencing a few too many stability issues with Clerk, we're migrating to BetterAuth. We are optimistic about the greater control and stability we'll have with BetterAuth. If the transition goes smoothly, you should hardly notice (if at all). You may have to mark login email links as not spam or re-approve GitHub OAuth. Please email [email protected] if you run into bugs. Thanks in advance for your help with the transition.

Opt in to receive Error notification email

The default notification setting for val errors is now website-only, instead of website + email. You can opt back into error email in val.town/settings/notifications. Notifications can trigger on the first occurrence of an error or every error, depending on your preference. We had trouble with other email (e.g. login links) going to spam, possibly caused by sender reputation harm inflicted by error notifications. Error emails are often low-information and come from abandoned vals, anyway. Email sender reputation is a Hard Problem that Tom is working hard to improve.

Dashboard redesign

The logged-in val.town dashboard now includes a switcher to toggle between orgs, namely your personal account and Teams org. This is table stakes for more and more and more of you who are using Val Town both personally and at work.

Access email headers in email trigger vals

Email-triggered vals can now access headers (like Message-ID) in the email object passed to the val as input. With Message-ID from an inbound email, you can set In-Reply-To on your reply so that strict-threading clients like Outlook will properly group the messages. Thanks to dt for requesting this!

DB Pro Now Supports Val Town

DB Pro, a database desktop client, now supports Val Town SQLite as a database provider. This is a powerful query UI for SQLite power users in Val Town, if you graduate out of the built-in SQLite admin panel in a val's sidebar.

Upgraded to Deno 2.7.5

Val Town code runs on Deno. Before upgrading to 2.7.5, we were on version 2.5.5.

Alternatives page

We wrote an Alternatives page to help prospective customers evaluate Val Town against similar services. As Steve wrote about in his February investor update, Val Town is still finding true product-market fit, which can be tricky for such a broad tool. The alternatives page is part of the effort to publicly reason about where Val Town fits in the devtools ecosystem. Thanks to Justin Duke at Buttondown for modeling what a thoughtful alternatives page looks like.

This is a newsletter about the goings-on in Val Town. I'm Pete, and I joined the team this year, partly to write things like this (and that , and this , and that ). Steve used to write these newsletters when I read them as a Val Town user, and I know it's nice to hear from the founder. Sorry I'm not Steve! Please do still reply with your thoughts and feedback, though—what you like reading about, what you wish Val Town would support, what vals you've built or want to build, et cetera. We'll reply!

Our last newsletter, #25 , was delivered in summer of 2025 when Townie was a val in user-space and "vibe coding" was only a few months old. Since then: the Val Town MCP server and vt CLI launched, so you can work on vals wherever you get your LLMs; Townie was reborn in product-space; every val gets its own SQLite database; our TypeScript editor is faster and better; we launched Teams so that you can bring Val Town to work; and much more.

Also: we're having a party this Thursday, March 12th, at our office in downtown Brooklyn. Come say hello!

The elephant in the town: AI

There are three primary ways to ✨ do AI ✨ in Val Town:

1. Townie
2. MCP + your favorite LLM
3. vt CLI + your favorite LLM

Before I talk about Townie, let me just say: Townie is quite good, but we encourage you to bring Val Town to whatever coding tool you prefer (claude code, codex, cursor, et al—it's up to you). Townie and MCP are a step above the CLI because they have better access to val primitives, but regardless of your weapon of choice, you get Val Town's core loop: edit code → 100ms deploy → live URL.

Ok, without further adieu: Townie is Val Town's code robot, now back in town next to your code editor. Townie uses the Claude 4.6 family and the Val Town MCP server under the hood. The MCP server can do a whole lot: create, edit, and run vals; read your SQLite, blob, and log data; configure cron, http, and email; read and write environment variables; view history and switch branches; and more. Here we ask Townie to one-shot a "Val Town Square" messaging forum.

Video at 1x speed to offer a realistic sense of Townie. Song credit: Good Time Oldies by Bosley.

Scoped SQLite

As of January, every val gets its own SQLite database . Before that, you got one global database for your org or personal account (and you still do), but now it's a whole lot easier to manage your data. There's also a new SQL admin dashboard for poking around your val's data.

If you've already been using the admin UI, you'll notice some new features this month: now you can create tables and add records with a GUI, and if you're writing SQL by hand (or pasting from an LLM), your query will be saved as you navigate between table, docs, and query views.

Personally, I'm very excited about this one. Previously my vals used the same shared database for newsletter subscriber lists, wiki submissions, and whatever other data I stored. Now each val's data lives sensibly in its own silo, and the query interface lowers the friction to quickly explore data.

Also, coming soon: val-scoped blob storage.

TypeScript language server

The TypeScript code editor in Val Town now runs Deno's official Language Server for faster and more accurate type information. The CodeMirror language server and full server+client+proxy Val Town LSP are open source, and Wolf wrote a great blog post about it if you're curious to learn how it works.

Val Town Teams

Teams launched last year so that you can bring Val Town to work. Teams comes with features for your organization like environment variable groups, val-scoped API tokens, val-scoped OAuth connections, blob management, custom domains, val ownership transfers, member management and invites, public profiles, version control/history/branching, and more. Companies like Kilo Code, Preston-Werner Ventures, and Turso are collaborating on customer support agents, deal pipelines, customer leads, and the like.

With the explosion of agents in 2026, we're noticing Teams customers beyond the eng team editing vals. One customer noted that Val Town is a perfect platform for engineers and business people to collaborate because the biz team can easily update prompts and see changes deployed immediately without waiting on engineers, and the eng team can customize the code to their liking.

And much more

Here's an unordered, incomplete list of other new features in Val Town:

• Pin vals to your profile page
• Change your account handle up to 5 times
• Connect to Slack or Google from a val
• .json , .css , and .txt files supported as val files
• Download vals as ZIP files
• Download val files individually
• Export environment variables as .env file
• Copy environment variables when you remix your own val
• 3x faster SQLite, average latency down from 35ms to 10ms (thanks Turso)
• New onboarding steps for org setup
• Val READMEs support Mermaid diagrams
• Docs guide for adding auth to your val
• Docs guide for building a Slack agent
• Go to definition for any symbol in your code
• DenoLS resolves and type-checks imported private vals and modules
• Search and replace in branches
• Search results link to source line
• Better code search (cmd+k)
• cmd+s saves globally (not just when the editor is focused)
• cmd+shift+f maps to project search
• Live HTTP preview pane floating in or alongside the editor
• Markdown preview pane alongside the editor (cmd+return )
• Full-page Logs view for a val
• Render multi-line logs
• Linkify stack traces in logs
• Query val logs via API /v1/logs
• API endpoints for managing environment variables
• Browser-based device auth for vt CLI
• Manage OAuth client connections in Settings
• Include merge commits, PR links, and Townie edits in val History
• View diffs between val versions from History
• View Townie chat history in Settings
• Townie model picker to choose between Haiku, Sonnet, and Opus
• Show Townie diff view before approving/denying edits
• Let Townie run vals
• Townie's "4 C's": commands for /cost, /compact, /context, /clear
• As an aside^, why do so many AI things start with C? Claude Code, Codex, Cursor, context...
• Attach images to Townie chat
• Fullscreen Townie mode (new!)

Val Town Party

If you live in or around NYC, swing by our headquarters this week! We're having a party at the Val Town office in downtown Brooklyn on Thursday.

Val Town Hall

Speaking of community hangouts, last summer we had a Val Town Hall where we opened up the floor to community members demo'ing vals they'd made (for business or pleasure) and talked about our roadmap. This spring, we're bringing it back (date TBD).

Reply (1) if you're interested in presenting or attending, and/or (2) if you have requests or ideas about what should be on the meeting agenda.

Talk of the Town

My favorite part of the old newsletter was the community vals section, which you'll now find in Talk of the Town . In February we highlighted:

• vals in the atmosphere (read: atproto/Bluesky)
• a Valentine's val (Val) , (dubbed "Valentown" in one email reply)
• a literal laundry val
• a Helium Hotspot val
• a moon phase val

and dozens of other neat vals you all wrote

Share your vals in our Discord #showcase or on Bsky/X/HN/etc to be included in the upcoming March issue.

BYOA—in Val Town or elsewhere

Yesterday morning I wrote a Slack agent in Val Town using Vercel's AI SDK, and yesterday afternoon it became obsolete.
Just after I'd written a docs guide and recorded a demo video, I saw the announcement: "Today, we're open sourcing the new Chat SDK in public beta." By this morning, I learned that the Chat SDK, which paves Vercel's new Slack bot happy path, has already been renamed to "Chatbot." What will happen tomorrow? Or next week? Heaven forbid you go on a family vacation.

I'd written my Val Town agent—named duck, as in rubber duck debugging—and accompanying guide based on Vercel's now-stale Slackbot Agent Guide. That guide and its companion repo—last commit 8 months ago, an eternity in AI Land—uses the AI SDK v4. But they're already on v6. If even they were two versions behind on their own framework, imagine where that leaves the rest of us.

Just about every software vendor you use has their own AI agent with a punny, on-theme name.¹ (Not to throw stones or anything—at Val Town we have Townie.) All those bespoke agents will always be behind, using yesterday's framework or model. It's ok to be behind ("if it ain't broke..."), but you should control when you are behind and when you want to catch up. You should Bring Your Own Agent.

BYOA—in Val Town or elsewhere

I've found Val Town to be quite a good place to write and run code, including agents. I thought so for two years as a regular user, and I think so now that I've been working here a couple months. It's "a nice place for JavaScript," as one of our users recently put it. But before I tell you why I think it's good, I should say: you may prefer to BYOA elsewhere, which is just as well. I don't know what tools you're familiar with and what you prefer. The important thing is that your agent answers to you—not your vendor.

Val Town is designed to have credible exit, meaning if you ever want to move your code elsewhere, you can do so easily. You can credibly exit. It's anti lock-in. Just like how when you own a domain name, you can transfer it to another registrar, or move your website hosting between providers, or change email clients. Val Town code runs on the Deno runtime and emphasizes Web-standard and mature technologies: JavaScript (or TypeScript), npm packages, SQLite, et cetera. So if you BYOA in Val Town, you can later port it over to Vercel or Netlify or AWS, or wherever.

Now, I like building agents (and many other things, but not everything) in Val Town because it removes the deployment step, such that I don't even think about it. Vals auto-deploy on save in 100ms, and you get a live URL. The feedback loop is very fast. There's no local versus staging versus prod environment (although there is branching for safe code changes). When collaborating with coworkers or sharing code with friends and strangers, there's no local dev setup—instead, they just remix your val or create a new branch. At this point in the paragraph my salesiness barometer is reading too high, and it'll probably only get worse in the next section about Kilo Code's agent val, so I'll transition by saying: it's totally reasonable if you want to BYOA on [insert hosting provider here]. I like Val Town, but YMMV.

Case study: Kilo Code's customer support agent

Last week, Steve (and Townie) from our team and Alex from Kilo Code set aside 8 hours to get a customer support bot² agent up and running on Val town. But they only needed 89 minutes.

I watched a recording of Alex and Steve's meeting to inform my work on the aforementioned Slack agent. It really was, like, surprisingly easy. Here's some verbatim dialogue from the crux of the meeting, screenplay-style (stage directions added):

[image: screenplay.png]

The point this scene is supposed to illustrate is that setting up the agent was easy, even fun. But the more important, practical point that you can rehearse and repeat to your boss (or your boss's boss) in the architecture meeting next week is what Alex wrote about in his blog post:

"Every SaaS platform you use is shipping an AI agent add-on right now. Your support tool has one. Your CRM has one. Your project management platform probably just announced one last week. They all cost $500–$1,000/month. They’re all black boxes. And if your experience is anything like ours, they mostly don’t work."

And these black box SaaS agents won't obviously be a hot mess, not at first. They'll boil you slowly, like a frog. Of the customer support agent that Kilo Code tried for a month before BYOA'ing, Alex wrote:

"It wasn’t bad enough to reject on day one — it was bad in the slow, corrosive way that wastes your time: almost good enough, but never quite right, and no levers to pull to fix it."

So Kilo Code rolled their own agent with Val Town and the Kilo Code AI Gateway. Tomorrow or next week or next month, when a new model or better tools come out, they'll be in control.

BYOA

"Bring Your Own Agent" (not a new term, btw) feels like the right pattern for this build-don't-buy moment, and Val Town might be the right place to do it. But again, I don't want to oversell. We are pickling compute, and BYOA is the new flavor. Chances are your company is already (or will soon be) hiring agents to work alongside you: for customer support; for data analytics; for fraud detection; for code review; for lots of things. Maybe you'll build them on Val Town.

Footnotes

• (1) As far as punny AI agent names go, I think Gusto's Gus is pretty damn good. I like Townie, too. But my favorite robot name, hands down, is Kroger's inventory-taking robot, Tally.

• (2) Here, and everywhere in this post, I mean "agent" as in Simon Willison's definition: an LLM running in a loop with tools—definitely not agent-as-human-replacement.

Code example

Using the std/sqlite val to access the val database:

import sqlite from "https://esm.town/v/std/sqlite/main.ts";
await sqlite.execute('CREATE TABLE IF NOT EXISTS "docs" (contents TEXT)');
await sqlite.execute('INSERT INTO docs (contents) VALUES ("Hello, world!")');

Demo

With the built-in SQLite browser you can:

• Add and rename columns
• Delete rows
• Get the schema of any table
• Run queries
• Export tables as CSV
• Dump the database as SQL

History

In 2023 we launched SQLite for every Val Town user, powered by our friends at Turso. Vals could use the database with zero configuration and total control. A lot of the most interesting vals are built on this - my Bluesky ThinkUp Tribute val uses SQLite to store people's social media bios, and devstats uses the database to track statistics about our repository.

But because databases were scoped to users and organizations, they contained intermixed data: it's impossible to tell a priori which data came from which val. Scoped databases fix that problem, eliminating conflicts between different vals and making it easy to just browse val-specific data.

Security

We've designed scoped databases to be more secure, too: vals can only access their own scoped database, and can't reach across to access data from other vals. This makes it a lot safer to work on SQLite databases too, because your schema changes can't affect any other vals.

Under the hood, we've added project-scoped API tokens to make this work: each val automatically gets a temporary API token as the VAL_TOWN_API_KEY environment variable. That API token has always belonged to a user, but now it belongs to a val as well, which gives it specific val superpowers.

Existing databases will stick around

We're supporting both val-scoped and user-scoped databases for the long term: there are uses to both, and there's no reason to force everyone into a gnarly upgrade path. But val scoped databases are definitely recommended for new projects: they make a lot of things easier, and come with a powerful UI.

Thanks Turso for the continued collaboration!

We've provisioned thousands of databases and this will add even more - but it's possible because Turso runs SQLite in the cloud. This feature really relies on some tricks from Turso too, like forking databases by seeding from point-in-time backups.

We’re hiring!

Join our team and help build the future of programming.

Townie's back!

Townie's back! In its 5th version, Townie, our AI agent, lives alongside your code editor, powered by the Claude 4.5 family and our carefully crafted tools.
Townie is like Claude Code, but in the browser, optimized for Val Town's simple and instant runtime.
Here we ask Townie to scaffold this very blog post:

Like every edit in Val Town, Townie's changes are instantly deployed live on the internet at a URL (or a branch-preview-URL) in 100ms.

What can Townie do?

Townie can take almost any action that you as a user can take:

• List, search, & create vals
• Read, write, & run files
• View history, create & switch branches, revert versions
• Query your SQLite databases & Blob storage
• Read & write environment variables
• Read logs
• Read & configure cron jobs

Because Townie has so much context, you can ask it to one-shot whole features or even full-stack apps. Or remix one of our templates. Townie gets the same tight feedback loop that Val Town users get:

1. Edit code
2. Automatically deployed live in 100ms
3. Run the code
4. View the output
5. Read the logs
6. Keep iterating until done

You can rely on version history and branching to move fast without breaking things, along with Townie's chat history to pick up where you left off.

Modes

We're using the latest models in the Claude 4.5 family — Haiku, Sonnet, and Opus — with three modes:

1. Normal: Townie asks you to approve before writes
2. Plan: Townie as your read-only thinking partner
3. Allow all edits: Townie YOLOs changes to your vals

System prompt

Townie knows Val Town inside and out. Our system prompt is public (still), and it doubles as a great "101 intro to Val Town."

Keyboard shortcuts & slash commands

As a power user, you can open Townie with ⌘J and use slash commands:

• /cost Show estimated cost and usage
• /context Show context window usage
• /compact Summarize older messages to save context
• /clear Start a new chat

Townie is writing ~50% of my code

Before Townie v5, we didn't think we needed an in-browser AI agent. We wanted to thoughtfully craft a good MCP server and let you the developer stay where you are (in your favorite AI coding tool). And we did. And you can!
But MCP clients just aren't good enough yet, so that experience often falls short. Our customers asked for a good in-browser AI agent. Honestly, we as users of our product wanted this too. And it's pretty great! I use Townie v5 a lot now. Sometimes I use it for vibe coding (for prototypes or simple things), and other times I keep it on a tight leash (for stuff I care about).
It's fun and productive – give it a try!

Try Townie

Townie is available in public beta for Pro and Teams customers, so you can try it for $10/mo.

Thanks to Pete for helping me write this and crafting the lovely Townie doodle at the top.