Prompt Performance Mastery: Profiling, Bottlenecks, and Real-World Optimizations

[0:00]Amit: Welcome back to PromptOps Deep Dives, where we unpack the technical realities of building with AI prompts in production. I’m your host, Alex Carter. Today’s episode is all about understanding and improving prompt performance: profiling, bottlenecks, and practical optimizations. If you’ve ever wondered why your prompt feels slow, or how to make it run smoother and cheaper, you’re in the right place.

[1:20]Amit: Our guest is Dr. Maya Choudhury, an AI Systems Optimization Lead at PromptOps Solutions. Maya, thank you for joining us.

[1:30]Dr. Maya Choudhury: Thanks, Alex. Excited to dig into the guts of prompt performance—it’s one of those topics that sounds niche, but can make or break real-world AI rollouts.

[1:45]Amit: Let’s start with your background. What brought you into the world of prompt performance?

[2:00]Dr. Maya Choudhury: Sure thing. My background is a mix of applied machine learning and systems engineering. I spent years building conversational AI products, and I kept running into situations where clever prompts weren’t enough—the real challenge was getting those prompts to perform reliably and fast, especially at scale. That’s what hooked me.

[2:30]Amit: So, not just writing the perfect prompt, but making sure it actually works in production?

[2:40]Dr. Maya Choudhury: Exactly. The best prompt in the world doesn’t matter if your users are staring at a spinner. And with today’s API-driven AI, performance is a moving target.

[3:15]Amit: Why should prompt performance be a top concern for teams right now? Isn’t accuracy the main thing?

[3:35]Dr. Maya Choudhury: Accuracy’s vital, but if your prompt takes four seconds to return, your users bounce or your costs skyrocket. With so many orgs integrating AI into customer-facing apps, slow or unreliable prompts become a real business risk. Plus, cost is tied directly to performance—long prompts, repeated calls, or inefficient chaining can all drive up your bill and hurt the user experience.

[5:10]Amit: Let’s define some terms, so we’re all on the same page. What exactly do you mean by profiling a prompt system?

[5:30]Dr. Maya Choudhury: Good call. Profiling, in this context, means measuring where time and resources are spent as your prompt flows through the system. That might mean timing the API call, tracking how long the model takes, or even seeing where your application code adds delays. It’s about getting a data-driven view, not just guessing what’s slow.

[6:10]Amit: So, it’s like using a stopwatch on every step in the prompt’s journey?

[6:20]Dr. Maya Choudhury: Exactly. And the more granular you get, the better. Even a few hundred milliseconds here and there can add up.

[7:40]Amit: What are the key metrics teams should track when profiling prompt workflows?

[7:55]Dr. Maya Choudhury: The big three are latency—how long a request takes from input to output; throughput—how many prompt calls your system can handle per second; and cost, both in terms of compute and API usage. There’s also error rate, which can spike if you push a system too hard.

[8:40]Amit: Let’s pause and define throughput in plain language.

[8:50]Dr. Maya Choudhury: Sure. Throughput is just how many prompts you can process over a period of time, like requests per second. It matters a lot for teams building chatbots or any high-traffic AI service.

[10:00]Amit: If a team wants to start profiling their prompt system, where should they begin?

[10:20]Dr. Maya Choudhury: Start simple: measure end-to-end latency for a single prompt, then break it down—how much time is spent in your app code, network, the AI model, and so on. Most teams are surprised by where the real delays come from.

[12:15]Amit: What are some of the most common bottlenecks you see in prompt systems?

[12:40]Dr. Maya Choudhury: One big one is model inference time—the time the model spends generating a response. But there are others: slow network calls, unnecessarily large prompt contexts, and chaining too many prompts together. Sometimes it’s just a poorly designed retry loop hammering the API.

[13:30]Amit: Can you give us a concrete example of a surprise bottleneck?

[13:45]Dr. Maya Choudhury: Absolutely. We worked with a team whose chatbot was slow, and they assumed the model was the issue. Turns out, their prompt was calling a user profile service before every AI call, and that service was rate-limited. Profiling revealed that 60% of the latency was outside the AI model entirely.

[14:50]Amit: That’s a perfect segue into our first mini case study. Can you walk us through what happened next with that chatbot project?

