The previous post explained the rationale for moving from direct Anthropic API (Application Programming Interface) calls to AWS (Amazon Web Services) Bedrock. This one builds a working application and migrates it, file by file, so you can follow along and do the same thing.

The whole project is in a public repo: github.com/nealvybe/knockknock-bedrock. Clone it, set up a virtual environment, and run each file to see exactly what changes at each step.

git clone https://github.com/nealvybe/knockknock-bedrock.git
cd knockknock-bedrock
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Then copy .env.example to .env and fill in your credentials. The direct API files need your ANTHROPIC_API_KEY. The Bedrock files need your AWS_PROFILE (or AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) and AWS_REGION.

cp .env.example .env

The app is a knock knock joke generator. You give it a topic, pick a style and an optional character voice, and it writes knock knock jokes. Simple enough to understand in five minutes. Complex enough to show real patterns: multi-turn conversations, prompt caching, and the wrapper abstraction that makes provider migration trivial.

File 1: knockknock.py

This is the starting point. A single-turn joke generator using the direct Anthropic API.

python knockknock.py

Topic: hugs

Knock knock.
Who's there?
Hug.
Hug who?
Hug-ry for some affection!

The code is about 40 lines. An Anthropic client, a system prompt that defines the format rules, and a single API call. The system prompt does most of the work. It tells Claude to only respond with knock knock jokes, to use the traditional format, and to incorporate whatever topic the user provides. Nothing else. No intro, no commentary. Just the joke.

This version takes a topic, makes one call, prints the result, and exits. It works, but it is a dead end. One joke per run. No way to refine, no memory of what it already told you.

File 2: knockknock_v2.py

This version adds three things: style selection (corny, clever, or kid-friendly), an optional character voice, and a conversation loop that remembers what jokes it already told.

python knockknock_v2.py

Topic: puppies
Style (corny/clever/kid-friendly) [corny]: corny
Character (optional, e.g. Yoda, Batman, Gordon Ramsay): Gordon Ramsay

Knock knock.
Who's there?
Puppy.
Puppy who?
Puppy hell, this dog's so raw it's still chasing its bloody tail!

Another joke? (y/n): y
Topic [puppies]: mars
Style (corny/clever/kid-friendly) [corny]: clever
Character (e.g. Yoda, Batman, Gordon Ramsay) [Gordon Ramsay]: Yoda

Knock knock.
Who's there?
Mars.
Mars who?
Mars bars, eat them I do not. Only the red planet, strong with the Force it is!

Another joke? (y/n): n

The conversation history is stored as a list of messages. Each joke the model generates gets appended to the list, so on the next turn the model sees everything it already said and avoids repeating itself. Defaults carry forward between turns. Hit enter to keep the same topic, style, or character. Change any of them to mix things up.

This is still using the direct Anthropic API. Same client, same authentication. If you have an API key, this file runs.File 3: knockknock_bedrock.py

Same app. Three lines changed.

The import switches from anthropic to AnthropicBedrock. The client initialization adds a region and profile parameter. The model ID switches from the Anthropic shorthand (claude-sonnet-4-20250514) to Bedrock’s cross-region format (us.anthropic.claude-sonnet-4-20250514-v1:0). Everything else is identical. The system prompt, the message structure, the conversation loop, the response parsing. All the same.

python knockknock_bedrock.py

Topic: Philadelphia
Style (corny/clever/kid-friendly) [corny]: corny
Character (optional, e.g. Yoda, Batman, Gordon Ramsay): Batman

Knock knock.
Who's there?
Philly.
Philly who?
Philly up the Batmobile, Robin - we've got crime to fight in the City of Brotherly Love!

Same output. Now it is running through your AWS account with IAM (Identity and Access Management) authentication, CloudTrail logging, and consolidated billing.

To run this, you need two things set up in AWS first.

First, enable model access. In the AWS Console, go to Amazon Bedrock, click Model access in the left sidebar, then Manage model access. Check the Anthropic Claude models you want to use and submit. Approval is usually instant.

Second, add the IAM policy. If your application is already using AWS for anything (S3, Lambda, DynamoDB), you probably already have IAM roles set up. Adding Bedrock is one JSON policy attachment.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.*"
        }
    ]
}

Attach that to your existing role and you are done. No new credentials, no separate auth system. The same IAM infrastructure you already trust.

