VS Code Copilot Cloud Automations: Daily App Store Review Triage

On October 28, 2026, GitHub added Copilot cloud automations to VS Code. You write a prompt and pick a time. Then a Copilot cloud agent runs that prompt on GitHub every day, even when your laptop is off. We used this for one common mobile job. Each morning, the agent sorts new bad App Store and Google Play reviews into crash, payment and login problems.

We made 10 live calls to the EveryInfra app_store/reviews and google_play/reviews capabilities on November 11, 2026. The calls covered two public apps, Duolingo and Strava, in both stores. The API fee for a daily run over four store listings is $0.0056 a day, or $0.17 for 30 days.

Two other facts decide if the job works. One call returns at most 200 English Google Play reviews for Duolingo, and they cover only 4.25 hours. So one daily run misses most new reviews of a large app. Also, VS Code lets a cloud automation run at most once a day.

We did not create this automation in a GitHub repository. All Copilot steps in this article come from GitHub and VS Code documentation, and we label them "config example". All EveryInfra numbers come from live calls, with the Singapore time (SGT) of each call.

Key points

• Copilot cloud automations shipped on October 28, 2026, with VS Code 1.144. They work on private and internal repositories, on the Pro, Pro+, Max, Business and Enterprise plans.
• In VS Code, a cloud automation runs manually, daily or weekly. Minutes are 00, 15, 30 or 45, and times are stored in UTC. Hourly and cron schedules are for local runs only.
• One call covers very different time spans: 4.25 hours for Duolingo on Google Play (English), 123.9 days for Strava on the US App Store.
• In both stores, the newest review is 24 to 44 hours old. Google Play holds new reviews for about 24 hours before it shows them.
• If the model reads the raw MCP output, it reads about 65,062 tokens a day. A script that keeps only new 1 to 3 star reviews cuts this to about 4,999 tokens.
• A keyword rule is only a first filter. In a random sample of 40 bad reviews, the rule was right 23 times, wrong 13 times and missed 4.

The daily job is a sieve. Most reviews need no reading. A few bad reviews go into crash, payment, login and sync groups.

The job: a bad-review report every morning

A team ships one mobile app for iOS and Android. Each morning, the repository must contain a new report on the 1 to 3 star reviews since the last run. The report puts each review into one group: crashes and bugs, payment, login and account, sync and devices, ads, redesign, or other. If one group jumps, for example "the app crashes after the update" a dozen times in three days, the automation opens an issue. The issue holds the examples and the app version.

The job fits Copilot cloud automations for three reasons. It runs on a schedule and must finish before people start work. It writes into the repository, and the cloud agent already has GitHub tools for files and issues. Its data is outside the repository, so the agent needs an MCP server or a fetch script. The EveryInfra data API fills that third gap.

We picked one large app and one medium app. Duolingo (App Store ID 570060128, Android package com.duolingo) is a language app with a very large review volume. Strava (App Store ID 426826309, package com.strava) is a fitness tracker with a medium volume. We read only public reviews and signed in to no account. The main calls ran on November 11, 2026, from 00:22 to 00:42 SGT, which is about 08:30 PST on November 10.

What are VS Code Copilot cloud automations? The October 28 release, checked line by line

The GitHub changelog of October 28, 2026 announced Copilot Automations in Visual Studio Code. The entry says that you need VS Code 1.144 and the setting chat.automations.cloud.enabled. The feature is available on the Copilot Pro, Pro+, Max, Business and Enterprise plans. You find it in the Automations tab of the Agents window. The VS Code download page showed version 1.144.1 on that day.

The VS Code automations page, dated November 11, 2026, now says something slightly different. It says that automations and cloud automation management are on by default. You check chat.automations.enabled and chat.automations.cloud.enabled only if the Run in the Cloud option is not in the form. Both pages agree on the version and the plans. We quote both because a team that follows the changelog may look for a setting that is already on.

GitHub posted two related entries on the same day: cost controls for automations and shared team automations. The cost section and the limits section below use them.

One Copilot cloud automation has three parts: a prompt, a trigger and a set of tools. The prompt says what to do, what to read and what to deliver. The trigger is a schedule, a manual run, or a GitHub event such as a new issue. The tools are the GitHub tools plus MCP tools from the repository settings. Each run starts one cloud agent session on GitHub, and its log stays there. The table below lists each fact with its source.

Fact	What the source says	Source
Release date	October 28, 2026	GitHub changelog
VS Code version	1.144 or later	GitHub changelog, VS Code 1.144 release notes
Settings	chat.automations.cloud.enabled (changelog), on by default (docs page of November 11, 2026)	GitHub changelog, VS Code docs
Plans	Copilot Pro, Pro+, Max, Business, Enterprise	GitHub changelog
Repositories	Private and internal repositories only	VS Code docs
Entry point	Automations tab in the Agents window	VS Code docs
Cloud schedules	Manual, daily, weekly; minutes 00/15/30/45; stored in UTC	VS Code docs
Tools	GitHub tools, plus MCP tools from the repository MCP settings	VS Code docs, GitHub docs
Billing	One cloud agent session per run, paid in AI credits, plus Actions minutes	GitHub docs
API	REST "agent automations", public preview, version 2026-03-10	GitHub REST docs

One row is easy to miss. The VS Code page says that a cloud automation does not accept local mode, local approval settings, custom agents or local MCP configuration. So the cloud automation cannot see the EveryInfra MCP server in your own VS Code. You must add the server again in the GitHub repository settings, as the MCP section below shows.

