You know the scene: you crank textures to Ultra because the dropdown implies you’re buying “more game,” then the frame time graph turns into modern art. The GPU isn’t pegged, the CPU isn’t pegged, and yet your camera pan feels like dragging a couch across carpet.
This is usually not “bad optimization” in the abstract. It’s a very specific kind of bad day: VRAM pressure, texture residency, and the ugly interaction between what the engine wants, what the driver reports, and what your card can actually keep resident without paging.
Ultra is a policy, not a promise
“Ultra” isn’t a universal unit. It’s not “best.” It’s not “correct.” It’s a bundle of choices made by a studio under time pressure, with incomplete knowledge of your machine, your background apps, your driver version, and your tolerance for stutter.
Texture quality is the easiest place for “Ultra” to become silly, because it’s the setting that can quietly demand the most VRAM while giving the least visible improvement. Many engines will happily allocate themselves into a corner, then spend your frame time budget doing memory triage.
Here’s the mental model I use in production systems and in games: when you’re near a capacity limit, everything becomes a scheduling problem. It’s not just “am I out of VRAM?” It’s “how often do I force evictions, uploads, and decompression at the worst possible times?”
What you should do, by default
- Start with High textures, not Ultra, even on a big GPU. Then measure. If you can’t tell the difference while moving, don’t pay for it with stutter.
- Keep a VRAM safety margin. If your overlay says you’re at 95–100% VRAM in a busy scene, you’re not “using all of it efficiently.” You’re flirting with paging.
- Prioritize stable frame times over peak FPS. Spikes are what your hands feel.
One quote that belongs on a sticky note near every “Ultra” toggle: “Hope is not a strategy.”
— Gene Kranz
Textures, VRAM, and why it gets weird
Textures are big, numerous, and not all equal. A “texture quality” slider usually changes some mix of:
- Maximum texture resolution (e.g., 2K → 4K)
- Mip bias and residency rules (how aggressively lower mips are used/kept)
- Anisotropic filtering defaults (sometimes separate, sometimes bundled)
- Streaming pool size (how much memory the engine reserves for streaming)
- Compression format choices for certain asset classes (varies widely)
VRAM is not a single “bucket.” It’s a hierarchy: local video memory, plus shared/system memory, plus whatever the OS/driver can page in/out. Modern APIs (DX12/Vulkan) expose memory budgeting and residency more explicitly, but the experience still depends on the driver and engine behaving like adults.
Texture math that makes “Ultra” look expensive
A common surprise: a single 4K texture isn’t “a few megabytes.” It depends on format and mipmaps. Roughly:
- Uncompressed RGBA8 4K: 4096×4096×4 bytes ≈ 64 MiB for the top mip, plus ~33% for mip chain → ~85 MiB.
- BC7-compressed 4K: ~16 MiB top mip, plus mip chain → ~21 MiB.
Now multiply by: albedo + normal + roughness/metalness/AO + emissive + masks. Then multiply by number of unique materials in view, plus the “just in case” assets the engine keeps around because it has to predict where you’ll turn next. The bill arrives fast.
Short joke #1: Ultra textures are like carrying a full-sized refrigerator to a picnic. Technically impressive; socially questionable.
Resolution isn’t the same knob
Screen resolution mostly affects render targets (color, depth, post-processing buffers) and shading cost. Texture quality mostly affects asset residency. You can play at 4K with High textures and have a fine time, and you can play at 1080p with Ultra textures and have a stuttery disaster. These are different pressure points.
Facts and context you can use at a party (or a postmortem)
- Mipmapping is older than most GPUs you’ve owned. It was described in the early 1980s to reduce aliasing and improve cache behavior, and it’s still a core tool for stability.
- Consoles normalized fixed memory budgets. The “8 GB unified memory” era forced studios to become disciplined about residency and streaming, even if PC ports sometimes forget that lesson.
- DX11 hid a lot of residency pain. Driver-managed memory made life simpler, until it didn’t; DX12/Vulkan made it explicit, which is great for performance and terrible for sloppy budgets.
- Texture compression is a bandwidth strategy, not just a storage trick. Block compression formats (BCn/ASTC) reduce VRAM footprint and memory traffic; they’re a performance feature.
- Normal maps often dominate more than albedo maps. People think “color textures,” but high-frequency normals are everywhere, and they’re rarely cheap.
- Virtual texturing (“mega textures”) isn’t new. Variants existed for years, but modern SSDs and better GPU page tables made it practical at scale.
- VRAM reporting is not standardized across tools. “Allocated,” “committed,” “resident,” and “in use” are different states; overlays often mix them.
- Resizable BAR can change the feel of oversubscription. It doesn’t increase VRAM, but it can influence transfer behavior and reduce some worst-case stalls.
- PCIe bandwidth is not VRAM bandwidth. When you page textures from system memory, you’re leaving a multi-hundred-GB/s highway for a much smaller road with traffic lights.
What actually happens when you “run out of VRAM”
Most of the time, nothing dramatic happens. No crash. No error. Just inconsistent frame times.
Under VRAM pressure, the system juggles:
- Evictions: pushing resources out of local VRAM to make room.
- Uploads: pulling textures back in when needed.
- State churn: changing which mips are resident, sometimes multiple times per second.
- Synchronization: waiting for transfers, fences, or copy queues to complete.
The failure mode isn’t “low average FPS.” It’s stutter while rotating the camera, hitching when entering a new area, or periodic spikes every few seconds. These correlate with streaming events, shader compilation, or garbage collection too—but VRAM pressure amplifies all of them because everything is fighting for the same limited residency pool.
VRAM oversubscription: the hidden tax
When an engine’s “budget” exceeds local VRAM, it can still run by leaning on system memory (or worse, page file). That’s oversubscription. Think of it like running a database with a buffer cache larger than RAM: it technically starts, and then it spends its life thrashing.
If you only take one actionable point from this article: keep your working set comfortably within VRAM. “Comfortably” means leaving room for spikes, driver overhead, and whatever the engine didn’t tell you it’s doing.
Short joke #2: Turning textures to Ultra on a tight VRAM card is a great way to experience “immersive loading screens” in real time.
Fast diagnosis playbook
This is the order that finds the bottleneck quickly without turning your evening into an interpretive dance of toggles.
First: prove whether it’s VRAM pressure
- Enable a VRAM overlay (driver overlay or in-game if trustworthy) and reproduce the stutter in the exact scene that feels bad.
- Watch for VRAM pegging (95–100%) and frame time spikes coinciding with camera movement or asset-heavy transitions.
- Drop texture quality one notch (Ultra → High). Do not change anything else yet. If the spikes shrink materially, you found your lever.
Second: separate VRAM from “everything else” stutter
- Check CPU saturation per core. A single core pegged can cause streaming and draw-call stalls that look like VRAM issues.
- Check shader compilation symptoms: spikes that happen the first time you see an effect, then disappear.
- Check storage I/O: if your disk is at 100% active time when streaming, your textures are arriving late regardless of VRAM.
Third: optimize for consistency
- Set textures to the highest level that stays within budget in worst-case scenes.
- Cap FPS to reduce transient load spikes and stabilize pacing.
- Dial in streaming settings if exposed (pool size, prefetch distance). Bigger isn’t always better; bigger can mean “thrash slower but longer.”
Practical tasks with commands (what it means, what you decide)
These are intentionally boring. Boring is good; boring is repeatable. The commands assume Linux with common tooling because that’s where SRE habits are easiest to demonstrate, but the logic applies everywhere.
1) Identify your GPU and driver
cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2782] (rev a1)
What the output means: Confirms which GPU is present and which PCI device we’re talking about. Useful when you have hybrid graphics or remote sessions.
Decision: If the GPU isn’t the one you think you’re using, stop and fix that before tuning anything.
2) Check NVIDIA VRAM use and per-process consumers (if applicable)
cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,memory.total,memory.used,memory.free --format=csv
name, driver_version, memory.total [MiB], memory.used [MiB], memory.free [MiB]
NVIDIA GeForce RTX 4070, 550.54.14, 12282 MiB, 10321 MiB, 1961 MiB
What the output means: Total vs used vs free VRAM. If used is high while stuttering, you’re likely near a residency edge.
Decision: If “free” is consistently under ~10–15% in the problematic scene, treat Ultra textures as guilty until proven innocent.
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec fb command
0 28144 G 62 48 0 0 9920 game.bin
0 2331 G 2 1 0 0 180 Xorg
What the output means: Quick view of which processes are consuming framebuffer memory (fb). “mem” here is utilization %, not MiB.
Decision: If background processes are holding hundreds of MiB (recorders, browsers with GPU acceleration), kill or isolate them before blaming the game.
3) Check AMD GPU memory info (if applicable)
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_total
17179869184
cr0x@server:~$ cat /sys/class/drm/card0/device/mem_info_vram_used
12884901888
What the output means: Raw bytes of total and used VRAM as reported by the kernel driver.
Decision: Convert to GiB mentally (divide by 1024^3). If used is close to total during stutter, lower textures or reduce other VRAM-heavy features (RT, high-res shadows, large caches).
4) Verify your PCIe link isn’t downgraded
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
What the output means: Link capability vs actual negotiated link. If you’re at x4 or a lower speed, paging costs hurt more.
Decision: If the link is unexpectedly downgraded, reseat the card, check BIOS settings, and don’t chase texture settings yet.
5) Check CPU per-core saturation during stutter reproduction
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 01/21/2026 _x86_64_ (16 CPU)
12:04:10 PM CPU %usr %sys %iowait %idle
12:04:11 PM all 22.11 6.18 1.02 70.69
12:04:11 PM 7 92.00 5.00 0.00 3.00
What the output means: One core (CPU 7) is pegged. That can be render thread, streaming thread, or driver work.
Decision: If a single core is pinned when stutter happens, lowering textures may help indirectly (less streaming work), but you should also try reducing draw-call heavy settings (view distance, crowd density) and check for background CPU hogs.
6) Check storage latency and saturation while streaming
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
21.2 0.0 6.1 1.0 0.0 71.7
Device r/s rkB/s await %util
nvme0n1 210.0 82000.0 3.20 62.0
What the output means: “await” is average time per I/O. %util shows device saturation. If await spikes high during hitches, storage is in the loop.
Decision: If %util is near 100% and await is high when you hitch, moving the game to a faster SSD or reducing streaming demand (textures, view distance) will help.
7) Verify the game isn’t paging heavily at the OS level
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 0 8123456 221000 9021000 0 0 120 340 900 2100 22 6 71 1
What the output means: “si/so” are swap-in/out. If these are non-zero during stutters, you’re not just out of VRAM; you’re out of system memory headroom too.
Decision: If swapping occurs: close background apps, add RAM, reduce texture quality, and ensure the page file/swap is on SSD (and sized sanely).
8) Observe GPU engine utilization (sanity check)
cr0x@server:~$ sudo intel_gpu_top -s 200 -o -
requesting drm device 0, main kdev 0, minor 0
Render/3D 12.32% Blitter 0.00% Video 0.00%
What the output means: On Intel iGPU systems, shows whether the GPU is actually busy. Low utilization with bad frame times often points to CPU stalls or memory stalls.
Decision: If utilization is low during stutter, don’t chase “more GPU.” Chase the stall source (VRAM paging, CPU thread, I/O, shader compilation).
9) Check compositor / display mode (VRR and fullscreen behavior)
cr0x@server:~$ xrandr --verbose | grep -E 'connected|vrr_capable|vrr_enabled'
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis)
vrr_capable: 1
vrr_enabled: 1
What the output means: Variable refresh support is enabled. VRR can mask small frame time variance but will not save you from 200 ms hitches.
Decision: If VRR is off, turn it on for comfort. If VRR is on and you still hitch, you’re dealing with big spikes (streaming/paging).
10) Confirm which filesystem and free space you have (streaming hates full disks)
cr0x@server:~$ df -hT /mnt/games
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p2 ext4 930G 870G 13G 99% /mnt/games
What the output means: 99% full is a performance smell. Fragmentation and garbage collection behavior can increase latency.
Decision: Free space. Aim for at least 10–15% headroom. Then retest stutter before touching more settings.
11) Watch real-time I/O latency spikes with iotop
cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 75.21 M/s | Total DISK WRITE: 2.11 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
28144 be/4 cr0x 62.10 M/s 0.00 B/s 0.00 % 9.21% game.bin
What the output means: The game is pulling a lot of data. That’s normal during streaming, but if it coincides with hitches and your drive is slow/saturated, you found a contributor.
Decision: If read rates are high and your drive is maxed, reduce streaming demand (textures/view distance) or move the install to faster storage.
12) Validate system memory headroom
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 26Gi 1.2Gi 1.1Gi 4.8Gi 3.9Gi
Swap: 8Gi 0.0Gi 8Gi
What the output means: “available” is what matters. If it’s low, the OS will fight you.
Decision: If available memory is under ~3–4 GiB while gaming, expect more paging and worse stutter when VRAM is tight. Close things, or add RAM.
13) Check shader cache size and location (practical sanity)
cr0x@server:~$ du -sh ~/.cache/* 2>/dev/null | sort -h | tail -n 5
1.2G /home/cr0x/.cache/mesa_shader_cache
2.8G /home/cr0x/.cache/game-shader-cache
What the output means: Large shader caches are normal. If your home directory is on a slow disk or near-full, shader compilation and cache writes can stutter.
Decision: Ensure caches live on SSD and there’s headroom. Don’t “optimize” by deleting caches routinely unless troubleshooting corruption.
14) Measure frame pacing via present statistics (basic approach)
cr0x@server:~$ mangohud --dlsym ./game.bin
MangoHud: HUD initialized
What the output means: You’re running with a frame-time overlay. You care more about the frame-time graph than the FPS number.
Decision: If the graph shows periodic spikes that vanish after lowering texture quality, you’re looking at streaming/VRAM residency stress, not raw GPU throughput.
Three corporate mini-stories from the trenches
1) Incident caused by a wrong assumption: “VRAM is like RAM, it’ll just cache better”
A studio I worked with (call them Company A) shipped a PC patch that “improved visuals” by raising default texture quality on higher-end GPUs. The change was justified with a familiar line: most cards had enough VRAM now, and unused VRAM is wasted.
They tested on a handful of machines in the lab. Frame rates looked fine. No crashes. The patch went out on a Tuesday, because of course it did.
Within hours, support channels filled with reports: “microstutters after 20 minutes,” “hitching when turning,” “fine at first, then terrible.” The kicker: many reports were from 8–10 GB cards that should have been “safe.” The assumption failed because VRAM isn’t a passive cache. It’s a residency constraint, and engines can make bad bets about future camera movement. A player with a wide FOV, fast turning, and a high-speed mount was effectively a worst-case streaming benchmark.
The postmortem showed the default texture change pushed typical VRAM use from “comfortable” to “knife-edge,” and the engine’s eviction policy started oscillating. Oscillation is the enemy in every system: once you’re thrashing, the work you do creates more work. Classic positive feedback loop.
The fix was not heroic. They reverted the default, added a warning label that mapped texture presets to VRAM headroom, and adjusted the streaming pool to behave more conservatively under pressure. The biggest lesson wasn’t about textures; it was about assuming capacity behaves linearly. It doesn’t.
2) Optimization that backfired: “Let’s shrink texture memory with aggressive mip drops”
Company B had a legitimate problem: on midrange GPUs, VRAM usage was too high in dense cities. Somebody proposed a clever idea: dynamically drop mips more aggressively whenever VRAM approached the budget. In theory, this would keep the game inside its lane and avoid hitches.
The first internal test looked promising. VRAM use flattened. Fewer hard stalls. Everyone nodded. Then QA started doing what QA does: standing still and slowly rotating the camera, repeatedly, in the same spot.
The city became a shimmering mess. Textures popped constantly. Worse, the engine started “yo-yoing” mips: drop mips to reduce VRAM, free space appears, engine upgrades mips again, VRAM rises, drop again. The result was stable VRAM but unstable visuals and continuous background work. They traded one form of stutter for another: instead of rare big hitches, they got constant low-grade jank.
In systems terms, they implemented a controller with no damping and too aggressive thresholds. It was a thermostat that turns the heater on full blast at 19.9°C and off at 20.0°C. Congratulations, you invented oscillation.
The eventual fix was to add hysteresis (don’t immediately upgrade mips after a drop), cap how fast mips can change per second, and prefer reducing future streaming requests over evicting currently visible assets. The “optimization” wasn’t wrong; it was incomplete. In performance work, incomplete is how you ship new problems on time.
3) Boring but correct practice that saved the day: “Budgets, instrumentation, and a hard ‘no’ to silent defaults”
Company C didn’t have the most glamorous engine, but they had a discipline that felt almost old-fashioned: a VRAM budget table per platform and per quality level, reviewed like an SLO. Not “roughly.” A real table.
Every build collected telemetry from internal playtests: peak resident textures, average streaming queue depth, number of evictions per minute, worst frame time percentile. If you changed texture presets, you had to show the metrics. If you added a new material library, you had to show the budget impact. If you didn’t, your change didn’t land.
When late-stage content pushed the city map close to the budget, they didn’t scramble. They already knew which asset groups were the top offenders. They lowered some normal map resolutions, adjusted a few material instances, and replaced a handful of “hero” props that didn’t deserve hero textures.
The release still had bugs, because software always does. But they didn’t have the signature “Ultra makes the game stutter on perfectly normal hardware” fiasco. The boring practice—budgets, instrumentation, and refusing silent changes—did what boring practices do: prevented exciting outages.
Common mistakes: symptom → root cause → fix
1) “FPS is high, but it feels terrible when I turn”
Root cause: Texture streaming stalls or VRAM oversubscription causing evictions/uploads during camera movement.
Fix: Drop texture quality one notch; reduce view distance; ensure game is on SSD; keep VRAM usage under ~85–90% in worst scenes.
2) “Lowering resolution didn’t fix stutter”
Root cause: You reduced render-target load, but your bottleneck is asset residency and streaming, not pixel shading.
Fix: Lower textures and/or streaming settings; reduce high-res shadows; disable high-res texture packs that exceed your VRAM.
3) “It runs fine for 10 minutes, then gets worse”
Root cause: Working set grows as you traverse; caches fill; background apps creep; VRAM becomes fragmented or budget shrinks due to other allocations.
Fix: Close GPU-heavy background apps; restart the game between long sessions as a workaround; tune textures for worst-case areas, not the tutorial zone.
4) “Ultra textures look the same as High, but performance tanks”
Root cause: You’re limited by memory footprint/bandwidth, not detail perception. Many scenes are mip-limited in motion anyway.
Fix: Keep High. Spend budget on anisotropic filtering (usually cheap) or better lighting settings that actually change the scene.
5) “Texture pop-in is awful on Medium”
Root cause: Streaming pool too small or too aggressive mip bias, causing visible mip transitions.
Fix: Increase texture quality one notch, or increase streaming pool if the engine exposes it—but only if you have VRAM headroom.
6) “VRAM overlay says I’m using 11 GB on a 12 GB card, so I’m fine”
Root cause: Being “almost full” is not fine. Spikes happen. Driver overhead happens. The engine can burst allocate during transitions.
Fix: Target a buffer. Treat 90% as “yellow,” not “green,” in the scenes where the game struggles.
7) “After enabling ray tracing, textures started stuttering”
Root cause: RT often allocates large buffers (BVHs, denoiser history, extra render targets), reducing VRAM left for textures.
Fix: If you want RT, lower textures or shadows. If you want crisp textures, lower RT. Pick one luxury at a time unless you have serious VRAM.
8) “I installed a high-res texture pack and now everything hitches”
Root cause: The pack increased working set beyond VRAM; paging over PCIe is now part of your frame loop.
Fix: Uninstall the pack, or accept lower textures elsewhere. High-res packs are not “free upgrades.” They are capacity decisions.
Checklists / step-by-step plan
Checklist A: pick the right texture level in 15 minutes
- Find a worst-case scene: dense city, lots of unique materials, fast traversal.
- Enable a frame-time overlay (not just FPS).
- Set textures to Ultra; play for 2 minutes; note VRAM peak and worst frame-time spikes.
- Set textures to High; repeat the exact path; compare spikes and VRAM peak.
- If High removes major spikes and Ultra doesn’t look meaningfully better while moving, keep High.
- If Ultra is smooth and you still have 10–20% VRAM free in the worst case, congrats: Ultra is for you.
Checklist B: stabilize a system that stutters under VRAM load
- Close GPU-heavy background apps (browsers with many tabs, recorders, overlays you don’t need).
- Ensure game is installed on SSD with >15% free space on that volume.
- Reduce textures one notch; retest.
- If still bad: reduce RT/shadow resolution; retest.
- Cap FPS slightly below your typical average (e.g., 120 → 90, 60 → 50). This reduces burstiness.
- Only then consider resolution scaling.
Checklist C: “Ultra without regret” rules
- Ultra textures are justified when you have VRAM headroom in worst-case scenes and you play slow enough to notice fine surface detail.
- Ultra textures are unjustified when they force VRAM to the limit, especially in open-world traversal games.
- If you stream content (capture/encode) while playing, assume you need more headroom than a “pure gaming” scenario.
- If the game has a “high-res texture pack,” treat it like a hardware requirement, not a cosmetic add-on.
FAQ
1) Is VRAM usage supposed to be near 100%?
No. A healthy system uses VRAM but keeps headroom. 95–100% in demanding scenes is where paging and eviction storms begin.
2) Why do textures cause stutter more than other settings?
Because textures are large and numerous, and the penalty for missing a needed texture is often a synchronous wait: evict, upload, decompress, then draw.
3) If my GPU has plenty of compute, why can’t it “muscle through”?
Compute doesn’t help if the data isn’t resident. A fast GPU waiting on a texture upload is still waiting. That’s not a strength contest; it’s a logistics failure.
4) Does lowering resolution reduce VRAM usage?
It reduces render-target memory and some caches, but it may not materially reduce texture residency. That’s why resolution drops often don’t fix texture-driven stutter.
5) Are “High” and “Ultra” textures visibly different?
Sometimes in still shots. Often not in motion, especially with TAA, depth of field, and typical camera distances. If you can’t tell during play, don’t pay the VRAM tax.
6) What’s the difference between “allocated” VRAM and “used” VRAM?
Allocated can mean reserved address space or committed resources. Used/resident means actually occupying local VRAM. Tools vary; don’t assume one overlay is authoritative.
7) Can an SSD fix VRAM problems?
An SSD helps streaming, not residency. It can reduce the severity of hitches by making data arrive faster, but it can’t replace local VRAM bandwidth and latency.
8) Should I disable texture streaming?
Only if the game supports it well and you have massive VRAM. Disabling streaming often increases upfront loads and can increase total VRAM demand. Test, don’t guess.
9) Why does ray tracing affect texture smoothness?
RT features consume VRAM for acceleration structures and history buffers. That reduces the memory budget available for texture residency and streaming pools.
10) What single setting is the best “bang for buck” if I lower textures?
Anisotropic filtering is usually cheap and improves texture clarity at angles. Keep it high while you tune texture resolution down.
Next steps you can actually do
If your current approach is “set everything to Ultra and hope,” replace it with a process:
- Pick a worst-case scene and measure VRAM and frame-time spikes.
- Lower textures one notch and rerun the same path. If spikes shrink, keep the lower setting and move on with your life.
- Protect headroom: aim for VRAM peaks that leave 10–20% free in the scenes that matter.
- Spend your budget where you feel it: stable pacing, sensible shadows, and AF beat bragging rights.
- When you change one thing, change one thing. Tuning is debugging, not a ritual.
Ultra isn’t a badge of honor. It’s a resource policy. Make it a policy you can afford.