File 4: knockknock_cached.py

One change from the Bedrock version. The system parameter switches from a plain string to a list containing a single object with a cache_control field.

The system prompt in this app is short, so the savings here are small. But the pattern matters. In a production application where your system prompt is thousands of tokens (detailed instructions, style rules, domain context, few-shot examples), prompt caching changes the economics.

The first call caches the system prompt at a small write premium (1.25x the normal input cost). Every subsequent call within 5 minutes reads from cache at 0.1x. For a multi-turn conversation like this joke generator, that means the first joke pays a slight premium and every joke after that gets the system prompt for 90% less.

For longer-lived sessions (agent loops, chat applications), there is a 1-hour cache option at 2x write cost:

"cache_control": {"type": "ephemeral", "ttl": "3600s"}

That pays off after two cache reads.File 5: llm_wrapper.py + knockknock_final.py

This is the file structure we use in production. The wrapper module (llm_wrapper.py) contains a single function called call_llm(). It handles the client initialization, the caching, the model selection. About 30 lines.

The application (knockknock_final.py) imports call_llm and uses it. It never imports the Anthropic SDK (Software Development Kit) directly. It has no idea whether it is talking to the Anthropic API, Bedrock, or anything else. It passes a system prompt and a message list, and gets a string back.

from llm_wrapper import call_llm

joke = call_llm(SYSTEM_PROMPT, messages)

That is the entire integration surface. When we migrated our production system from the direct API to Bedrock, this wrapper was the only thing that changed. Claude Code made the edit in the wrapper file. We tested it. It worked. The rest of the application had no idea anything was different.

This pattern also makes model switching easy. Running Haiku for low-cost tasks and Sonnet for complex ones is just a matter of passing the model as an argument. Adding retry logic, logging, or token counting means changing the wrapper once. Every call in the application benefits without touching any application code.

The progression

Looking at the five files side by side, the diff between each step is small:

File 1 to File 2: add the conversation loop, style, and character inputs. File 2 to File 3: change the import, client, and model ID (three lines). File 3 to File 4: switch system from string to list with cache_control (one structural change). File 4 to File 5: extract the LLM call into its own module (architectural, not functional).

Each step is one concept. No file introduces more than one new idea. You can diff any two adjacent files and see exactly what changed and why.

The repo is at github.com/nealvybe/knockknock-bedrock. Clone it, follow along, and you will have a working Bedrock application in about 15 minutes.

Most people who use Claude interact with it in one of two ways: the website at claude.ai, or Claude Code in the terminal. Both are products built by Anthropic. You type something, Claude responds. The infrastructure behind it is invisible.

When you start building software that uses Claude, the relationship changes. You are no longer a user. You are a developer making API calls. That distinction matters more than it sounds like it should, because it changes how you pay, what you can control, and where the compute actually runs.

This post explains the path from using Claude as a consumer to running it as infrastructure through AWS Bedrock, and why we made that shift.

The API layer

The Anthropic API is how developers send prompts to Claude programmatically. Instead of typing into a chat window, your code sends a request to Anthropic’s servers with a prompt, a model name, and some parameters. The response comes back as structured data you can parse, store, or pass along.

Setting up is fast. You create an account at console.anthropic.com, generate an API key, and start making calls. The Python SDK is a few lines:

import anthropic

client = anthropic.Anthropic(api_key="your-key")
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explain what an API is in one paragraph."}]
)

You pay per token. Inputs and outputs are priced separately. As of March 2026, Claude Sonnet 4.6 costs $3 per million input tokens and $15 per million output tokens. Claude Opus 4.6 is $5 and $25. Claude Haiku 4.5 is $1 and $5.

For prototyping, this is all you need. You can build a working AI feature in an afternoon. The limitations show up when you move toward production: managing API keys across environments, monitoring costs outside of Anthropic’s dashboard, needing models from other providers, or wanting enterprise controls around what the model can and cannot say.

What Bedrock is

Amazon Bedrock is AWS’s managed service for running foundation models. It is not a model. It is a layer that sits between your application and multiple AI providers, including Anthropic (Claude), Meta (Llama), Mistral, Cohere, AI21 Labs, and Amazon’s own Nova models.

When you call Claude through Bedrock, the request goes through AWS infrastructure. The model is the same. The responses are the same. But the billing, authentication, logging, and networking all run through your AWS account.

