DEV Community: Lucas Swanson

How I Keep My AI Coding Agent Costs Down as a Student

Lucas Swanson — Mon, 10 Aug 2026 14:31:06 +0000

I graduated from undergrad the year that ChatGPT was first released to the public, and I'm now applying to Master's programs for the Fall. As we inch away from the educational realm I knew, an era ruled by StackOverflow and Chegg, I can't help but think how different my learning path would have been had I had access to these tools back then. Depending on your self-control, AI can either give you a competitive edge, even over others using LLMs for everyday tasks, or it can sneakily lead your learning to a plateau.

But, with great power, comes great responsibility. And no, I'm not just talking about the learning cost of using AI maliciously in an academic context (i.e. cheating on exams or labs), but also in financial cost. Every prompt, response, and tool call burns tokens, and tokens cost money. And given the control Chipotle had over my bank account in college, I was sticking to free tiers wherever I could. I assume you are too.

For the money you can spare, however, AI coding agents can build complex apps, explain concepts, and create study resources to help you reinforce your learning. Well-scoped prompts, frugal model choice and appropriate MCP server usage can use a tenth of the tokens of a rambling prompt, maximizing value per request and stretching out that usage window each month.

After applying to some Master's programs, and coding extensively in conjunction with editors like Kiro and Claude Code, I've settled on a few habits that postpones that dreaded "Try again tomorrow at 5:30pm" message in my chat window. Here's three of those habits.