[15:10]Dr. Maya Choudhury: Sure. Once we identified the bottleneck, the team switched to caching user profiles for a few minutes at a time. Instantly, prompt response times dropped from nearly two seconds to under 600 milliseconds. The AI experience felt snappy, and their support team was thrilled.

[16:00]Amit: So just by profiling, they saved over a second per request. That’s huge.

[16:10]Dr. Maya Choudhury: Exactly. And they also cut their API costs since fewer calls hit the external service.

[17:40]Amit: Let’s dig into prompt structure for a minute. How does the way you write a prompt affect performance?

[18:00]Dr. Maya Choudhury: Great question. Longer prompts—meaning more tokens—take longer to send, process, and return. Nested instructions or lots of context can also push you closer to model context limits, which may force you to truncate or split calls. Sometimes, rephrasing or slimming down your prompt pays huge performance dividends.

[18:50]Amit: Is there a rule of thumb for prompt length?

[19:00]Dr. Maya Choudhury: It depends on the model, but as a general rule: keep prompts as short as possible while maintaining accuracy. If you’re pushing up against context windows, consider whether all that information is really needed up front.

[20:00]Amit: Let’s talk about caching and prompt reuse. How can teams use these to improve performance?

[20:20]Dr. Maya Choudhury: Caching means storing results of prompts that are likely to repeat, so you don’t need to recompute them. For example, if you have a system prompt that’s consistent across sessions, cache the model’s output. Prompt reuse is about designing prompts so that you can reuse parts or templates, reducing redundancy and complexity.

[21:00]Amit: Is there a risk with caching AI outputs, since they can be non-deterministic?

[21:15]Dr. Maya Choudhury: That’s a great point. If your prompt is very dynamic, caching can be tricky. But for static or semi-static prompts—like onboarding flows or policy explanations—it works well. You just need to be careful about cache invalidation when your underlying data changes.

[22:00]Amit: How about batching—sending multiple prompts at once? Does that help?

[22:20]Dr. Maya Choudhury: Definitely. Batching can dramatically improve throughput and reduce per-call latency, especially when your provider supports it. Instead of sending 10 separate requests, send one batch and process them together. It reduces overhead and can be more cost-effective.

[23:00]Amit: Are there downsides to batching?

[23:15]Dr. Maya Choudhury: There are trade-offs. If one request in the batch fails, you may need to retry the whole batch, which can create its own issues. Also, batching increases complexity in error handling and ordering.

[24:00]Amit: Let’s touch on the trade-off between accuracy and performance. How do you balance making a prompt as accurate as possible without slowing everything down?

[24:20]Dr. Maya Choudhury: It’s a balancing act. More context and elaborate instructions can boost accuracy, but at the cost of speed and sometimes cost. You need to measure both outcomes and decide what matters more for your use case. Sometimes, slimming down a prompt slightly reduces accuracy, but the speed gain is worth it.

[25:30]Amit: This ties into our next mini case study. Can you share an example where chaining prompts led to unexpected costs or slowdowns?

[25:50]Dr. Maya Choudhury: Absolutely. We worked with a customer-facing support tool that used prompt chaining—meaning the output of one prompt fed into the next. It worked well in testing, but once in production, the latency stacked up fast. Users were waiting five or six seconds per query, and their costs tripled compared to initial estimates.

[26:30]Amit: What was the fix?

[26:40]Dr. Maya Choudhury: First, we profiled every step to see where time was being spent. Then, the team merged some of the chained prompts into a single, more carefully constructed prompt. That cut both latency and cost by more than half, and users were much happier.

[27:20]Amit: So, sometimes less is more—even with prompt logic.

[27:30]Dr. Maya Choudhury: Exactly. Chaining is powerful, but it’s easy to go overboard. Always ask if you can combine steps or cache intermediate outputs.

[27:30]Amit: Alright, so picking up from where we left off, we were just starting to get into the meat of prompt performance bottlenecks. I think this is where things really get interesting—when theory meets reality. Would you say that profiling prompts is more about speed, or about quality of the outputs, or is it always a combination of both?

[27:43]Dr. Maya Choudhury: Great question. It’s almost always a combination. People often fixate on latency or cost, but in practice, the quality—or, let’s say, the reliability—of the output is just as important. For example, you might have a really fast prompt that gives you inconsistent results, which is a nightmare for downstream automation.