The benefits go beyond convenience.

Multi-model access. Bedrock gives you one API surface for every supported model. If you want to compare Claude Sonnet against Llama 3 against Mistral Large for a specific task, you change the model ID in your code. You do not manage three separate API keys, three billing relationships, and three sets of documentation. For a team evaluating which model works best for which task, this saves weeks.

AWS integration. If your infrastructure already runs on AWS, Bedrock plugs in natively. Authentication uses IAM roles instead of API keys. Logging goes to CloudTrail. Monitoring goes to CloudWatch. Your AI spend shows up on the same AWS bill as everything else. For teams that care about security or compliance, this consolidation matters.

Guardrails. Bedrock has a built-in guardrails system that lets you define content policies for your application. You can block specific topics, filter harmful content, redact personally identifiable information from inputs and outputs, and set up automated reasoning checks that validate model responses against factual rules. These are configurable per application. Instead of building your own content filtering layer, you define policies and Bedrock enforces them before the response reaches your user.Knowledge Bases. Bedrock offers managed Retrieval-Augmented Generation (RAG). You point it at your data sources (S3 buckets, databases, documents), it handles the indexing, chunking, and embedding. When your application makes a call, Bedrock retrieves relevant context from your data and includes it with the prompt. This is the same pattern teams build manually with vector databases and embedding pipelines, but managed as a service. Guardrails can be applied to knowledge base responses as well.

Prompt caching. Both the direct API and Bedrock support prompt caching, but the feature becomes especially valuable at scale. Caching stores the processed version of your prompt prefix so repeated calls with the same system prompt do not reprocess those tokens. The first call writes the cache. Every subsequent call that hits the cache pays only 10% of the normal input price for those cached tokens. For applications making hundreds or thousands of calls with the same base context, the savings are significant. Bedrock added 1-hour cache duration in January 2026, which works well for sustained agent loops and multi-turn conversations.

Credits. AWS Activate provides cloud credits to startups. These credits apply to all AWS services, including Bedrock. Which means your Claude API calls, if routed through Bedrock, can be paid with credits instead of cash. For early-stage companies, this changes the math on whether AI features are affordable to build.

What made the migration easy

Two decisions we made early turned this from a project into a task.

First, we had abstracted all LLM calls to a single function. Every part of the application that talks to Claude goes through one wrapper. When it was time to switch from the direct Anthropic client to the Bedrock client, there was one function to change. Claude Code made the edit in minutes. No regressions, no missed call sites, no compatibility issues. If your LLM calls are scattered across your codebase, the migration is harder. If they go through one function, it is a find-and-replace.

Second, our application was already running on AWS with IAM-based authentication. Adding Bedrock access was just attaching a new JSON policy to the existing IAM role through the console. No new credentials to manage, no new authentication flow to build. The permissions were additive, not architectural.

If you are building an AI application and thinking about this move eventually, those two things (a single LLM wrapper function, and AWS IAM already in place) are worth setting up now even if you are months away from needing Bedrock.

The trade-off

Bedrock is not always the right choice. New Anthropic features (extended thinking, new model releases, MCP support) tend to land on the direct API first and arrive on Bedrock weeks or months later. If you need the latest capabilities on day one, the direct API is faster.

The setup is also heavier. What takes five minutes with the Anthropic API (generate a key, install the SDK, make a call) can take an afternoon with Bedrock if you are new to AWS. IAM roles, service permissions, region selection, model access requests. For a quick prototype, the overhead is not worth it.

The way we handle this: prototype on the direct Anthropic API, deploy through Bedrock. The actual code change, when it comes, is two lines in one function.

Where Vybe fits

Vybe Capital is an AWS Activate Provider. That means startups in the portfolio can apply for Activate credits through the partnership. The credits apply to all AWS services, including Bedrock. Beyond credits, Vybe provides guidance on the infrastructure decisions described in this post: when to use the direct API versus Bedrock, how to structure LLM calls for easy migration, how to set up caching and guardrails.

The next post walks through the practical setup, step by step, with a working example you can run yourself.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

The last post built ParkPulse: a single-file HTML prototype, encrypted with StaticCrypt, deployed to GitHub Pages behind a password. This post shows how to update that same site with one prompt.