1. Prompt Engineering (Yes, it's a real skill)

When LLMs first started gaining traction and people started talking about "Prompt Engineering", it felt like a snobby title. I thought "you know what chatgpt is, and you know how to write... so what?". Comedians were going on Jimmy Kimmel saying they asked ChatGPT what it thought, my roommate was asking ChatGPT how to make a comeback to my joke... it just seemed like people considered them more technical for knowing how to ask a genie a question.

But this is 2026. Models are smarter, MCP reduces model guesswork, and the software industry is innovating faster than ever. As such, there is MUCH to be gained in reducing your token usage, and Prompt Engineering encompasses that first critical skill; accurately and concisely structuring your request.

With that in mind, the most expensive prompt is one where the agent has to guess. So, when prompting, you should...

Show up with a plan, not a blank page. I don't ask the agent to design my whole system if I already know roughly what I want. If my assignment calls for a REST API with a database and a couple of endpoints, I say that directly. I don't make the agent spend tokens rediscovering decisions I've already made in my head.

Say what you're sure about, and flag what you're not. If your class requires Python and Flask, say so up front. If you genuinely don't know whether to use SQLite or Postgres for a small project, say that's the part you want the agent's input on. This tells the agent where to just execute and where to actually reason, and reasoning costs more tokens. "Build me an app" forces the agent to guess at dozens of small decisions and explain each one. "Build me a Flask API with these three routes, and suggest the best way to handle rate limiting" puts the expensive thinking exactly where you need it and nowhere else.

When I'm unsure which tool is best, I'll just do some research with Gemini to try and make a decision before asking my coding agent.

Compress your prompt with a free model first. Before sending a long, complicated prompt to your paid agent, paste it into a free-tier model (ChatGPT's free tier, Gemini, whatever you have access to) and ask it to tighten the prompt without losing any meaning. You're paying by the input token, so a shorter prompt with the same information is money back in your pocket.

Shape your prompt around the MCP tools you can enable.
MCP serves as a structure to streamline repeatable actions you expect your agent to take. Skills are contextual instructions, like a ruleset or a workflow, whereas Tools provide pre-written executable functions, standardizing how the agent should perform a task.

Telling your agent which MCP tools and skills to reach for will further reduce the guesswork required to accomplish your task. The difference between "What EC2 instance types fall within my budget?" and "Use the AWS Documentation MCP to identify which EC2 Instance Types fall within my budget" may be semantically minor, but it removes the need for the agent to parse it's entire MCP library, and that habit compounded over dozens of sessions will save you significant amounts of credits.

2. Match the Model to the Job

Not every task needs the most powerful model available. Picking the right model for each task is the simplest way to optimize your inference spending.

Look up how the models compare on your current task. Benchmarks like SWE-bench and HumanEval show which models are strongest at writing and debugging code versus which ones are better at prose. Know the strengths of whatever models you have access to.

Check what each model actually costs you. In Kiro (an AI coding IDE), for example, you can see how much credit each model uses relative to "Auto" mode, which picks a model automatically based on how complex your prompt looks. Auto is convenient when you're not sure, but knowing the relative costs lets you choose deliberately when you already know the task is simple or hard.

A frontier model (like Claude Opus 5, GPT Sol) is worth the extra cost for multi-file projects, tricky debugging, or anything where the agent needs to hold a lot of context at once. Yes, it costs more per token. But a wrong implementation that takes three rounds of fixing costs more overall than getting it right the first time.
A lighter model (like Haiku) is plenty for writing docs, generating boilerplate, drafting a README, or formatting code. These tasks don't need deep reasoning, and a cheaper model handles them just as well.

The rule of thumb: if the task requires the agent to think, use a strong model. If the task just requires the agent to type, use a cheap one.

3. MCP Tools: Let the Agent Check Instead of Guess

Model Context Protocol (MCP) servers are probably the most overlooked way to cut costs. An MCP tool gives your agent direct access to real information (documentation, live APIs, code search) instead of making it guess based on whatever it remembers from training.

Without a tool, an agent has two options when it needs a fact it doesn't have memorized: guess and risk being wrong, or ask you and burn your time and more prompt tokens. An MCP tool call is cheap: a quick lookup that returns the exact right answer. Compare that to the alternative, where the agent writes a plausible-looking but wrong API call, you catch it, you explain the fix, and the agent tries again. That round trip alone can cost four times as many tokens as just looking the answer up in the first place.

Two that I use regularly:

AWS Agent Toolkit gives your agent additional tools to improve it's efficiency. Enable your agent with direct search access to current AWS docs, drastically improve your agent's ability to build AWS applications, and more.
Strands MCP helps your agent build other agents. If you're working on a multi-agent project, this saves you from having to paste boilerplate framework code into context repeatedly.

A single documentation lookup might cost a few hundred tokens. The alternative (wrong answer, correction, retry) easily runs into the thousands. Over a semester of daily use, that adds up fast.

Keeping an Eye on What You're Spending

The three habits above reduce cost. This last one is about actually seeing it, because you can't fix what you can't measure.

Kiro's dashboard updates every few minutes and shows your credit usage against your monthly pool, plus a per-interaction cost right in the notification bar. For more detail on credit usage and limits, you can use the '/usage' Kiro command. Use the following command in the Kiro CLI:

/usage

Try running this in a separate terminal while you work.

Once you've watched your usage for a week or two, predicting cost gets easy. Kiro's Auto mode is the baseline (1x), and other models are published as multipliers against it, so if a task usually costs half a credit in Auto, you can estimate what switching models will cost before you commit. You'll also start noticing patterns: a quick bug fix costs one thing, building a whole feature costs several times that, and pasting a 500-line file into context costs more than pointing the agent at the 30 lines it actually needs (roughly one token per four characters, as a rule of thumb).

The Point of All This

Overall, the name of the game is to reduce your agent's guesswork. Every design decision you make concretely, every MCP tool you set up, and every unnecessary word you eliminate from your prompt all reduce the amount of inference your agent has to perform (and charge you for) to complete your task.

You end up with the same quality of work for a fraction of the credits, which matters a lot more when you're working on a student budget as opposed to an enterprise. Employing these skills in your project will position you well for a software industry where AI is critical infrastructure.

Thanks for tuning in.

EC2 101: Servers-as-a-service

Lucas Swanson — Wed, 18 Mar 2026 19:10:01 +0000

When I first started on AWS, I struggled to understand virtual compute. I picked T3 micro for everything because it was cheap, and for most use cases, it did the job. Sticking to one type of EC2 instance, however, is like picking one screwdriver size from your toolbox for everything... it may work for several projects, but you're creating more work for yourself if you don't select the right tool for the job. Now, I can't just select a random instance for my projects. I actually need to know what these instance types mean.

EC2 is the foundation of almost everything we build on AWS. The decisions we make in those first five minutes from considering instance types, security groups, storage, and networking will heavily influence the success of our projects. By the end of this article, you'll understand when EC2 can be useful in your projects AND be able to spin up EC2 instances for your use cases.

What is EC2?

EC2 stands for Elastic Compute Cloud. At its core, it's a virtual server running in an AWS data center. Think of it like a “server rental”, where you can shop pre-built servers designed to host specific types of applications, then “rent” space on those servers as needed. Rather than a virtual server or machine, we call it an instance. When you launch one, you pick the specs, you pick the operating system, and then you can be up and running in minutes. The elastic part is what's really key here. You can add computing resources to, remove computing resources from, or launch hundreds of instances on demand.

You may be comfortable with your current setup, however, given that you've been able to build hobby projects with no trouble. So that begs the question...

Why should I use an EC2 instance instead of running my app locally?

Think about the town that you live in, and what methods of transport you use. You may drive a car for daily transit, ride a motorcycle to save money on gas and take it for joyrides, or use a moving truck when you’re moving between homes. Do you personally own and maintain a car, motorcycle and a moving truck? Maybe you would if you owned a moving business, needed a daily driver for running errands, and enjoyed riding a motorcycle for fun. Most people, however, rarely use a moving truck, and some don’t even drive a car if their city has good public transit. Those folks wouldn’t own the moving truck... they would just rent it for the time they need it.

Imagine that you’re building a house on an empty plot of land. You’ll need some heavy equipment to build that house, including an excavator to dig the foundation, a crane to lift scaffolding, maybe a concrete mixer to lay a base layer for the house to sit on. Would you buy the excavator, crane, and concrete mixer outright, use it to build the house and just... keep them around? I’d bet that you’d rather just rent the equipment for the time you need it.

That’s what you’re doing when you spin up an EC2 instance. Lets say you’re training a machine learning model, and you only have access to a laptop with minimal graphics capacity... not very strong computing power, which is essential for fast model training. Would you buy a whole new computer to train these models, or would you rent access to an existing server for the exact computing time and computing capacity your model needs to be trained? If you chose the latter, EC2 provides that service.

EC2 has many instance types, each built for different types of workloads. EC2 can also scale automatically depending on how much traffic or compute power you demand from it. Your laptop, on the other hand, can’t install more graphics cards into itself instantly when a program bottlenecks it’s capabilities.

Now, before we launch our own EC2 instance, let me break down six key components you need to know about.

Amazon Machine Image (AMI): The Amazon Linux AMI is a maintained Linux image provided by AWS for use on Amazon EC2. It offers a stable, secure environment for running applications and includes packages for easy AWS integration, such as launch configuration tools and popular AWS libraries. AWS provides ongoing security and maintenance updates for all instances running the AMI, at no additional charge to EC2 users.
Instance Type: This is your instance's hardware specs. It defines the CPU, memory, storage, and network. We'll dive deeper into this later in the demo.
Key Pairs: With this you're able to authenticate and connect to your instance via SSH or RDP. If you are using Windows, when you use a key pair, AWS holds the public key. You hold the private key, but remember to always store this safely. Losing it can mean that you're locked out of your instance.
Security Groups: You can look at these as a stateful firewall that controls traffic that goes in and out of your instances.
Networking: This is a component that we need to discuss without going too deep. Here's what you need to know when it comes to networking on AWS. The Amazon VPC, or Virtual Private Cloud, allows you to configure subnets where you launch your instances into. These subnets can be public or private, with public subnets having a route directly to an internet gateway and private subnets not exposed to the internet. Within the VPC, you have full control over how you configure this. If you're interested in knowing more about the Amazon VPC, let me know in the comment section below.
EBS Volume (Amazon Elastic Block Store): This is a separate disk or storage that persists independently from your instance. We'll discuss why this matters later in the demo.

In this demo, we're going to launch an EC2 instance as a web server that we can connect to from the internet. To connect to the instance, we'll use Session Manager, a fully managed service that provides secure, auditable, and browser-based remote access to your EC2 instances. This means we won't need a key pair. To make this work, we first need to create an IAM role.

Part 1: Create an IAM Role for Session Manager

In the AWS Console, search for "IAM" and open the IAM console.
Click on "Roles," then click "Create role."
For the trusted entity type, select "AWS service."
Under use cases, select "EC2." Then select the additional use case "EC2 role for AWS SystemManager." This will allow us to connect to our instance via System Manager.
Click "Next." You'll see the policy that is already attached to this role. This is what allows browser-based access to your instance.
Click "Next" and enter a name for the role. We'll use ec2-ssm-role.
Verify the policy is attached in Step 1: “Select trusted entities” and click "Create role."

Part 2: Launch the EC2 Instance

Back in the AWS Console, ensure you are in the correct region. Select the region closest to you or your users. For example, if you're on the West Coast, select "US West 2 (Oregon)." If you're on the East Coast, "US East 1" may be a better fit. Remember, you want to select the region that will be geographically closest to your users as possible, whether that's you or your user base, to lower the latency for the average request.
Search for "EC2" and open the EC2 console. Click "Dashboard" in the left side menu.
Click "Launch Instance".
Enter a name for your instance. We'll use My First Instance.
Under "Application and OS Images," select "Amazon Linux." This is the AMI we will use for this session, and it provides all the AWS tools and features we need to work directly with AWS. You can optionally select the architecture (x86 or ARM). We'll leave this as default.
Under "Instance type," you can compare the different types of server. Don’t be intimidated by the instance type names. My colleague Brooke Jamieson wrote a wonderful article demystifying instance type naming conventions in AWS. For this demo, select t2.micro.

This falls under the free tier, which helps save on costs. If you're unsure which instance type to choose, you can click "Get advice," enter your workload requirements (e.g., web hosting, low cost), and AWS will provide recommendations. You can also click "Compare instance types" to view configurations side by side.
Under "Key Pair," select "Proceed without a key pair." Normally, best practice would be to generate a key pair, but for demonstration purposes we will be using SSM instead.
Under "Network settings," use the default VPC. AWS comes preconfigured with a VPC in each region that includes subnets, security groups, an internet gateway, and everything you need to launch instances and connect to the internet.
Under "Security groups," create a new security group. Allow SSH traffic (port 22) from "My IP" so that only your personal computer can access the instance via SSH. You also have the option to add HTTP and HTTPS traffic, but we'll configure that later.
Under "Configure storage," leave the default of 8 GB of EBS. You can increase this if needed.
Under "Advanced details," find the "IAM instance profile" dropdown and select the EC2-SSM-role we created earlier. This is what allows SSM to be accessed from our EC2 instance.
Click "Launch instance."

Part 3: Connect to Your Instance via Session Manager

Click on your instance ID to view its details. You'll see the state is "Running" and the status check says "Initializing." Three status checks need to pass before you can log in. You can also access this info by clicking on the "Instances" option in the left-side EC2 menu.
While waiting, scroll down to the details section. Here you'll see the instance ID, public IP address, private IP address (for access within the VPC), public DNS address, hostname, instance type, and all the configurations we set up.
Once all three status checks have passed, select your instance and click "Connect."
Select "SSM Session Manager" and click "Connect." If the Connect button is grayed out, your instance is not fully loaded yet. Wait and try again.
You're now inside your instance via the browser. Now, we can verify the identity of the users logged in to the instance. To verify, type:
```
whoami
```
You'll see the logged-in user is ssm-user.

Part 4: Install and Start a Web Server

First, update your instance:
```
sudo yum update -y
```
sudo literally means “Super User Do”. This runs the command as a super user. yum is the package manager for Amazon Linux. Think of it like an app store for your instance. update checks for the latest versions of everything installed, and -y auto-confirms so you don't have to approve each update.
Install Apache, one of the most popular web servers in the world:
```
sudo yum install httpd -y
```
Start the Apache web server:
```
sudo systemctl start httpd
```
Enable Apache to start automatically on reboot:
```
sudo systemctl enable httpd
```
Verify that Apache is running:
```
sudo systemctl status httpd
```
You should see the status as "active (running)" and "enabled."

Part 5: Fix the Security Group to Allow Web Traffic

Go back to the AWS Console and copy your instance's public IP address. Paste it into your browser. You'll notice the page doesn't load. You get a blank page or a connection error.
This is because our security group only allows port 22 (SSH). To access our web server, we need to allow port 80 (HTTP). Remember, the security group is a stateful firewall. If we don't allow the traffic, it will be denied.
In the EC2 console, go to your instance's "Security" tab and click on the security group.
Click "Edit Inbound Rules."
Add a new rule: Type "HTTP" (port 80), Source "Anywhere." This means anyone on the internet can access your web server via HTTP. We're not configuring HTTPS here because that requires a certificate.
Click "Save rules."
Go back to your browser and refresh. You should now see the default Apache test page.

Part 6: Customize Your Web Page

Back in your Session Manager terminal, run:

sudo bash -c 'echo "<h1>Hello from EC2</h1>" > /var/www/html/index.html'

This writes a simple HTML header to the Apache default index file.
Go back to your browser and refresh. You should now see "Hello from EC2."

You now have a running, customized web server in the AWS cloud.

Finishing Thoughts

Your discipline and focus have paid off, dear developer. You've created an IAM policy to control traffic, selected an EC2 instance type, started an instance and run your code on an AWS managed server. You can now officially tell your friends you "build software in the cloud". That's pretty cool if you ask me.

I challenge you to build more complex applications using EC2, and try to incorporate new instance types into your architectures. Alternatively, if this is your first step on your cloud journey, I challenge you to migrate a project from a class, club or hobby onto the cloud using AWS services. If you're an advanced developer, consider the AWS Compute Optimizer to brainstorm ideas to optimize your architecture to reduce cost. Most importantly, if there's anything I hope you learned today... it's that Lamborghini's are cheaper to rent.

Until next time,
Lucas