How often can it run? Cloud schedules are daily or weekly

For a review job, the most important fact is the shortest interval. The text under the VS Code table "Set a recurring schedule" is direct. Cloud automations support Manual, Daily and Weekly triggers, and hourly and cron schedules are for local runs only. The minute must be 00, 15, 30 or 45, and cloud schedules are stored in UTC. We took a screenshot of that part of the page.

The schedule types that VS Code offers for cloud automations. The teal box marks the sentence that we quote. Screenshot taken on November 11, 2026, SGT. VS Code automations documentation, screenshot

Two sources do not say exactly the same thing here. The GitHub page on creating automations lists hourly, daily and weekly schedules, event triggers for issues and pull requests, and an API trigger. A VS Code test issue from October 11 (number 340970) also lists Hourly and Weekdays as test items. Our reading is that an automation created on the GitHub website can run every hour. An automation created in VS Code offers only daily and weekly cloud schedules.

The VS Code page is newer than the test issue, so this article follows the page. If your team needs an hourly run, create the automation on GitHub. You can also split the job into frequent fetches and one daily analysis, as we show later.

UTC storage is easy in Singapore, where 01:00 UTC is 09:00 all year. In San Francisco, 15:00 UTC is 07:00 in winter (PST) and 08:00 in summer (PDT). The VS Code page tells you to check the saved time after a daylight saving change.

The full flow: six steps per run

The figure above shows the flow that we recommend. Step 1 is the GitHub schedule, and in step 2 the agent reads the instruction files in the repository. Step 3 fetches new reviews, through MCP or a script. Step 4 removes reviews already seen, by ID, and keeps only 1 to 3 stars. Step 5 lets the model put each review into a fixed group and compare the counts with past days. Step 6 writes the report and, if necessary, opens an issue.

The split between step 3 and step 4 is the main design choice. If the agent calls the API through MCP, each full review goes into the model context, with author, avatar link and helpful count. If a script fetches, dedupes and filters first, the model reads one small file. Both ways work, and the section "Filter with a script first" measures the tokens of each.

How the Copilot cloud agent connects to MCP: the JSON in repository settings

The Copilot cloud agent reads its MCP servers from the repository settings. Open the repository Settings, then Copilot, then MCP servers, and paste a JSON block there. The GitHub page on MCP servers describes the format. The top level is mcpServers. Each server has a type (local, stdio, http or sse), a url and headers for a remote server, and a tools allowlist.

Only MCP tools work, not MCP resources or prompts. Remote servers that need OAuth are not supported yet, according to the same page. The EveryInfra remote MCP server uses an API key, not OAuth, so it fits. The block below is a config example. We did not save it in a GitHub repository.

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_EVERYINFRA_KEY"
      },
      "tools": ["everyinfra_list_capabilities", "everyinfra_call_api", "everyinfra_get_job"]
    }
  }
}

Do not put the key in this JSON. The GitHub page on secrets for the cloud agent explains the rules. Under Secrets and variables there is an Agents type. A secret whose name starts with COPILOT_MCP_ goes only to MCP servers and is not an environment variable for the agent. Other secrets become environment variables for the commands and scripts that the agent runs. Session logs mask secret values.

So the MCP path stores the key as COPILOT_MCP_EVERYINFRA_KEY. The script path stores it under a name without the prefix, for example EVERYINFRA_API_KEY. The two paths need two different secrets. If you use the wrong name, the server or the script starts without a key and the first call fails with 401.

Keep only three tools in the allowlist. At 00:22 SGT we sent one tools/list request to the EveryInfra MCP server, and it returned 12 tools. Review triage needs three of them: list capabilities, call the API and read an async job. The allowlist also has a second effect. The MCP specification gives each tool annotations, and readOnlyHint means that the tool changes nothing.

In our tools/list response, everyinfra_list_capabilities and everyinfra_get_job are read-only. everyinfra_call_api costs money, so it is not marked read-only. The GitHub MCP overview says that Copilot code review uses only tools with readOnlyHint set to true. So the same config cannot call the data API during code review. It can call it in cloud agent sessions and automations.

To test the setup, GitHub tells you to assign an issue to Copilot and open the session log. The step "Start MCP Servers" must list the server and its tools. There is also an open community report. GitHub community discussion 211107 was posted on October 27, 2026. A user says that custom MCP tools start in an automation session, but the agent cannot call them. The same setup works in a cloud session that the user starts by hand.

When we read that thread, no GitHub staff member had posted an answer. So for the first launch, trigger the automation by hand. Check that the log shows a real everyinfra_call_api call and its result, and only then turn on the schedule.

The firewall is the last difference. The GitHub firewall page says that it applies only to processes that the agent starts with its Bash tool, not to MCP servers. So the MCP path needs no change. On the script path, the request starts from Bash, and you must add api.everyinfra.com to the custom allowlist. The allowlist reference lists the default hosts, and our host is not on it.

Two capabilities: app_store/reviews and google_play/reviews