The file on GitHub Pages is AES-encrypted ciphertext, so it cannot be edited in place. The workflow is: clone the repo, decrypt the HTML, edit, re-encrypt with the same password, commit, push.

What you need

1. The live site from the first post (or any StaticCrypt-encrypted site on GitHub Pages)

2. A paid Claude account with the Claude desktop app and Cowork mode enabled

3. A GitHub Personal Access Token with write access to the repo (see the previous post if you have not set this up)

The prompt

I opened Cowork and pasted this:

I have a live site at nealvybe.github.io/parkpulse-proto that's encrypted
with StaticCrypt (password: pulse2026). The source repo is
github.com/nealvybe/parkpulse-proto. Clone the repo, decrypt the index.html,
and add an "About" page to the top navigation menu. The About page should
describe ParkPulse as a product: what it does, who it's for, and a short
team section with three fictional team members (names, roles, one-line
bios). Match the existing design style and orange accent color. After the
edit, re-encrypt with StaticCrypt using the same password, commit, and
push to GitHub so the live site updates.

The prompt contains everything Cowork needs: the live URL, the password, the repo, the change, and the deploy instruction.

What Cowork did

Step 1: Clone. Standard git clone. The repo contained the encrypted index.html (99KB) and a README.

Step 2: Decrypt. First error. StaticCrypt’s decrypt command failed because the repo had no .staticrypt.json config file. That file stores the salt used during encryption. Without it, the decryptor cannot reverse the process.

Claude solved this by reading the encrypted HTML directly. The StaticCrypt config object is embedded near the bottom of the encrypted output, including the salt:

"staticryptSaltUniqueVariableName":"515fd507a794550948cb85bd91e23474"

Claude extracted that value and passed it to the decrypt command explicitly. The original 825-line prototype came back intact.

Step 3: Edit. Claude modified three parts of the decrypted file:

• An About link added to the navigation bar

• A block of CSS for the About page (hero, feature grid, team grid, avatar circles, responsive breakpoints)

• The About view HTML: product description, audience paragraph, three team member cards

The existing showView() function did not need changes. It was already written to match view names to element IDs dynamically, so adding a new view only required adding the HTML with the right ID. The file went from 825 lines to 988 lines — 163 lines added.

Step 4: Re-encrypt. Same password, same StaticCrypt command. The 988-line source became a 112KB encrypted file.

Step 5: Commit and push. Second error. The bare git push failed because Cowork’s sandbox has no stored GitHub credentials. This is the same issue from the first deployment. Claude authenticated by embedding the Personal Access Token in the push URL. Because the token already had write access to parkpulse-proto from the previous session, the push succeeded on the first authenticated attempt.

Step 6: Verify. GitHub Pages redeployed in 36 seconds. Claude loaded the live URL, entered the password, and confirmed the About page rendered. I refreshed the site, typed pulse2026, and saw four nav items instead of three.

What the About page contains

Three sections, matching the existing design:

• A hero with the headline “Built for building operators” and a product summary

• A feature grid (real-time occupancy, revenue intelligence, automated alerts) reusing the landing page’s card style

• An audience section naming the three target segments: commercial real estate operators, property management firms, municipal parking authorities

• A team section: three fictional team members — Maya Reeves (Co-founder and CEO), James Kowalski (Co-founder and CTO), Sofia Patel (Head of Product) — with orange avatar circles, roles, and one-line bios

Home, Dashboard, Revenue, and About all navigate correctly. Same password, same URL.

What was different from the first deployment

The first deployment required one manual fix: scoping my GitHub token to the new repo. This update required zero manual actions because that setup carried over. Two errors came up during the run (missing salt config, missing git credentials), and Claude resolved both without prompting me.

Total time from pasting the prompt to verifying the update: under five minutes.

Try it

• Live site: nealvybe.github.io/parkpulse-proto (password: pulse2026)

• Code: github.com/nealvybe/parkpulse-proto

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

We recently went through the agent framework decision at SportChartz. We build trading agents that need to monitor live sports games, detect technical signals, and post alerts to our community. When we started, the natural instinct was to reach for a framework. We evaluated a full-featured open-source agent platform against building directly on an LLM SDK. We ended up on the SDK, but the decision turned on the specific characteristics of our application, not on framework quality. The answer is application-dependent, and the questions worth asking before committing are the same regardless of what you’re building.