[27:58]Amit: Yeah, that makes sense. Actually, can we dig into a real-world scenario? Maybe walk us through an anonymized case where a team ran into these issues?

[28:16]Dr. Maya Choudhury: Definitely. So, there was a fintech team using a large language model to summarize customer service chats for internal reporting. They started with a very generic prompt—basically, 'Summarize this conversation.' At first, it worked okay, but as volume ramped up, they noticed huge swings in both processing time and summary quality.

[28:29]Amit: So what did they do? How did they even start to profile what was going wrong?

[28:43]Dr. Maya Choudhury: Step one was actually just logging everything. They started measuring not just the time per prompt, but also scoring output quality using a rubric—was the summary accurate, did it miss key details, was it readable, that sort of thing. It quickly became apparent that the bottleneck was in ambiguity: the prompt didn’t constrain the model enough, so outputs were all over the place.

[28:59]Amit: So, basically, too little guidance made things slower and less reliable?

[29:09]Dr. Maya Choudhury: Exactly, and it also increased token usage, so it was more expensive. They iterated by adding more context and clear instructions. Instead of just 'Summarize,' it became, 'Summarize this conversation in three sentences, focusing on action items and customer sentiment.' That change alone cut costs and improved speed and consistency.

[29:28]Amit: That's a great example. It sounds like the process is: log, measure, and then tighten up the prompt based on what you see.

[29:39]Dr. Maya Choudhury: That’s the core of it. But another layer is how you handle edge cases. For instance, what happens if the chat is mostly emojis, or if there’s sensitive information? Those are the sorts of things you only catch with good profiling.

[29:50]Amit: Let’s talk about profiling tools. Are there go-to approaches you like, or is it more about internal dashboards and custom scripts?

[30:04]Dr. Maya Choudhury: Both, honestly. There are some great open-source tools that help with prompt evaluation—things like LLM Eval, Promptfoo, and custom logging middleware. But in production, teams almost always need to build their own dashboards to track specific metrics—like latency, cost, and output quality—over time.

[30:18]Amit: I love that. Maybe let’s get practical. What are three metrics every team should track when they’re using AI prompts in production?

[30:31]Dr. Maya Choudhury: Sure. Number one: latency—how long the model takes to respond. Number two: token usage, both input and output. And number three: output quality, usually scored with a rubric or semi-automated evaluation. If you’re not tracking those, you’re flying blind.

[30:45]Amit: Alright, you mentioned cost earlier. Sometimes teams just want to optimize for the cheapest possible run. How risky is that in practice?

[31:00]Dr. Maya Choudhury: It’s tempting, but it can backfire. For instance, one e-commerce team I worked with tried to save money by truncating all user messages to 150 tokens before feeding them to the model. It cut costs, but sometimes, the most critical information was at the end of the message, so their automated responses started missing the point. They ended up with more customer complaints and manual escalations.

[31:20]Amit: That’s a classic trade-off. You save a little now, but pay more in the long run with support headaches.

[31:27]Dr. Maya Choudhury: Exactly. Sometimes, spending a bit more per call gives you better automation and fewer downstream problems.

[31:36]Amit: Let’s shift gears for a second. What about prompt chaining or multi-step prompts? Do you see performance issues cropping up there?

[31:50]Dr. Maya Choudhury: Absolutely. Prompt chains can be powerful, but they introduce new latency and complexity. Each step adds its own failure points. For example, I saw a content moderation workflow with three chained prompts: extract the text, check for policy violations, then generate a user-facing message. If the extraction step failed, everything downstream was garbage.

[32:06]Amit: So, do you recommend always keeping things single-step if possible?

[32:15]Dr. Maya Choudhury: Not always. Sometimes a chain is necessary for modularity or explainability. But you should profile each link in the chain and have safeguards—like fallback prompts or manual review triggers—so one failure doesn’t cascade.

[32:28]Amit: That’s really practical. Maybe this is a good time for a quick rapid-fire round. I’ll throw out a scenario or a decision point, and you give me your gut reaction. Ready?

[32:33]Dr. Maya Choudhury: Let’s do it!

[32:36]Amit: First one: More detailed prompts or shorter, open-ended ones?

[32:39]Dr. Maya Choudhury: More detailed—usually safer and more reliable.

[32:42]Amit: Hard-coded examples in the prompt, or dynamically generated examples?