The free EveryInfra catalog (GET https://api.everyinfra.com/api/v1/social/catalog, no charge) listed 573 capabilities when we read it. Review triage uses two of them. Two more help during setup. app_store/search finds an App Store app and its numeric ID, and google_play/profile reads the store page of an Android app. You find all four on the App Store data API and Google Play data API pages.

The capability pages are App Store reviews, Google Play reviews, App Store search and Google Play app profile. Each page shows the parameters, the response fields and the price from the same catalog. The table below compares the two review capabilities field by field.

Item	app_store/reviews	google_play/reviews
App ID	app_id, numeric, for example 426826309	app_id, package name, for example com.strava
Region and language	country selects the store country	country does not change the reviews, language does
Sort	newest or most_helpful	newest or top_rated
Reviews per call	30 by default, 500 at most	40 by default, 200 at most
Pages	No paging, one call returns all	page_token, valid 24 hours, 200 reviews at most
Star field	rating (plus rating_scale)	score
Other fields	id, title, text, author, app_version, helpful_count, posted_at	id, text, author_name, thumbs_up, reply_text, reply_at, app_version, language, url, posted_at
Price	$0.001389 per call	$0.001389 per call

The price is per call, not per review. An App Store call for 500 reviews costs the same $0.001389 as a call for 30 reviews. So always set limit to the maximum. Google Play paging has a hard depth limit. At 00:23 SGT we asked for 100 Strava reviews and got a next-page token. The second page gave 100 more, and stop_reason was depth_limit, which means the 200-review limit.

So the newest 200 reviews are all that this capability returns, in one call or in two pages. Paging only adds one more charge. The practical rule is one call with limit 200 per Google Play listing and one call with limit 500 per App Store listing.

The two stores use different field names, so the script maps them first. Stars are rating in one store and score in the other, and only the App Store has a title. Both use posted_at, but the App Store value has a Pacific offset such as -07:00, and Google Play uses UTC. Convert all times to one zone before you count by day, or the boundary of "yesterday" moves by 7 or 8 hours.

One real round trip: what the agent sends and what comes back

In a Copilot cloud agent session, a call to an MCP tool is a standard MCP tools/call request. At 00:26:38 SGT we sent one in this format directly to the EveryInfra MCP server. The request asked for 20 newest Strava reviews from the US App Store. The reply was one JSON text block of 10,725 characters. It had count 20, and billing showed charged_usd 0.001389. The model in a session sees this full block, with no compression.

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"everyinfra_call_api",
  "arguments":{"platform":"app_store","action":"reviews",
   "params":{"app_id":"426826309","country":"us","sort":"newest","limit":20}}}}

One MCP round trip and one 429 response, both real. Author names are masked, and balance fields are removed. Captured on November 11, 2026, SGT. Real EveryInfra API responses, 2026-11-11, 00:22 to 00:26 SGT