The context

During a busy night with 10+ concurrent games across multiple leagues, our system is monitoring game events in real time, evaluating signal conditions every 60-90 seconds and generating content when something fires. It looked like a multi-agent problem: one process watching games, another monitoring social mentions, another reading community chat, another generating content. The path to our decision mattered more than the outcome, because we learned that the right framework depends entirely on what your application actually does.

What’s out there

Agent frameworks sit between your application code and the LLM. They manage the orchestration loop: deciding what tool to call, handling the response, maintaining state, determining the next action. As of early 2026, they roughly fall into three tiers:

Full-featured platforms like OpenClaw provide a complete runtime. Gateway process, channel adapters (Slack, Discord, WhatsApp, Telegram), per-agent memory files, heartbeat schedulers, a plugin ecosystem. You define agents, bind them to channels, and the gateway handles routing. These are essentially operating systems for agents, and they’re powerful when your problem fits the model they were built for.

Orchestration frameworks like LangGraph and CrewAI sit one level down. LangGraph gives you graph-based execution with explicit state machines - define nodes and edges, the framework manages state transitions. CrewAI gives you role-based teams where agents have defined roles and the framework coordinates between them. Both are Python-native and have strong adoption for complex workflows.

LLM SDKs with agent capabilities like the Claude Agent SDK or OpenAI Agents SDK are the thinnest layer. They expose the model’s native tool-use in a loop: the model decides what to do, calls tools, gets results, decides again. Subagent delegation, session persistence, context management are built in, but the outer orchestration logic is yours.

Each tier solves a real problem.

The questions that matter

The decision breaks down along five questions. Your application’s position on each one pushes you toward different points on the framework spectrum.

Trigger type: internal vs. external

Internal trigger means your system decides when to act. A polling loop checks data on a cadence, evaluates conditions, maybe takes action. The timing is yours to control. A timer, a cron job, a scheduled function.

External trigger means something outside your system initiates the action. A user sends a message. A webhook fires. A WebSocket pushes an event. The system needs to be listening and ready to respond.

This is the first dimension because it determines whether you need always-on infrastructure. Full-featured agent platforms with channel adapters and WebSocket listeners are purpose-built for external triggers. They keep connections alive, route inbound events to the right agent, and handle the plumbing of being permanently available. If your application is genuinely event-driven across multiple channels, that plumbing is valuable and building it yourself is significant work.

If your application is internally triggered - running on a cycle, checking data, acting when conditions are met - the always-on infrastructure is overhead you’re paying for but not using. A timer and an API call handle it.

There’s a gray zone. Polling at 60-90 seconds feels like real-time to most users. If someone posts in a community chat and the agent notices on its next cycle 45 seconds later, that’s fast enough for most applications. The question is whether your latency requirement is measured in seconds (event-driven) or minutes (polling handles it).

Our trading agents are internally triggered. They poll on a cycle during game windows. If we wanted them to also respond to community chat messages, we’d add “read recent chat” as another input in the same cycle. The architecture doesn’t change.

Decision type: deterministic vs. judgment

If the trigger logic is “when value X exceeds threshold Y, take action Z” - that’s code. It’s a conditional. Routing that decision through an LLM agent loop means paying for a model to evaluate something a boolean check handles. The LLM adds value when you need it to write the alert, interpret context, or make a judgment call. It doesn’t add value for the threshold check itself.

Most agent frameworks route every decision through the model by design. That’s the ReAct loop: observe state, reason about what to do, act, repeat. For applications where the decisions genuinely require interpretation of unstructured input - reading a customer email and deciding which department to route it to, analyzing a document and determining next steps, interpreting ambiguous user intent - the ReAct loop is exactly right.

For applications where the trigger is deterministic and only the output requires generation, you’re paying the framework’s coordination overhead on every cycle for logic that could be an if statement. The research quantifies this: CrewAI consumes roughly 3x the tokens and runs 3x slower than a direct API call for simple single-tool tasks. That overhead is the framework’s coordination logic, not the model’s reasoning.

The practical split that worked for us: deterministic code for signal detection and threshold evaluation, LLM for content generation and contextual judgment. The two concerns don’t need to live in the same loop.

Cost structure at scale

Token economics at agent scale are different from chatbot scale and worth modeling before you commit to an architecture.