[32:46]Dr. Maya Choudhury: Dynamically generated, if you can keep them relevant and accurate.

[32:49]Amit: Longer context windows or chunking the input?

[32:54]Dr. Maya Choudhury: Chunking, unless you really need full context. Otherwise, you’ll pay more for diminishing returns.

[32:57]Amit: Best fallback: re-prompt, or escalate to a human?

[33:01]Dr. Maya Choudhury: Escalate to a human for anything high-stakes. Re-prompt for low-impact stuff.

[33:05]Amit: Prompt engineering: art or science?

[33:08]Dr. Maya Choudhury: Both! But trending more toward science as we get better metrics.

[33:11]Amit: Okay, last one: automated evaluation or human-in-the-loop?

[33:15]Dr. Maya Choudhury: Start with humans, automate where you can over time.

[33:21]Amit: Love it. Thanks for playing along. Now, circling back—a lot of teams struggle with reproducibility. Why does running the same prompt sometimes give different results, and how can teams manage that?

[33:36]Dr. Maya Choudhury: Great point. The root issue is that most large language models have a randomness factor—what’s called temperature. If you want exact reproducibility, you need to set temperature to zero, but then you might lose creativity or flexibility. In practice, you have to balance reproducibility and diversity, and always log your parameters alongside your prompts.

[33:50]Amit: So, logging isn’t just about the prompt text, but the config settings too?

[33:57]Dr. Maya Choudhury: Exactly. Log the prompt, the model version, temperature, max tokens—everything. That’s the only way to debug when you get unexpected outputs.

[34:06]Amit: Let’s do another mini-case study. Can you share a time when prompt changes actually made things worse, and how the team caught it?

[34:23]Dr. Maya Choudhury: Sure. There was a marketing analytics team that wanted more playful copy from their AI. They tweaked the prompt to encourage creativity, but didn’t realize their tone guidelines weren’t built in. Suddenly, the AI started producing brand-damaging jokes. They only caught it because they were running regular spot checks on outputs. The lesson: every prompt tweak should go through both automated and human review before rollout.

[34:41]Amit: That’s a nightmare. It shows how even small prompt edits can ripple out if you’re not careful.

[34:46]Dr. Maya Choudhury: Totally. And it’s why version control for prompts is becoming a best practice, especially as teams iterate quickly.

[34:52]Amit: What about hallucinations? That’s the bugbear for a lot of teams. How do you profile and minimize those?

[35:05]Dr. Maya Choudhury: It’s tough. Hallucinations often slip past basic metrics, so you need targeted evaluation. One trick is to inject known facts or 'canaries' into your test data, and see if the model changes them. Also, be explicit in your prompt—tell the model not to make up information, and to say 'I don’t know' if unsure.

[35:18]Amit: Have you seen teams successfully reduce hallucinations in production?

[35:27]Dr. Maya Choudhury: Yes, but it takes work. One enterprise support team added a post-processing step, using a rule-based filter to check outputs against a knowledge base. Anything suspicious was flagged for human review. Their hallucination rate dropped by over half.

[35:41]Amit: That’s really clever—so, not just relying on the AI’s own output, but validating it externally.

[35:45]Dr. Maya Choudhury: Exactly. Defense in depth.

[35:50]Amit: Switching focus, what about prompt performance at scale? Are there unique challenges when you go from a few thousand calls to millions?

[36:03]Dr. Maya Choudhury: Definitely. At scale, you start to see tail latency issues—those rare cases where a single prompt takes 10 times longer than average. These can mess up SLAs or batch jobs. Profiling at scale means tracking not just the average, but the slowest 1% or even 0.1% of calls.

[36:16]Amit: How do you address those slow outliers?

[36:24]Dr. Maya Choudhury: Often, you need to set hard timeouts, and either retry or skip the slowest prompts. Another approach is bucketing—grouping similar prompts together and tuning them separately. That way, you can optimize for the heavy hitters.

[36:34]Amit: Do you see a lot of batching or async processing in modern production systems?

[36:43]Dr. Maya Choudhury: Absolutely. For large-scale jobs, async is the norm. You can queue up prompts, parallelize processing, and handle retries without blocking user flows. But this adds new complexity—especially around tracking which outputs map to which inputs.

[36:54]Amit: Let’s talk about practical optimizations. If a team is seeing slow responses, what are the first three things you’d check?