The bottom half of the screenshot shows a rate-limited request. Our test key has its own limit of 10 calls per minute, and other jobs used the same key that night. At 00:22:43 SGT, the Duolingo Google Play request got a 429. The response gave the reason (this key's per-minute limit), retry_after 16 seconds and retryable true. It also said that nothing was charged.

We waited 21 seconds and sent the request again. At 00:23:04 SGT it returned 200 reviews. At 00:23:44 SGT the Strava App Store request got another 429, and the retry at 00:24:11 SGT worked. Neither 429 was charged.

For a daily automation, 429 handling is simple. Put one retry rule in the prompt: wait retry_after seconds after a 429, and try at most three times. The model can read the response, because the reason, the wait time and the charge status are all in it. The bigger risk is a changed parameter. While it waits, the model may call again with a different limit and pay twice for the same reviews. So the prompt also allows one call per app and store per run.

Test 1: how much time does one call cover?

To know if one run a day is enough, first look at the time span of one call. We took the posted_at of the newest and the oldest review in each response.

The four sets are very different. For Duolingo, 200 Google Play reviews in English cover 4.25 hours, and 500 US App Store reviews cover 37.9 hours. For Strava, 200 Google Play reviews cover 7.6 days, from November 2, 2026, to November 9, 2026. The 450 US App Store reviews cover 123.9 days. The longest span is 700 times the shortest.

Data set	Call time (SGT)	Reviews	Time covered	New reviews per day	1 to 3 stars
Duolingo · App Store US	00:22:28	500	37.9 hours	316.6	105 (21%)
Duolingo · Google Play English	00:23:04	200	4.25 hours	1,130.6	27 (13.5%)
Strava · Google Play English	00:23:21 and 00:23:31, two pages	200	7.6 days	26.3	102 (51%)
Strava · App Store US	00:24:11	450	123.9 days	3.6	236 (52.4%)

Two points need a comment. First, the 450 Strava App Store reviews cover four months, from July 7, 2026, to November 8, 2026. For an app with a low volume, one call shows a full quarter.

Second, the share of bad reviews goes the other way from the volume. Duolingo, with many reviews, has 13.5% to 21% bad reviews. Strava, with fewer reviews, has more than half. This does not mean that one app is worse. A large app gets many quick five-star ratings, and they dilute the share. In a triage report, look at the count of bad reviews and its change, not at the share alone.

Test 2: is one run a day enough?

If you divide the limit of one call by the daily volume, you get the share that one daily run catches. The limit is 500 reviews for the App Store and 200 for Google Play, and the share stops at 100%. Three of the four sets reach 100%. Duolingo on the App Store gets about 317 a day, and Strava gets a few to a few dozen. Only Duolingo on Google Play in English gets about 1,131 a day, so one call catches 17.7%.

The reviews that one run misses do not come back later. Google Play gives the newest 200 reviews and stops there, also with paging. So for an app like Duolingo, the daily report sees a slice of about 4 hours and loses the other 20. The group shares in that slice may still be fair. But a claim such as "this group grew" becomes weak, because the slice may follow a push notification by chance.

For a high-volume app, one run a day catches a short slice. The rest falls off the end of the belt.

To catch all reviews for Duolingo, you need 6 runs a day, one every 4 hours. A cloud automation made in VS Code runs at most once a day, so there are two paths. The first path is an automation made on the GitHub website with an hourly schedule. Every run starts an agent session, so every run uses AI credits and Actions minutes.

The second path splits fetching from analysis. A plain GitHub Actions scheduled workflow runs the fetch script every 4 hours, with no model. It appends the new bad reviews to a file in the repository. The cloud automation runs once each morning and reads only that file. The API fee for this path is 9 calls a day: 6 for Duolingo on Android and 1 for each of the other three listings. That is about $0.375 for 30 days, and the model still starts only one session a day.

For apps with medium or low volume, none of this matters. One run a day catches 100% with a large margin. The table below turns the four measured sets into a schedule rule.

Data set	Time covered by one call	Runs a day to catch all	API calls a day	API fee, 30 days
Duolingo · Google Play English	4.25 hours	6	6	$0.250
Duolingo · App Store US	37.9 hours	1	1	$0.042
Strava · Google Play English	7.6 days	1	1	$0.042
Strava · App Store US	123.9 days	1	1	$0.042

A simple test finds the right number for your own app. Make one manual call during setup and look at the span between the newest and the oldest review. If the span is more than 24 hours, one run a day is enough. If it is less, divide 24 by the span and round up. Put this test in the automation prompt, so the agent checks it on every run. One big release or one sale can multiply the review volume within a week.

Test 3: the newest review is already a day old

The second fact that affects a daily run is the delay. We took the call time minus the time of the newest review in each response. The table also shows the repeat calls that we made to check the delay.

Data set	Delay of the newest review	Repeat call (SGT)	Result of the repeat
Duolingo · App Store US	36.9 hours	00:40:33, 18 minutes later	500 of 500 the same, 0 new
Duolingo · Google Play English	24.3 hours	00:29:13, 6 minutes later	177 the same, 23 new
Strava · App Store US	44.3 hours	(not compared)	—
Strava · Google Play English	24.4 hours	00:41:50 to 00:42:10, about 19 minutes later	200 of 200 the same

Both Google Play delays are just over 24 hours. This matches the Play Console help page, which says that new ratings and reviews appear publicly after a delay of about 24 hours. The App Store delay is longer, 36 to 44 hours, and the Apple pages on ratings and reviews give no exact number.

The repeat calls show two patterns. On Google Play, 23 of 200 Duolingo reviews were new after six minutes, so the store releases reviews all the time, about one day late. On the App Store, all 500 Duolingo reviews were the same after 18 minutes, so that store updates in batches. Two calls a few minutes apart can give the same list, and this is normal.

The delay has three effects on the automation design. First, the report must state the range of posting times that it covers. Do not call it "today's bad reviews", because it shows reviews from two days ago to yesterday. Second, decide "new" by review ID, not by posting time. A review posted 40 hours ago may appear for the first time today. Third, the exact start time does not matter much. A run 30 minutes earlier or later gets almost the same data.

Test 4: what groups do the bad reviews fall into?

We wrote the group rules as a fixed keyword table in the script. With fixed rules, anyone can run the numbers again, and we can compare the rules with the model later. The rules have an order. Crash and bugs come first (crash, freeze, bug, not working, stuck). Login and account come next (log in, sign in, password, account). Then come payment and subscription (subscription, charge, refund, premium, trial), and then sync and devices (sync, GPS, Garmin, watch, upload).

Ads and redesign (update, redesign, changed) come last. When a review matches more than one rule, the first match wins. When it matches no rule, it goes to "other". We fixed these rules at 00:27 SGT, before we looked at the group counts.

Group	Duolingo · App Store	Duolingo · Google Play	Strava · App Store	Strava · Google Play
Crash and bugs	5	0	44	19
Login and account	1	1	25	12
Payment and subscription	27	4	63	14
Sync, GPS and devices	2	0	28	11
Ads	5	2	0	1
Redesign and updates	10	1	14	7
Other	55	19	62	38
Total, 1 to 3 stars	105	27	236	102

The two apps have very different bad reviews. For Duolingo, "other" and payment are the largest groups, and crash and login problems are rare. Most "other" reviews are about lesson design, the energy system and the learning method, and keywords do not catch them. For Strava, payment is still the largest group. But crash, sync and login together are larger than payment, which fits an app that connects to watches and records GPS tracks.

A report that shows only shares would be nearly empty for Duolingo. Of 27 bad English Android reviews a day, 19 are "other". So the classification step cannot depend on keywords alone. The next test measures how far the keywords go.

Test 5: how accurate is the keyword rule?

To learn if the keyword rule can work alone, we drew 40 bad reviews from the four sets with a fixed random seed. We read the title and text of each review, gave it a group, and compared that group with the rule. The rule was right 23 times and wrong 13 times. It missed 4 reviews: the rule said "other" and we found a real group. With only 40 reviews, this ratio gives only the order of size. The rule is right a little more than half of the time.

The 13 wrong reviews follow a pattern. The word "account" causes most errors. One user writes that they paid for a full year but cannot use it, and the text contains "account". The login rule comes first, so the rule says login, but the problem is payment. Complaints about support, or about a missing workout type, also go to login because of the word "account".

The second pattern is "super". Duolingo calls its paid plan Super, so the rule treats "super" as a payment word, and "super annoying" goes to payment. The third pattern is the Strava Android data problem. A review such as "it used 4GB of mobile data in a few hours after the update" contains GB and a number. The payment rule catches it as a money amount, but the problem is a bug.

The 4 missed reviews use no keyword at all. Examples are "heart rate does not show", "no full screen on iPad mini" and "auto-pause is terrible". A person sees the group at once. A keyword list does not.

These errors show where the model belongs. Keyword rules are a good first filter: they are cheap, anyone can run them again, and they catch the obvious payment and crash reviews. The final group must come from a model that reads the text. Public research gives numbers to compare. A May 2025 paper used ChatGPT zero-shot on 1,880 labeled app reviews in four requirement groups and reports an F1 of 0.842. An October 2025 paper tested five lightweight open models on user feedback and reports F1 values from 0.47 to 0.68.

A July 2025 paper on hybrid routing sends easy feedback to small fine-tuned models and hard feedback to a large model. It keeps 98.4% to 100.4% of the zero-shot accuracy of the large model alone. A value above 100% means that the mix was slightly better. It also cuts requests by 67.8% and token cost by 66.3%.

These papers use other groups than ours, so do not copy their numbers. But the direction is the same: a cheap layer first, and a large model for the hard cases. Our keyword rule takes the place of the small model in that paper.

Test 6: the Strava Android data bug, and how much earlier a daily run sees it

The real value of a triage report is to show when one group suddenly grows. The Strava Google Play reviews gave us a real example. Of 200 reviews, 23 say that the app uses a lot of mobile data, for example 3GB for two hikes. Of those 23, 21 have one star. In the 450 Strava App Store reviews from the same period, no review mentions data use. The problem shows only on Android.

By posting day, November 2, 2026 had 10 of these reviews. After that, each day had 0 to 3, and the count fell day by day. By app version, 17 of the 23 came from version 487.11 and 4 from version 488.11. Version 487.11 had 86 reviews in the set, so about 20% mention data. Version 488.11 had 68 reviews, and about 6% mention data.

One review says that the problem started on October 22, 2026, and had no fix after two weeks. A Reddit thread in r/Strava describes the same jump in Android data use. In that thread, one user repeats advice from support to turn off mobile data first. We found no public statement from Strava about this problem. So we describe only what the reviews show, and we do not guess the cause.

Now imagine a team that ran a daily triage from late October. The keyword rule would put the problem in "payment" or "other", as the last section showed. The model reads the text and puts it in the bug group. Ten reviews with the same complaint on one day mark it as a spike, and the automation opens an issue. A weekly report sees the problem several days later at best, and this is the main difference from our weekly Codex Cloud review report.

Filter with a script first: why the agent should not read raw MCP output

First, count the tokens. In the four raw responses, one review is 437 to 569 bytes on average. The OpenAI help page on tokens gives about 4 characters per token in English. So one review is about 109 to 142 tokens. The MCP round trip at 00:26:38 SGT fits this estimate, with about 536 characters per review.

Now take one call a day for each of the four listings. For Duolingo on the App Store we count about 317 new reviews a day, and for the others we count the reviews of that day. If the model reads the raw MCP output, about 65,062 tokens a day enter the context. If a script removes seen IDs, keeps 1 to 3 stars and keeps only title and text, about 4,999 tokens a day remain. The difference is about 13 times.

The GitHub models and pricing page lists input prices per million tokens. Claude Sonnet 5.5 is $2, Claude Haiku 5.5 and GPT-6 Luna are $0.10, and Claude Opus 5.5 is $4. For the data part only, Sonnet 5.5 costs $0.1301 a day on raw output and $0.0100 a day on filtered output. Haiku 5.5 costs $0.0065 a day on raw output and $0.0005 a day on filtered output.

These numbers include only the data that enters the context, not the prompt, the repository files, the report or the issue. We did not run a real session, so we have no measured number for that part. The data part already shows the direction. With filtering, even a strong model is cheap, and without it the same money buys only a small model.

A script first has two more advantages. Code does the dedupe, not the memory of the model. Test 3 showed why: a review can appear for the first time long after its posting time. Also, author names and avatar links leave before the data enters the context. So the report and the issues cannot show the names of ordinary users by accident.

Below is a minimal fetch script for the repository, and the agent runs it with Bash on each run. We ran it once with our test key at 00:41:50 SGT. It made one call per store, and the charge was $0.002778. It marked all 600 reviews as seen. It wrote 311 reviews with 1 to 3 stars to the file of the day.

"""Fetch new App Store / Google Play reviews, drop seen ones, keep 1-3 stars for the model."""
import json, os, pathlib, urllib.request, datetime

API = "https://api.everyinfra.com/api/v1/social"
KEY = os.environ["EVERYINFRA_API_KEY"]          # Agents secret, no COPILOT_MCP_ prefix
APPS = [
    ("app_store", "426826309", {"country": "us", "sort": "newest", "limit": 500}),
    ("google_play", "com.strava", {"country": "us", "language": "en", "sort": "newest", "limit": 200}),
]
STATE = pathlib.Path(".triage/seen.json")

def call(platform, app_id, params):
    body = {"platform": platform, "action": "reviews", "params": {"app_id": app_id, **params}}
    req = urllib.request.Request(API, data=json.dumps(body).encode(), method="POST", headers={
        "Authorization": f"Bearer {KEY}", "Content-Type": "application/json", "User-Agent": "review-triage/1.0"})
    with urllib.request.urlopen(req, timeout=120) as r:
        return json.load(r)

seen = set(json.loads(STATE.read_text())) if STATE.exists() else set()
out, spent = [], 0.0
for platform, app_id, params in APPS:
    data = call(platform, app_id, params)
    spent += data.get("billing", {}).get("charged_usd", 0)
    for r in data.get("results", []):
        key = f"{platform}:{r['id']}"
        stars = r.get("rating", r.get("score"))
        if key in seen:
            continue
        seen.add(key)                              # mark as seen
        if stars is not None and stars <= 3:
            out.append({"key": key, "stars": stars, "version": r.get("app_version"),
                        "posted_at": r["posted_at"],
                        "text": ((r.get("title") or "") + " | " + (r.get("text") or ""))[:600]})
day = datetime.date.today().isoformat()
pathlib.Path("reports").mkdir(exist_ok=True)
pathlib.Path(f"reports/{day}.new-low-star.json").write_text(json.dumps(out, ensure_ascii=False, indent=1))
STATE.parent.mkdir(exist_ok=True)
STATE.write_text(json.dumps(sorted(seen)))
print(json.dumps({"new_low_star": len(out), "seen_total": len(seen), "charged_usd": round(spent, 6)}))

The last line prints three numbers: the new bad reviews of this run, the total of seen reviews and the API fee of this run. The agent sees them in the session and can put them at the top of the report. Commit .triage/seen.json back to the repository. Each run starts in a new cloud environment, so without the file the script treats every review as new. The first run also treats all old reviews as new. Use the first report as a baseline only, with no spike alerts.

How to write the automation prompt

The automation prompt is text for the agent. You type it in the Automations tab in VS Code when you create the automation. A precise prompt gives more stable results and uses fewer credits, because the model does not have to plan the task again each day. The block below is a config example, and we did not save this automation on GitHub.

We suggest that you put the group rules and the report format in a skill under .github/skills/review-triage/. The GitHub page on agent skills says that the cloud agent reads project skills from .github/skills, .claude/skills or .agents/skills. The VS Code video on agent skills shows the same layout. Each skill folder has one SKILL.md, with optional scripts beside it.

Daily app store bad-review triage (config example)

1. Run `python3 scripts/triage.py`. It fetches new App Store and Google Play reviews,
   writes reports/<date>.new-low-star.json, and prints new_low_star, seen_total, charged_usd.
   Call each store listing once per run. On 429, wait retry_after seconds, at most 3 times.
2. Read the JSON. Put each bad review into one group from .github/skills/review-triage/SKILL.md:
   crash and bugs, payment and subscription, login and account, sync and devices,
   ads, redesign and updates, other. Decide from the full text, not from one keyword.
3. Write reports/<date>.md: the posting-time range covered, the count per group,
   the 7-report average per group, up to 3 review texts per group (remove names),
   and the API fee of this run.
4. If a group is more than 3 times its 7-day average and has at least 5 reviews,
   open an issue titled "[Review spike] group + app version" with the examples.
   If an open issue with that title exists, add a comment to it.
5. Commit reports/ and .triage/seen.json to the triage-reports branch and open a PR.
   Do not push to main.

The threshold in item 4 (3 times the average, at least 5 reviews) is only a starting point, so tune it to your review volume. Item 5 is about safety. The GitHub page on cloud agent risks says that the agent works on copilot/ branches and delivers through pull requests. Review text comes from outside users and can contain text such as "ignore the instructions above". A pull request puts a human check between the agent and the main branch.

What the report and the issue look like

A person should read the first screen of the report in 10 seconds. The sample below uses the real Strava data from 00:22 to 00:24 SGT. We laid it out by hand, in the format of the prompt above. The group counts come from the keyword rule and had no model check, so the sample shows only the format.

# Bad-review report 2026-11-11 (Strava)

Covered: Google Play English 2026-11-02 to 11-09 (UTC), App Store US 2026-07-07 to 11-08
New 1-3 star reviews: Google Play 102, App Store 236 (first run, baseline only)
API fee of this run: $0.002778 (2 calls)

| Group | Google Play | App Store |
|---|---|---|
| Crash and bugs | 19 | 44 |
| Payment and subscription | 14 | 63 |
| Login and account | 12 | 25 |
| Sync and devices | 11 | 28 |

To check: 23 Google Play reviews say the app used a lot of mobile data after an update,
mostly on 487.11. App Store: 0.

The automation opens an issue only when a group clearly grows. The issue is shorter than the report. It has the group, the app version, the count and the past average, three review texts and a link to the report file. Both the GitHub issues REST API and the built-in GitHub tools of the cloud agent can open issues. In an automation, let the agent use its built-in tools. It does not need another GitHub token.

The cost: API fee, AI credits and Actions minutes

We used the GitHub billing pages as of November 11, 2026, for the Copilot side. Copilot usage is now counted in AI credits, and 1 credit is $0.01. The plans page and the usage-based billing page give the monthly credits below.

Plan	Price	AI credits included each month
Pro	$10 a month	1,500
Pro+	$39 a month	7,000
Max	$100 a month	20,000
Business	$19 per user a month	1,900 per user
Enterprise	$39 per user a month	3,900 per user

The cloud agent gets a 10% discount. Each session uses credits by model tokens and minutes under the GitHub Actions billing rules. The runner price list gives $0.006 a minute for a 2-core Linux runner. You can set credit limits per run, day, week and month, with 30 credits as the lowest limit per run. The daily count resets at 00:00 UTC.

One run a day, 30 days	Amount	How we got it
EveryInfra API fee, two apps, 4 listings	$0.1667	4 calls a day × $0.001389 × 30
Same, Duolingo Android every 4 hours	$0.375	9 calls a day × $0.001389 × 30
Model reads data, Sonnet 5.5, script filter	$0.30	about 4,999 tokens a day × $2 per million × 30
Model reads data, Sonnet 5.5, raw MCP output	$3.90	about 65,062 tokens a day × $2 per million × 30
Actions minutes (10 minutes a run assumed, after included minutes)	$1.80	10 minutes × $0.006 × 30
Rest of the session (prompt, report, issue)	Not measured	We ran no real session, so we give no estimate

The API fee is the smallest part of the job, under $0.40 a month even with 9 calls a day. The script filter changes the model cost of reading data by about 13 times. The Actions cost depends on session length, and our 10 minutes is an assumption. Actions minutes are free until the account uses the minutes in its plan. Public pages cannot give the session overhead. So set a low credit limit per run for the first week, then read the GitHub usage page.

Why not use the stores' own APIs?

Both stores have APIs for developers, but each reads only your own apps. Apple's App Store Connect API has an endpoint that lists all customer reviews of an app. It needs an API key from your developer account, and it reads only apps of your own team.

The Google Play Developer API has reviews.list. The Reply to reviews page says that it returns only reviews from the last week, only for production apps and only reviews with text. The read quota is 200 calls an hour, and a reply has a limit of 350 characters. The Python reference for the reviews resource shows the same methods. For a team that watches only its own app, these two APIs are the first choice. They are free, and the data comes from the stores themselves.

They cannot do three things: read competitors, read more than one week back, and put both stores in one format. Many teams add one or two direct competitors to the daily report. Then they can see if a problem, such as crashes after an OS update, affects the whole category. The two EveryInfra review capabilities work the same for any public app, return one JSON format and cost $0.001389 per call.

Our suggestion is simple. Use the store APIs for replies and exact counts on your own app. Use a data API for competitors and for a cross-store view. Both can run in the same automation, in separate sections of the report.

Limits and things to watch

The table below collects the limits from all sections, with the action that each one needs.

Limit	What to do
Cloud automations from VS Code work only on private and internal repositories	Use a private repository; a shared team automation also needs the organization policy for the cloud agent
Cloud automations do not read local VS Code MCP config	Add the server in the GitHub repository settings
Discussion 211107: custom MCP tools can fail in automation sessions	Trigger the first run by hand and check the log, or use the script path
Shortest cloud schedule in VS Code is daily	Use an hourly automation on GitHub, or fetch often in Actions
Google Play returns the newest 200, country does not change them	Call each language separately
App Store returns at most 500, with no paging	Call each storefront separately with country
New reviews arrive 24 to 44 hours late	Label the report with its posting range; keep crash monitoring for real-time alerts
Review text can try to steer the agent	Deliver through a pull request, no push to main, remove user names

Every Copilot step in this article is a config example. We did not create this automation in a GitHub repository or run a real session. So we have no numbers for session time, total session tokens or real credit use. All EveryInfra numbers come from live calls on November 11, 2026, checked against the catalog price and the charged_usd of each response. This article does not speak for GitHub or Microsoft, and EveryInfra has no partnership with either company.

FAQ

VS Code Copilot cloud automations not working: how do I find the cause?

First check three things from the VS Code page. You need VS Code 1.144 or later, the automation settings must be on, and the repository must be private or internal. Then open the session log of that run on GitHub. Find out if the trigger did not fire, the session did not start or a tool call failed. If custom MCP tools fail only in automation sessions, as in discussion 211107, use the script path for now.

Copilot cloud agent pricing: what does one run a day cost?

Each run starts one cloud agent session. It uses AI credits by model tokens (1 credit is $0.01) and Actions minutes. We can give only the parts that we measured. The API fee for two apps is $0.0056 a day. Sonnet 5.5 reading filtered bad reviews costs about $0.01 a day for the data part. We did not measure the rest of the session. Set a per-run credit limit first and read the usage page after one week.

Can Copilot cloud agent skills hold the triage rules?

Yes. The GitHub page on agent skills says that the cloud agent reads project skills from .github/skills, .claude/skills or .agents/skills. Automations also use the skills of the repository. Put the group list, the examples for each group and the report format in one SKILL.md. Then the prompt can stay short.

Why does the Google Play store reviews API return only one week?

The Google Play Developer API page on replies says that reviews.list returns only reviews from the last week. It covers only production apps and only reviews with text. For a longer history, store the reviews yourself every day, or pull the newest reviews every day from another data API.

Get started

Step 1: get an API key from the EveryInfra quickstart, and read the parameters of app_store/reviews and google_play/reviews in the free catalog. Step 2: find the IDs of your app and of one competitor with app_store/search or the store URL. Make one manual call and look at the span between the newest and oldest review. Then compute how many runs a day you need.

Step 3: follow the config examples in this article. Add the MCP server or the fetch script and its secret to the GitHub repository. Create a daily cloud automation in the Automations tab in VS Code. Trigger it once by hand, and check that the session log shows the API call and the report commit. The full remote MCP guide is on the EveryInfra MCP server page, and the prices are on the pricing page.

Related posts on our site: in the Copilot MCP weekly social report, the model only writes a weekly Actions script. The Codex Cloud weekly review report uses the same two stores once a week. For review data as a product, read review data productization. For double charges on agent retries, read idempotency keys for AI agent retries.

References

1. Create and manage Copilot Automations in Visual Studio Code, GitHub changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-create-and-manage-copilot-automations-in-visual-studio-code/
2. Create and manage agent automations, VS Code docs, page dated 2026-11-11, read 2026-11-12, https://code.visualstudio.com/docs/agents/run/automations
3. VS Code 1.144 release notes, 2026-10-28, https://code.visualstudio.com/updates/v1_144
4. About automations, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/concepts/agent-capabilities/agent-powered-workflows-and-operations/about-automations
5. Creating automations, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations
6. New tools, triggers, and cost controls for Copilot automations, GitHub changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-new-tools-triggers-and-cost-controls-for-copilot-automations/
7. Build shared workflows for your team with Copilot automations, GitHub changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-build-shared-workflows-for-your-team-with-copilot-automations/
8. Copilot automations now learn from outcomes and self-improve, GitHub changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-copilot-automations-now-learn-from-outcomes-and-self-improve/
9. GitHub Agentic Workflows generally available, GitHub changelog, 2026-10-28, https://github.blog/changelog/2026-10-28-github-agentic-workflows-generally-available/
10. GitHub Universe 2026: evolving every layer of the stack, GitHub blog, 2026-10-28, https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/
11. REST API endpoints for agent automations (API version 2026-03-10), GitHub docs, read 2026-11-11, https://docs.github.com/rest/agent-automations/agent-automations?apiVersion=2026-03-10
12. Test automations (issue 340970), microsoft/vscode, 2026-10-11, https://github.com/microsoft/vscode/issues/340970
13. Configure MCP servers for your repository, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
14. About MCP, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/concepts/customizations/mcp
15. Configure secrets and variables for Copilot cloud agent, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables
16. Customizing or disabling the firewall for Copilot cloud agent, GitHub docs, read 2026-11-11, https://docs.github.com/copilot/how-tos/agents/copilot-coding-agent/customizing-or-disabling-the-firewall-for-copilot-coding-agent
17. Copilot allowlist reference, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/reference/copilot-allowlist-reference
18. About Copilot cloud agent, GitHub docs, read 2026-11-11, https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
19. Risks and mitigations for Copilot cloud agent, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations
20. About agent skills, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/concepts/agents/about-agent-skills
21. Usage-based billing for individuals, GitHub docs, read 2026-11-11, https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
22. Plans for GitHub Copilot, GitHub docs, read 2026-11-11, https://docs.github.com/en/copilot/get-started/plans
23. Models and pricing, GitHub docs, read 2026-11-11, https://docs.github.com/copilot/reference/copilot-billing/models-and-pricing
24. About billing for GitHub Actions, GitHub docs, read 2026-11-11, https://docs.github.com/billing/managing-billing-for-github-actions/about-billing-for-github-actions
25. Actions runner pricing, GitHub docs, read 2026-11-11, https://docs.github.com/en/billing/reference/actions-runner-pricing
26. REST API endpoints for issues, GitHub docs, read 2026-11-11, https://docs.github.com/en/rest/issues/issues
27. Custom MCP tools unavailable in automation sessions (discussion 211107), GitHub Community, 2026-10-27, https://github.com/orgs/community/discussions/211107
28. Copilot automations (discussion 211008), GitHub Community, read 2026-11-11, https://github.com/orgs/community/discussions/211008
29. Cloud sandbox sessions, VS Code docs, read 2026-11-11, https://code.visualstudio.com/docs/agents/run/cloud-sandbox-sessions
30. Add MCP servers in VS Code, VS Code docs, read 2026-11-11, https://code.visualstudio.com/docs/copilot/customization/mcp-servers
31. Introducing Agent Skills in VS Code, VS Code YouTube channel, transcript read 2026-11-11, https://www.youtube.com/watch?v=JepVi1tBNEE
32. Tools, Model Context Protocol specification 2025-06-18, https://modelcontextprotocol.io/specification/2025-06-18/server/tools
33. Reply to reviews, Google Play Developer API docs, read 2026-11-11, https://developers.google.com/android-publisher/reply-to-reviews
34. androidpublisher v3 reviews (Python reference), Google developer docs, read 2026-11-11, https://developers.google.com/resources/api-libraries/documentation/androidpublisher/v3/python/latest/androidpublisher_v3.reviews.html
35. View and analyze your app's ratings and reviews, Play Console Help, read 2026-11-11, https://support.google.com/googleplay/android-developer/answer/138230
36. List all customer reviews for an app, App Store Connect API docs, read 2026-11-11, https://developer.apple.com/documentation/appstoreconnectapi/get-v1-apps-_id_-customerreviews
37. Ratings, reviews, and responses, Apple Developer, read 2026-11-11, https://developer.apple.com/app-store/ratings-and-reviews/
38. What are tokens and how to count them, OpenAI Help Center, read 2026-11-11, https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
39. Hybrid routing for app review classification (arXiv 2507.08250), 2025, https://arxiv.org/html/2507.08250v2
40. Zero-shot app review classification with ChatGPT (arXiv 2505.04759), 2025, https://arxiv.org/html/2505.04759v1
41. Lightweight LLMs for app review analysis (arXiv 2510.23055), 2025, https://arxiv.org/pdf/2510.23055
42. Mobile data usage shot up today (Android), Reddit r/Strava, read 2026-11-11, https://www.reddit.com/r/Strava/comments/1xcqvgv/mobile_data_usage_shot_up_today_android/
43. EveryInfra social data catalog (free), read 2026-11-11 00:21 SGT, https://api.everyinfra.com/api/v1/social/catalog

---

Originally published on the EveryInfra blog: VS Code Copilot Cloud Automations: Daily App Store Review Triage. This article was written with AI assistance; the numbers come from the API calls and sources linked above, and were checked before publishing.

EveryInfra is a pay-per-call data API for AI agents and developers: everyinfra.com.