How I configured a maps project with the help of Computer Use

On 6 October, I asked AI to prepare a new Google Cloud project for maps and address suggestions in an application. I needed a project, billing, a budget, usage restrictions, and a suitably restricted API key. An API is the interface through which an application uses a service, and a key links its calls to my project.

This is an example of working through Computer Use. The agent operated the visible Google Cloud console in a signed-in browser, while I made decisions about scope and acceptance of terms. As a result, I did not have to work through many console screens myself, but I still knew exactly what had been saved.

First I established what actually needed to work

The initial plan was broader: a map, address suggestions, server-side geocoding, and two separate keys. Here, geocoding means turning an address into coordinates. During the work, I asked whether the application really needed a separate server key for that.

The answer was no, not at this stage. An operator selects the address in the browser, and the Places component can return information about the chosen place, including coordinates. Finding the closest point is then ordinary distance calculation between known coordinates. It does not need an additional Google call.

The final scope was therefore smaller:

This was a deliberate decision to postpone elements that do not yet have a concrete use. Every additional service and key means more settings to maintain. Google recommends restricting key access to the APIs that are needed. Google Maps Platform: securing keys and services

Account, project, and billing are three different things

Computer Use first read the active account and organisation in the console. Only then did it create a new project, open its billing settings, and confirm the connection to the right billing account.

The distinction matters. An account is for signing in. A project groups APIs, permissions, keys, and limits. A billing account determines where Google charges for usage. Creating a project does not yet answer whether services can run or whether the owner will see the cost.

After creating the project, we set a monthly budget of PLN 100, limited only to that project, with alert thresholds of 50%, 90%, and 100%. A read after saving confirmed the amount, thresholds, and narrowed scope. We had not yet tested delivery of an alert after an actual threshold was exceeded.

This is an easy point of confusion: a budget is not a fuse that automatically cuts off usage after PLN 100. It is an observation and notification mechanism. Google describes budget alerts as forecasting or reporting spending; a budget itself does not stop services or charges. Google Cloud Billing: budgets and alerts

The budget therefore answers “are we approaching a cost?”, while an API limit answers “how many requests can a given function accept?” It is useful to have both.

Accepting terms was not a hidden click

When the Google Maps Platform services were first enabled, the console displayed terms for the European Economic Area. This was not an ordinary technical option. Acceptance creates an obligation for the organisation, so the agent stopped on that screen, explained its meaning, and waited for my explicit decision. I describe the same pause before an externally consequential decision in the domain-move story using Computer Use.

After acceptance, we enabled only Maps JavaScript API and Places API (New). The console was then read again to confirm that the unnecessary Geocoding API had not been enabled along with them.

Later, I decided to add Places UI Kit for the planned address-suggestion form beside the map. It is a separate service, so this was a second explicit stage: find it in the library, enable it, read the confirmation, and add it to the key restrictions. Places UI Kit provides the BasicPlaceAutocompleteElement component for building place suggestions. Places UI Kit documentation

“Maps” is not one switch. The choice of API follows from the specific interface you are building. In a similar task, it is worth reading the list of active services after saving and comparing it with the approved scope.

One browser key, two layers of restriction

Only one browser key was created. It was saved locally in a file ignored by Git, outside files tracked in the project’s version history. Access to that file was limited to its owner. I do not publish the key’s value in this article.

The key received two kinds of restriction:

1. Application restriction: it works only from local localhost addresses and its subdomains. That is the development-environment scope.
2. API restriction: it can call only Maps JavaScript API, Places API (New), and—after the second stage—Places UI Kit.

The two layers solve different problems. Restricting the site address makes it harder to use the key from a foreign website. Restricting the API means that even a correctly used key does not open access to other services in the project. Google recommends combining application and API restrictions and later checking actual use in Metrics Explorer. Google Maps Platform: key-protection practices

This matters because a key that works in a browser can be read by an application user. Hiding it in a local file during development does not replace restrictions on how it can be used. A key intended for server calls would need its own storage method and access restrictions. In this case there was no reason to create one yet.

Limits: three numbers, three different behaviours

In the first stage, we set two daily limits:

After enabling Places UI Kit, we added a limit of 500 daily session requests for that service. The agent did not merely type the number: it went through the warning screen about lowering a limit, saved the change, and then read the value in the console again.

These limits are not the same thing. A user may see one map but generate several suggestion requests while entering an address. The Places UI Kit limit, in turn, measures its own session requests. You must not look at one number and assume it describes all map traffic.

A limit of 500 sessions per day does not guarantee zero monthly cost either. Across 30 days it allows 15,000 sessions, and other services have their own billing units. After deployment, actual traffic and budget alerts therefore need monitoring. Current rates and free tiers should be checked for each service used in the Google Maps Platform pricing.

What was evidence, and what still had to be checked

In this story, “done” did not mean the agent had said so. The evidence was console reads after every material change: the created project, connected billing, saved budget, active APIs, the key’s allowed APIs, and the visible value of the 500-session limit.

We had not yet tested the component’s behaviour in the application itself. Configuration in Google Cloud prepares the environment; it does not prove that the form works. The next person doing the work should connect the key in the local environment, choose an address through Places UI Kit, and check:

• whether the map loads from the local application;
• whether address suggestions return the chosen place;
• whether the application retrieves only the fields it needs;
• whether an attempt to use the key outside the allowed local address is rejected;
• whether, after several tests, the console shows the expected use of the correct APIs.

The durable storage of Places data also remains to be designed separately. I do not automatically treat coordinates or an address retrieved from Google as my own permanent database. Before saving them in a business model, the current terms of service must be checked and a decision made about which data is owned data and which has a retention period and deletion rules.

A prompt I will use again

The template below organises the steps from this work; it is not a verbatim quotation from the conversation.

Use Computer Use to configure a new Google Cloud project for a local web-application environment with a map and address suggestions.

First read and show me: the active account, organisation, planned project name, and billing account. Present the plan for services, restrictions, and costs. Work within the approved scope. Show contract terms and changes that extend that scope separately for a decision.

After my approval:
1. create the project and confirm its connection to the right billing account;
2. create a budget only for this project with an amount and alert thresholds, then explain that an alert is not an automatic spending limit;
3. enable only the APIs needed for the described function;
4. create only the key needed now, save it in the agreed place outside Git history, and do not show its value in chat or logs;
5. restrict the key both to the relevant application addresses and to specific APIs;
6. set separate limits for the map, suggestions, and UI components if the console displays them separately;
7. after every change, read the saved state and state what is fact and what needs testing in the application.

At the end, prepare a table: setting, value, evidence in the console, remaining risk. The report must not contain key values, passwords, or tokens.

The practical result of this work is a configured project for a local application environment: the needed services, a restricted key, a budget, and separate limits. An important decision was to omit the server key that was unnecessary at this stage. The next step has a different purpose: test the map and suggestions in the application. That makes it clear what the configuration confirms and what we have not checked yet.