[37:06]Dr. Maya Choudhury: First, check input length—overly long prompts slow everything down. Second, see if the model is overloaded—sometimes switching to a less busy endpoint helps. Third, look for unnecessary steps in prompt chains. Simplifying the workflow can make a huge difference.

[37:19]Amit: What about prompt caching? Is that a real thing, or does it only help in rare cases?

[37:29]Dr. Maya Choudhury: It can help more than people think, especially for static prompts or repeated queries. If you’re generating the same report summary or FAQ answer over and over, caching the output saves both time and cost.

[37:41]Amit: Let’s zoom out for a moment. If you had to give one piece of advice to teams just starting with prompt performance profiling, what would it be?

[37:51]Dr. Maya Choudhury: Start with manual review and basic logging, before you jump into fancy tools. Understand your baseline, then iterate. You don’t need to automate everything on day one.

[38:00]Amit: That’s reassuring. Sometimes people get overwhelmed by all the options.

[38:04]Dr. Maya Choudhury: Exactly. The basics still matter—measure, test, review, repeat.

[38:10]Amit: We’ve talked mostly about bottlenecks and fixes. But what about long-term maintenance? How do teams avoid prompt rot, where things slowly degrade over time?

[38:24]Dr. Maya Choudhury: Prompt rot is real. Over time, business needs change, models get updated, and edge cases stack up. The best teams set up regular reviews—monthly or quarterly—to audit prompts and outputs. They also use A/B testing to compare old and new prompts, so changes are data-driven.

[38:37]Amit: Do you recommend automated alerting if performance drops, or is that still mostly manual?

[38:45]Dr. Maya Choudhury: A bit of both. Set thresholds for key metrics—like quality scores or error rates—and trigger alerts if you go out of bounds. But someone still needs to investigate and make the call.

[38:54]Amit: Let’s touch on documentation. How important is it to document prompts and changes over time?

[39:03]Dr. Maya Choudhury: It’s critical, especially as teams grow. You want to know why a prompt was changed, who changed it, and what impact it had. Good documentation makes onboarding easier and helps when things break unexpectedly.

[39:13]Amit: What’s an example of poor documentation causing real pain?

[39:22]Dr. Maya Choudhury: I’ve seen teams scramble when a key engineer leaves, and no one knows why the prompt says, 'Respond in pirate slang.' Suddenly, the AI is talking like Jack Sparrow—and it’s a week before anyone figures out how to fix it.

[39:36]Amit: That’s both hilarious and terrifying. Okay, so stepping back—can you walk us through a quick implementation checklist for teams who want to get serious about prompt performance?

[39:51]Dr. Maya Choudhury: Absolutely. Here’s a simple checklist: One—define your success criteria. Two—set up logging for prompts, parameters, and outputs. Three—introduce basic output evaluation, human or automated. Four—iterate on prompts based on data, not gut feeling. Five—document every change. Six—set up regular reviews and A/B tests. Seven—monitor for drift and set alerts for key metrics.

[40:10]Amit: That’s gold. Can we break those down a bit? For example, what’s a good way to define success criteria?

[40:20]Dr. Maya Choudhury: Tie it to business outcomes. For a support bot, maybe it’s a reduction in manual escalations. For content generation, maybe it’s brand consistency and positive feedback. Make it measurable, so you know if you’re actually improving.

[40:30]Amit: On logging, any specific tips beyond just dumping things into a database?

[40:38]Dr. Maya Choudhury: Structure it so you can filter by prompt version, user, and time period. That way, if something goes wrong, you can pinpoint when and why.

[40:47]Amit: Is there ever such a thing as too much logging?

[40:53]Dr. Maya Choudhury: Only if you’re logging sensitive data or slowing down the system. Otherwise, more is usually better—especially early on.

[41:00]Amit: On evaluation, do you prefer manual scoring or some sort of automated metric?

[41:07]Dr. Maya Choudhury: Start with manual, move to hybrid. For scale, you’ll need automation, but human review catches nuance.

[41:13]Amit: Iteration—how do you avoid endless tweaking?

[41:19]Dr. Maya Choudhury: Set clear goals and time boxes. Otherwise, you’ll be chasing perfection forever. And always check if tweaks actually help, not just change things.

[41:25]Amit: What’s your favorite way to document prompt changes?