A chatbot handles one request, generates a response, moves on. An agent running a polling loop makes API calls every 60-90 seconds for hours. With subagent delegation, a single cycle can be 3-5 API calls. Over a 4-hour window, that’s 160-240 cycles.

Framework overhead multiplies the per-cycle cost. For the same simple task (single tool call and response), token consumption varies by framework:

• Direct API calls: roughly 150-200 tokens

• LangGraph: under 900 tokens (minimal overhead)

• CrewAI: roughly 2,700 tokens (3x multiplier from coordination logic)

At low volume, the difference is negligible. At scale, it compounds. A million daily executions at the direct API rate costs roughly $300/day. The same million through CrewAI’s coordination layer costs roughly $1,200/day. That’s $27,000/month in framework overhead.

Two levers help regardless of framework choice. Model routing (cheap models for routine scanning, expensive models for generation) and prompt caching (reusing the same system prompt and tool definitions across cycles, cutting costs 50%+ on repeated context). Both favor simpler architectures where the context is predictable cycle to cycle. Our polling loop runs every 90 seconds for 4 hours. The overhead is predictable and avoidable.

Security surface

A full-featured agent framework handles your API keys, social credentials, OAuth tokens, and platform secrets. It’s another system in the chain with access to sensitive material. OpenClaw, the most popular open-source agent framework with over 350,000 GitHub stars, had a January 2026 security audit that found 512 vulnerabilities, 8 of them critical, including OAuth credentials stored in plaintext JSON files. The framework’s creator left weeks later to join OpenAI, and the project was handed to a newly formed non-profit foundation that is still establishing its governance processes. In March 2026, the Chinese government banned state agencies from using OpenClaw over security concerns.

Our agents handle social media tokens, financial API keys, and user authentication credentials. Minimizing the number of systems that touch those credentials is not optional. The thin SDK approach keeps credentials in our code, our infrastructure, our control.

Debugging depth

Every abstraction layer between your application code and the model is a debugging surface. A full-featured framework wraps LLM calls in its own agent loop (ReAct), which internally may use another orchestration library. That’s potentially two agent loops and three abstraction layers between your business logic and the model.

When something breaks, the number of layers determines how quickly you find the problem. Our agents need to post during live game windows. If they stop working at 9pm, we can’t debug until morning. Fewer layers means faster recovery.

How it played out for us

Our application landed clearly on the “simpler is better” end of every dimension. Internally triggered. Mostly deterministic decision logic. Predictable cost structure. Sensitive credentials in the loop. Time-sensitive operations.

We went with the thin SDK approach. Single process, direct MCP tool integration, a time-aware scheduler that adjusts behavior based on the game window. The outer loop is about 100 lines of code. It handles 30+ concurrent games, evaluates confluence across 5 technical indicators, and calls the LLM when it needs to generate content. It runs on a container. The costs are predictable.

The five dimensions, summarized

Trigger type. Internal (polling, scheduled) favors thin SDKs and custom loops. External (event-driven, multi-channel inbound) favors full-featured platforms with channel adapters.

Decision type. Deterministic (thresholds, rules, conditions) favors keeping the LLM out of the decision loop. Judgment-heavy (unstructured input, ambiguous intent, contextual reasoning) favors agent frameworks with ReAct orchestration.

Cost structure. Predictable, high-frequency workloads amplify framework overhead. Bursty, variable workloads make framework overhead proportionally smaller. Model routing and caching help in both cases.

Security surface. Sensitive credentials favor fewer dependencies and thinner frameworks. Sandboxed operations are less constrained.

Debugging depth. Time-sensitive operations favor fewer abstraction layers. Batch operations can absorb more layers in exchange for richer tooling.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.

I wanted to see how far a single prompt could go inside Cowork. Not a chain of follow-ups. Not a back-and-forth where I steer the AI through each step. One prompt, one shot, from idea to password-protected live site.

The product is ParkPulse, a parking garage management dashboard for building operators. I made it up. The goal was to test the workflow, not the concept.

What you need

1. A paid Claude account (Pro at $20/mo or Max at $100/mo) with the Claude desktop app and Cowork mode enabled

2. A GitHub account (github.com, free tier works)

That’s it. Everything else gets set up along the way.

The prompt

I opened Cowork and pasted this:

Build me a single-file HTML prototype for a product called ParkPulse, a parking garage management dashboard for building operators. It should have three views:

1. Landing page with a hero section explaining the product and three feature cards

2. Occupancy dashboard showing 6 garage locations in a city (use Boston) with real-time occupancy percentages, revenue today, and status badges (full, available, maintenance)

3. Revenue timeline showing daily revenue events, rate changes, and capacity alerts in chronological order

Use a light theme with an orange (#ea580c) accent color. No external dependencies. Include search/filter, clickable rows that open a detail panel, and realistic mock data.

After you build it, deploy it to GitHub Pages under a new public repo called parkpulse-proto in my GitHub account. Then encrypt it with StaticCrypt so visitors need a password. Push the encrypted version using git.

Then I waited.

Here’s what Cowork did

About two minutes in, the browser opened and started moving. Claude navigated to GitHub, created a new repository called parkpulse-proto, filled in the description, set it to public, and clicked Create. I watched it happen in real time but didn’t touch anything.

In the background, the terminal was running git commands, installing npm packages, committing files. Claude generated an 825-line HTML file (32KB) with all three views, six Boston garages with realistic data, working search and filter, clickable rows, and a slide-out detail panel. All inline CSS and JavaScript, no external dependencies.

Then Claude encrypted the whole thing with StaticCrypt, running npx staticrypt index.html -p "pulse2026" --short in the terminal on its own. The 825-line prototype (32KB) became an 892-line encrypted file (99KB), with all the original HTML, CSS, and JavaScript baked into an AES-encrypted payload behind a password prompt.

The first git push failed with a 403.

Minor detour: I need to setup a GitHub Personal Access Token

Cowork can create repos and navigate GitHub through the browser, but pushing code from the command line requires authentication. GitHub doesn’t allow password-based git pushes. You need a Personal Access Token (PAT).

To set one up: GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens. Click “Generate new token.” Give it a name, set an expiration, and under Repository access select “Only select repositories” and add the repo you’re deploying to. Under Permissions, grant Contents read and write access. Generate the token and copy it.

Store the token in your git credential manager or pass it as part of the remote URL so that git push works without prompting for a password. GitHub’s docs on Managing your personal access tokens walk through the options.

In my case, I already had a token configured, but it was scoped to a different repo. I edited the token’s repository access, added parkpulse-proto, and saved.

Claude retried and the push went through.

Back to Cowork taking over

After that, the browser navigated to the repo’s Settings page, opened the Pages section, selected main as the source branch, and clicked Save. Then it navigated to the live URL. A password wall appeared.

Claude entered the password, clicked Decrypt, and the full prototype loaded.

The landing page has a hero section with the tagline and three feature cards: Live Occupancy, Revenue Tracking, and Smart Alerts. Clicking “See the Dashboard” switches to the occupancy view.

The dashboard shows summary cards at the top (total spaces, occupied now, revenue today, average occupancy) and a table of six garages with occupancy bars, space counts, daily revenue, and status badges. Post Office Square is at 94% and marked Full. Kendall Square is at 45% and flagged for Maintenance.

Clicking a garage name opens a detail panel that slides in from the right.

The panel shows current stats (occupancy percentage, revenue today, daily rate, monthly rate), garage info (total spaces, hours, manager name, phone number), and recent activity (capacity alerts, revenue milestones, morning rush peaks).

The third view is a revenue timeline.

Events are grouped by date and color-coded by type. Capacity alerts, surge pricing activations, revenue milestones, event rate changes, maintenance notices. Each entry shows the garage name, a description, and the financial impact. Filter buttons at the top let you narrow by revenue events, rate changes, or alerts only.

What came out of it

From a single prompt, Cowork generated 825 lines of HTML, CSS, and JavaScript, encrypted the file with StaticCrypt, created a GitHub repo, pushed the code, enabled GitHub Pages, and verified the live site. The only thing I did was fix a token permission. The whole process took under ten minutes.

You can try the prototype at nealvybe.github.io/parkpulse-proto. Password: pulse2026.

You can view and clone the code at github.com/nealvybe/parkpulse-proto.

In a future post, I’ll show how to make changes to a live encrypted site using the same Cowork workflow.

Neal Foster is Co-Founder & CTO of SportChartz and Founder & Partner of Vybe Capital.