[41:31]Dr. Maya Choudhury: A living changelog, ideally in the repo right next to your prompts. Brief notes—what changed, why, and who approved it.

[41:38]Amit: Regular reviews—how frequent is enough?

[41:43]Dr. Maya Choudhury: Monthly for most teams, more often if you’re iterating quickly or handling sensitive content.

[41:49]Amit: Final checklist item—monitoring for drift. Can you give a concrete example?

[41:58]Dr. Maya Choudhury: Sure. Let’s say your support bot starts suggesting refunds too often. That’s drift. You’d want an alert if refund recommendations spike unexpectedly, so you can intervene before it becomes a big cost problem.

[42:09]Amit: Bringing it back to bottlenecks—are there any new patterns or anti-patterns you’re seeing emerge as the field matures?

[42:20]Dr. Maya Choudhury: Definitely. One new pattern is overengineering—teams layering on too many post-processing steps until performance tanks. On the flip side, an anti-pattern is treating prompts as black boxes and never revisiting them. Both extremes lead to issues.

[42:31]Amit: So, balance is key—don’t overcomplicate, but don’t neglect prompt hygiene, either.

[42:37]Dr. Maya Choudhury: Exactly. Healthy prompts are living, evolving assets—not fire-and-forget scripts.

[42:43]Amit: Let’s do one last mini case study before we wrap. Maybe something from a domain like healthcare or education?

[42:54]Dr. Maya Choudhury: Sure. In education, there was a platform using AI to grade open-ended student answers. Their initial prompt just asked for a grade. But they found huge inconsistencies—some students got wildly different scores for similar answers. By profiling the outputs, they realized the model was sensitive to spelling and grammar, not just content. They updated the prompt to explicitly focus on subject understanding, not language mechanics. Consistency improved by a huge margin.

[43:15]Amit: That’s a fantastic example of how prompt tuning aligns output with what actually matters. It’s not just about making it faster—it’s about making it fairer.

[43:22]Dr. Maya Choudhury: Exactly. And it shows how practical profiling leads to real impact—not just technical gains.

[43:28]Amit: Alright, as we head into the last stretch, what’s one myth about AI prompt optimization you wish more people understood?

[43:35]Dr. Maya Choudhury: That it’s not a one-time job. Prompts need ongoing attention—just like any other piece of critical infrastructure.

[43:41]Amit: If you could wave a magic wand and give every team starting out one capability, what would it be?

[43:48]Dr. Maya Choudhury: Automated, reliable output evaluation. It’s the bottleneck for scale and quality in most deployments.

[43:54]Amit: Love that. Before we close, any final thoughts or advice for teams looking to level up their prompt performance?

[44:03]Dr. Maya Choudhury: Don’t be afraid to experiment and learn from failures. But always tie your work back to user and business outcomes. That’s where the real value is.

[44:12]Amit: Alright, let’s recap our implementation checklist for listeners. I’ll read these out, tell me if I miss anything:

[44:24]Amit: One—define success metrics. Two—set up structured logging. Three—introduce output evaluation. Four—iterate and test. Five—document changes. Six—review and test regularly. Seven—monitor for drift and set up alerts. Anything else?

[44:40]Dr. Maya Choudhury: That’s spot on. Maybe just add: involve stakeholders from the start, especially end users and QA folks.

[44:50]Amit: Perfect. We’ve covered a ton today—from profiling and bottlenecks to real-world optimizations and those implementation steps. Thanks so much for joining and sharing your expertise.

[44:58]Dr. Maya Choudhury: Thanks for having me. This was a blast.

[45:07]Amit: For everyone listening, we’ll put a summary of today’s checklist and resources in the show notes. If you got value from this episode, please share it with your team and leave us a review.

[45:17]Dr. Maya Choudhury: And if you have your own prompt performance war stories or questions, send them in—we’d love to feature them in a future episode.

[45:25]Amit: Absolutely. Alright, let’s do a quick sign-off. Any last words?

[45:30]Dr. Maya Choudhury: Just remember: great prompts are built, not born. Keep iterating!

[45:36]Amit: Love it. Thanks again for joining us. Until next time, this has been the Softaims podcast. Take care!

[45:40]Dr. Maya Choudhury: Take care, everyone!

[45:45]Amit: And that’s a wrap. We’ll see you on the next episode.

[55:00]Amit: Thanks for listening!